Lakebase branching for CI/CD: lessons from 100 PR databases

Lakebase 分支用于 CI/CD：从 100 个 PR 数据库中获得的经验 | Databricks 博客

跳至主要内容

行业

2026 年 10 月 31 日

Lakebase 分支用于 CI/CD：从 100 个 PR 数据库中获得的经验

按需复制分支使生产数据的隔离副本在 CI/CD 测试和智能体用例中既快速又经济。

作者：Yasamin Tari 和 Kartik Mathur

摘要

• Snorkel AI 的 CI/CD 流水线为每个开放的拉取请求分配一个 Lakebase Postgres 分支，这是生产数据的完整读写副本，可在不到一分钟内准备就绪，而非 30 分钟或更长时间，因此他们从未能够实现每个 PR 的复制。

• Lakebase 分支采用按需复制机制，因此在约 2.5 TB 的生产数据集上同时运行 100 个 PR 数据库时，仅需为每个分支修改的数据增加存储空间。分支过期（TTL）机制会在 PR 完成时自动清理每个分支，因此存储空间始终保持在生产数据大小加上活跃 PR 修改量的水平。

• 私有连接和 Okta SSO 支持提供受控且安全的环境

#### 问题：测试生产数据不应耗时超过 30 分钟

Snorkel AI 为 AI 团队构建数据开发工具，被专家数据标注人员和前沿模型提供商使用。在此特定用例中，Snorkel 通过基于 Kubernetes 的 CI 流水线分发代码。每个开放的拉取请求以及临时提交都会获得自己的临时 Kubernetes 命名空间（“PR 命名空间”）。开发人员在该命名空间中部署自己的分支，并在合并前运行完整的测试套件。

这些测试在运行真实数据时最有价值。Snorkel 的生产数据库是 Amazon Aurora PostgreSQL 集群。为每个 PR 命名空间提供该数据库的副本是关键难点。复制一个副本需要每个环境约 20 分钟，这对于开发人员全天候提交 PR 且每次运行都需要一个新环境的合并队列来说太慢了。其他替代方案（共享的预发布数据库、裁剪的测试数据集或合成数据）又回到了生产环境测试本应解决的问题：测试相互干扰、模式过时以及仅在真实数据结构下才会出现的错误。

#### 成功标准

如果 Lakebase 能够满足以下标准，Snorkel 将认为其在 CI/CD 中是成功的：

• 快速部署：新 PR 分支可在 60 秒内准备就绪（第 95 百分位）。

• 可扩展性：高峰期约 100 个并发 PR 分支，每个分支均可独立读写。

• 兼容性：现有应用程序和 CI 测试套件可通过标准 Postgres 连接到 Lakebase，性能与 Aurora 相当，并支持大型 JSONB/LOB 列。

• 数据新鲜度：通过持续的 DMS 复制，主分支与生产 Aurora 的时间差保持在约 2 分钟内。

• 安全性：生产数据始终位于私有网络中，不会通过公共互联网传输，开发人员使用 Okta SSO 登录，CI 流水线以服务主体身份进行身份验证。

#### 为什么数据库分支适合 CI/CD

Lakebase 是 Databricks 的无服务器 Postgres 数据库。其存储和计算相互分离，并支持分支：你可以像创建 Git 分支一样，从任何时间点创建数据库的新隔离可写分支。

分支采用按需复制机制。创建分支是一个元数据操作，因此创建分支时不会复制数据。新分支与父分支共享存储页面，仅当分支修改了页面时才会写入新的存储页面。对于 CI 来说，这意味着：

• 创建分支只需数秒，而非数分钟。这一过程与数据库规模无关。

• 存储空间随着每个分支所做的更改而增长，而非数据库的大小。Snorkel 的每个 PR 分支在约 1 TB 的基础数据上，仅产生约 5 到 10 GB 的更改数据。

• 计算资源按分支分配且可缩放至零。每个分支拥有独立的自动扩展计算资源，在 CI 运行之间可缩放至零。即使预置了 100 个分支，Snorkel 预计同时仅需 20 到 30 个分支处理流量，每个分支在峰值时处理约 5 次查询每秒。

#### 架构

1. 在主分支上保持生产环境的最新副本。Lakebase 是标准的 Postgres 数据库，因此可以作为 AWS DMS 的目标，无需自定义工具。Snorkel 将 DMS 任务指向其生产 Aurora 数据库，将其复制到 Lakebase 项目主分支：首先进行全量加载，然后通过持续的变更数据捕获保持主分支与生产环境的延迟在约 2 分钟内。全 LOB 模式可迁移 10 到 20 MB 的 JSONB 值。团队已经在运行 DMS，因此无需构建或维护新的复制流水线。主分支是每个 PR 分支的“黄金副本”。

1. 在 PR 提交时创建分支。当开发者提交 PR 时，CI 流水线调用 Lakebase API 从主分支创建新分支，设置其过期时间，并将分支的连接信息传递给 PR 命名空间。分支可在一分钟内准备就绪。

1. 在真实数据上运行测试。PR 命名空间中的应用程序通过标准 Postgres 连接到其分支。测试可以运行迁移、写入数据和修改模式，而不会影响生产环境、主分支或任何其他 PR。

1. 当 PR 关闭或测试通过时删除分支，TTL 作为兜底保障。当 PR 合并或关闭时，流水线会删除分支。如果清理步骤未执行，分支会在其 TTL 过期后自动删除。

$

/$

