Hamlet 如何用 Databricks Lakebase 以生产数据测试变更

从公共部门痛点出发：Hamlet 的 AI 决策平台

Hamlet 是一个 AI 驱动的平台，目标是让地方政府决策过程变得可访问、可理解。公共部门的决策往往涉及大量文档、会议记录和复杂的审批流程，普通人很难追踪其中的逻辑与依据。Hamlet 试图用 AI 把这些信息结构化，帮助居民、记者和官员更清楚地看到"决策是怎么做出来的"。

这类产品对数据可靠性的要求很高：一旦基于错误或过时的数据生成结论，损害的不仅是用户体验，还有公共信任。因此，Hamlet 在工程实践上必须解决一个经典难题——如何在不污染生产环境的前提下，用真实的生产数据验证每一次变更。

测试困境：生产数据不能随便用，仿真数据又不够真

传统做法通常是在 staging 环境中使用脱敏或合成的数据集。但对于 Hamlet 这样的平台，问题在于：地方政府的决策数据具有高度上下文依赖性，合成数据很难复现真实场景中的边界情况，比如特定会议记录格式、历史版本之间的引用关系、以及跨文档的实体关联。

如果只用仿真数据测试，很多问题要到上线后才会暴露。而直接在生产库上做变更测试，风险同样明显：可能写入脏数据、影响线上查询稳定性，甚至破坏数据一致性。Hamlet 需要一种介于两者之间的方案——既能拿到生产数据的真实形态，又能与线上环境隔离。

数据库分支（Database Branching） 是近年来兴起的一种数据库工程实践，核心思想借鉴自 Git 的分支模型：从主库的某个时间点派生出一个逻辑上独立、物理上隔离的数据库副本。分支通常采用写时复制（Copy-on-Write）或存储快照技术实现，因此创建成本低、速度快，且不占用与主库等量的存储空间。开发者在分支上可以自由执行 schema 迁移、数据修改和查询压测，所有写入都被限制在分支内部。测试完成后分支可直接删除，主库的历史与状态不受任何影响。这一机制解决了传统 staging 环境需要定期同步、容易漂移的问题，使“用真实数据测试”与“不污染生产”这两个目标得以同时成立。

Databricks Lakebase Postgres 的切入点

根据 Databricks 官方的介绍，Lakebase Postgres 是一项将 Postgres 兼容数据库与数据湖能力结合的服务。它的关键价值在于：开发者可以基于生产数据创建独立的数据库分支（branch），在分支上进行 schema 变更、查询测试和功能验证，而不影响主库。

Hamlet 采用的正是这一思路。团队不再维护一套与生产脱节的 staging 数据集，而是从生产环境派生出一个隔离的 Postgres 分支，把待测试的变更跑在这个分支上。测试完成后，分支可以丢弃，主库不受任何影响。

这种模式的好处是双重的：测试所用的数据与生产保持同构，边界情况自然覆盖；同时因为分支是隔离的，测试过程中的写入和查询不会回流到线上。对于 Hamlet 这样依赖真实决策数据进行推理的平台，这几乎是理想的状态。

工程收益：从"猜测上线风险"到"验证后再上线"

从 Hamlet 的实践可以提炼出几个对同类团队有参考价值的点：

• 真实数据形态带来的测试保真度：分支数据继承生产库的结构与内容特征，避免了合成数据与真实分布之间的偏差，尤其在涉及 LLM 推理管道的场景中，输入数据的细微差异会显著影响输出质量。
• 隔离性降低变更风险：数据库分支与主库分离，schema 迁移、索引调整、查询重写等操作可以先在分支上验证，减少上线回滚的概率。
• 环境一致性：不再需要维护一套可能逐渐偏离生产的 staging 环境，减少了"本地能跑、线上报错"这类问题的发生。

对于 AI 应用团队而言，第三点尤其重要。AI 系统的行为对数据状态高度敏感，环境漂移往往以难以复现的 bug 形式出现。用生产数据的隔离分支做验证，本质上是把"数据环境"也纳入了可测试的范围。

环境漂移（Environment Drift） 指的是测试环境与生产环境在数据、配置或依赖版本上逐渐产生差异的现象。传统 staging 环境往往在项目初期与生产高度一致，但随着生产库不断写入新数据、执行 schema 变更，staging 若不能同步更新，就会与真实状态脱节。对于 AI 应用而言，环境漂移的危害尤为隐蔽：模型推理对输入数据的分布、格式和上下文长度都很敏感，staging 中看似正常的测试通过，上线后却可能因为真实数据中的长尾样本而输出异常。使用生产数据分支可以从根本上消除数据维度的漂移，因为分支本身就是生产状态在某一时刻的精确投影。

对 AI 应用开发者的启示

Hamlet 的案例折射出一个更普遍的趋势：随着 AI 应用深入业务核心，测试策略需要从"代码正确"扩展到"数据与行为正确"。传统 CI/CD 流程关注的是构建、单测和集成测试，但 AI 系统的输出质量还取决于输入数据的真实性和上下文完整性。

Databricks Lakebase Postgres 提供的分支能力，可以看作是把数据库版本控制与测试流程打通的一种尝试。它让团队能够以较低成本获得"类生产"的测试环境，同时保留对数据的隔离控制。

当然，这套方案也并非零成本：分支的创建与管理、数据同步的时效性、以及权限与合规边界，都需要团队在流程上做出配套设计。对于处理敏感政府数据的 Hamlet 来说，如何在隔离分支中遵守数据治理要求，可能是一个需要持续投入的方向。

总体来看，Hamlet 用 Lakebase Postgres 分支测试变更的做法，为 AI 应用团队提供了一个可借鉴的工程范式：不要在生产与仿真之间二选一，而是用隔离的生产数据副本来验证真实世界的行为。