主页

风控服务的一次请求要完成宽表关联、特征计算和模型推理。这些计算依赖固定的关联宽表、词表和分箱字典。为了避免每次请求都重新读盘或访问外部存储，服务会在启动时把它们一次性加载到内存。这些工作以 CPU 计算为主，请求之间相互独立，通常可以通过增加计算进程提高并发能力。问题在于，磁盘上几百 MB 的静态数据，加载成 DataFrame 等 Python 对象后可能膨胀到数 GiB，每个进程再各自加载一份。在测试环境中，2 个进程处理轻请求时已经占用 6.3 GiB，3 个进程处理重请求时占用 8.7 GiB；继续增加并发，内存会先于 CPU 达到上限。 这次采用的办法是让 Gunicorn 主进程（master）先加载只读大对象，再 fork 出计算进程（worker）。借助 Linux ...

一次信贷或反欺诈决策，往往要串起数十到上百个处理步骤：多源数据查询、特征衍生、模型打分。为了应对特征与模型的频繁迭代和严苛的时延要求（SLA），决策引擎普遍采用声明式依赖编排。本文记录如何由声明式依赖推导出分层执行拓扑，并对其中依赖闭包计算的两版实现做复杂度与实测对比（基准测试：全图规模 $\lvert V \rvert=256$，目标节点数 $\lvert R \rvert=24$，闭包构建耗时从 2,987 ms 降至 2.33 ms）。

SIMUL8 is almost always used as a visual desktop tool. But under the hood, every .S8 simulation file can be exported to and imported from an XML format. Compared to manual GUI drag-and-drop, XML provides a programmatic interface to automate model construction, parameter tuning, and batch scenario generation. To build models this way, the offici...

引言 前置文章：JupyterHub 极简部署实践：基于 SystemdSpawner 与本地 PAM 认证 (一期) 在一期部署中，我们成功搭建了基于 SystemdSpawner 与本地 PAM 认证的多用户 JupyterHub。随着团队规模的扩大，手动管理 Linux 用户、维护密码不仅繁琐，而且无法满足企业对单点登录（SSO）与多因素认证（MFA）的安全合规要求。 本期我们将 JupyterHub 升级为 Azure AD（Microsoft Entra ID）OAuth2 认证。由于一期已经严格遵循了统一的用户名规范，本次升级无需迁移已有用户数据，可以实现无痛过渡。

为什么选择 JupyterHub + SystemdSpawner 多用户 Jupyter 平台常见方案是基于 Kubernetes (Zero to JupyterHub) 或 Docker (DockerSpawner)。但对于中小团队或单机部署，Kubernetes 维护成本过高，DockerSpawner 存在数据权限映射和容器管理开销。 我们需要一个更轻量、贴合宿主机环境的方案。SystemdSpawner 是一个理想的选择：它能够利用 Linux 原生 systemd 服务的 cgroup 限制 CPU 和内存资源，且用户打开 Terminal 直接就是真实的宿主机 Shell，方便使用宿主机已安装的各种开发工具。这非常适合单机、多用户的高效共享开发服务器。

为什么选择 NetBird 随着企业业务的分布式发展和远程办公的普及，构建一个安全、高效且易于管理的内网变得至关重要。传统的 VPN 解决方案（如 OpenVPN、IPsec）配置繁琐，对客户端支持有限，且由于中心化架构容易产生网络瓶颈。 我们需要一个现代化的替代方案，它应该具备以下特质：部署简单、配置下发自动化、基于点对点直连（降低延迟），且拥有直观的管理面板。这就是我们选择 NetBird 的原因。它不仅满足上述所有需求，还完美地平衡了企业级安全需求与极简的运维体验。

本文对 Rete 算法的执行架构、网络拓扑、编译与匹配过程进行说明，并附带 Python 代码模拟。

一台 Windows 机器上有多个账号，其中一个需要在后台保持登录来跑依赖桌面会话的定时任务。手动用远程桌面连一下太原始，改注册表 AutoAdminLogon 也只能设默认登录账号，无法在 A 账号已登录的情况下让 B 账号也在后台上线。最终方案：用 Node.js 在本地跑一个 RDP 客户端，连本机 3389 端口把目标账号登上去。