#### 安全性：私有网络连接与人和流水线的身份验证

两个安全需求排除了其他方案，因此值得单独说明。

私有连接。生产数据通过私有网络从 Aurora 传输到 Lakebase，并从 Lakebase 传输到 CI 集群，而非通过公共互联网。

身份验证。Snorkel 有两种类型的数据库用户：连接到 PR 环境进行调试的交互式开发者，以及无需人工参与的 CI 流水线。Okta SSO 围绕交互式浏览器登录构建，因此我们按用户类型拆分设计：

• 开发者：Okta 与 Databricks 账户联邦，用户通过 SCIM 配置。开发者使用常规的 Okta 身份登录。

• CI 流水线：每个 PR 命名空间作为 Databricks 服务主体运行（按团队或仓库范围限定），同样通过 SCIM 配置。PR 容器使用服务主体的凭证通过 Databricks SDK 获取 Lakebase 的短期 OAuth 令牌，并在长时间测试运行期间刷新这些令牌。CI 中不存在长期有效的数据库密码。

• 审计：Postgres 审计日志记录每个查询的服务主体身份，因此每个查询都可以追溯到执行它的流水线。

#### 为什么复制写入和分支过期能保持 CI 快速且低成本

Lakebase 的两个特性使这种模式在大规模场景下可行：复制写入分支和分支过期（TTL）。

写时复制技术使分支创建变得即时。新分支无需复制任何数据，而是指向父分支已有的存储页面，仅当分支修改页面时才会写入新的存储。从约1 TB的生产副本创建分支所需时间与从1 GB数据库创建分支相当：仅需数秒，而非传统完整恢复所需的约20分钟。每个PR命名空间都能立即获得一个独立且可写入的生产环境副本。

写时复制技术使分支成本低廉。每个分支与主分支共享大部分数据，因此存储空间增长取决于每个分支的修改量，而非数据库整体大小。对于Snorkel而言，每个PR分支在共享基础之上仅需约5至10 GB存储。计算资源按分支分配，空闲时可自动缩至零，因此只有正在运行测试的分支才会消耗计算资源。

分支过期机制确保长期成本可控。写时复制在分支生命周期较短时效果最佳。分支会保留创建时的数据版本。随着DMS持续将生产环境变更同步到主分支，长期保留的分支会持续持有这些旧数据页面，导致存储占用逐渐增加。为每个CI分支设置TTL（生存时间）后，分支在对应PR完成后会自动删除。这使存储空间始终保持在生产基础规模加上活跃PR修改量的水平。

#### 相同模式适用于AI代理

PR命名空间并非唯一需要生产环境临时副本的工作负载。执行SQL、运行迁移或修改数据的AI代理同样需要安全的测试环境，而写时复制分支正好满足这一需求。

每个代理任务对应一个分支。每个代理运行都会获得主分支的独立分支。代理可以读取真实数据、对其进行修改，甚至更改模式，而不会影响生产环境或其他代理的工作。无论数据库规模大小，创建分支仅需数秒，因此为每个任务创建分支是切实可行的。

并行运行多个代理。存储空间仅随每个分支修改的页面增长，每个分支的计算资源在空闲时自动缩至零。并行运行数十个代理的成本与其修改量相当，而非数十个数据库副本的开销。

审查修改或直接丢弃。团队可以在将分支变更应用到生产环境前，检查代理在分支上所做的修改。如果结果不符合预期，只需删除分支，无需回滚操作。

TTL机制清理代理产生的分支。代理可能创建大量短期分支。每个分支的过期机制会自动删除被遗弃的分支，与TTL清理CI分支的方式相同。

为代理设置作用域身份。如同CI流水线，代理可通过带有短期OAuth令牌的服务主体运行，确保每个代理执行的查询均可在审计日志中追踪。

#### 成果

• 部署时间：之前超过30分钟，使用Lakebase后低于60秒 [VERIFY p95测量值]
• 扩展性：针对约2.5 TB生产数据集设计支持约100个并发PR分支
• 兼容性：CI套件在Lakebase上运行"无重大兼容性问题" / 性能与Aurora相当
• 采用情况：在团队中推广至60至70名开发者
• 开发者评价："此前我们必须物理复制数据，这些复制任务耗时数小时且经常遇到与各种CI平台（GitHub Actions、Circle CI等）的网络及其他瓶颈。我们寻找一种解决方案，即使数据离开VPC也能满足我们的安全和合规要求"

#### Lakebase在CI/CD中的分支最佳实践

• 每个拉取请求对应一个分支，从持续同步的主分支创建。

• 始终设置生存时间（TTL）。将过期处理视为必需项而非可选项。根据拉取请求或测试运行的常规持续时间进行匹配。

• 优先创建新分支而非复用旧分支。如果某个拉取请求需要更新的数据，直接从主分支创建新分支。整个过程只需数秒。

• 允许计算资源扩展至零。大多数预分配的分支在任意时刻都处于空闲状态。

• 管道流程使用服务主体和短时效OAuth令牌进行认证，人员访问则采用单点登录（SSO）。

• 监控每个分支的存储使用情况，以便及时发现长期存在的分支。

准备好为每个拉取请求分配一个生产环境级别的数据库了吗？立即使用Lakebase，阅读分支管理文档，在您的CI流水线中配置分支过期策略。

相关标签：

技术

订阅以获取最新文章

订阅我们的博客，即可将最新文章发送至您的邮箱。

立即订阅

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"