datainfra前沿动态 · Vol.109

Databricks 用 Lakebase 写时复制分支在 Snorkel AI 的 CI/CD 上跑通生产验证：2.5TB 生产库挂 100 个并发 PR 分支，环境准备从 30 分钟以上压到 60 秒内；阿里云 CloudJump III 落地 SIGMOD 2026，分层存储决策从块层拉回引擎内部，定格在缓冲管理器的逐出与刷盘两个控制点，快照 0.64 秒；阿里云为 Agent 时代的数据库安全划四条边界，Agent Data Gateway 给每个 Agent 发独立身份与行列级权限

本期聚焦对「正在变化的数据」做决策的位置迁移：CI 测试用的副本不再复制数据只动分支元数据，冷热分层不再依赖外部块层痕迹而收进缓冲管理器，Agent 访问不再借用人类账号而在网关处获得身份、限额与审计链

DataInfra Lakebase Postgres CI/CD Copy-on-Write CloudJump 分层存储 SIGMOD Agent安全 阿里云 Databricks

数据库基础设施本周的三个动作指向同一件事：把对”那份正在变化的数据”做决策的位置，从外部系统搬回数据路径上最天然的观察点。Databricks 把生产数据副本的成本压成一次元数据操作，让每个 PR、每个 Agent 任务都能拥有可写的生产级环境；阿里云 ApsaraDB 把 CloudJump 系列的第三篇写进 SIGMOD 2026，冷热分层的判断不再让看不见引擎内部状态的块层工具猜；同一来源的另一篇文章承认了一个正在成形的现实——数据库最大的用户正在变成 Agent，安全模型需要围绕”每连接有身份、每动作有限额、每次访问可回溯”重建。

Lakebase 写时复制分支进 CI/CD：Snorkel AI 100 个 PR 数据库的生产课

事件概述

10 月 31 日，Databricks 发布 Lakebase branching 在 CI/CD 场景的生产案例。主角是数据开发工具厂商 Snorkel AI：它的 CI 流水线建在 Kubernetes 上，每个打开的 PR 会拿到一个临时 namespace，开发者把分支部署进去跑完整测试套件。测试要有价值就必须跑在真实数据上，而它的生产库是 Amazon Aurora PostgreSQL——给每个 PR 复制一份环境，单次恢复约 20 分钟起步，整体常超过 30 分钟；用物理拷贝的旧方案动辄数小时，还在 GitHub Actions、CircleCI 等各平台上反复撞网络瓶颈。复制环境慢到无法按 PR 粒度开通，团队只能退回共享 staging、裁剪 fixture 或合成数据，而这些恰恰是”类生产测试”本要解决的问题：测试互相干扰、schema 过期、只在真实数据形态下才出现的 bug 全都回来了。

换成 Lakebase 后，每个打开的 PR 调用 Lakebase API 从 main 分支拉出一个 Postgres 分支，60 秒内（p95）可用。Snorkel 的生产数据集约 2.5 TB，峰值约 100 个并发 PR 分支，每个分支独立读写，同一时刻真正承接流量的只有 20 到 30 个、各约 5 QPS 峰值。方案已推广到 60 至 70 名开发者。

技术解析

  • 分支是元数据操作：Lakebase 分支写时复制（copy-on-write），创建分支只写元数据、不搬数据，新分支与父分支共享存储页，只有被改动的页才落为新存储。从 1 TB 库建分支与从 1 GB 库建分支耗时一样，都是秒级。每个 PR 分支在约 1 TB 基础上只新增 5 到 10 GB 变更页。
  • main 分支持续同步生产：Lakebase 是标准 Postgres，直接当 AWS DMS 的目标端，全量加载后由 CDC 持续复制，main 与生产 Aurora 的差距保持在约 2 分钟内；Full LOB 模式承载 10 到 20 MB 的 JSONB 大对象。团队本来就在跑 DMS，没有新管道要维护。
  • TTL 不是可选项：分支持有创建时刻的数据版本，DMS 持续更新 main 时，老分支累积的旧页会越攒越多。给每个 CI 分支设过期时间（TTL），PR 结束即回收，存储总量才能稳定在”生产基础 + 活跃 PR 变更”的水平。文章把”永远设 TTL”列为第一条最佳实践。
  • 身份双轨：开发者走 Okta SSO 联邦加 SCIM 供给；CI 流水线按团队或仓库粒度跑 Databricks service principal，用 SDK 换短时 OAuth 令牌并在长测试中自动刷新，CI 里没有长寿命数据库密码。Postgres 审计日志按 service principal 记录每条查询，任何一次访问都能追到具体流水线。
  • 同一模式外溢给 Agent：每个 Agent 任务一个分支，Agent 可读真实数据、写数据、改 schema 而不碰生产；几十个 Agent 并行的成本约等于各自改动的页数；人在合并前审查分支上的变更，不满意就删分支，无需回滚。这与 10 月 9 日报过的 Agentic SDLC 文章（Vol.88）一脉相承，本期新增的是 CI 流水线侧的规模化实测数字。

行业影响

这篇案例把”数据库分支”从特性演示推进到了有数字的工程验证：环境准备 30 分钟以上对 60 秒内、100 并发分支只付增量存储、TTL 兜底防漂移。对数据库厂商而言，CI/CD 与 Agent 是同一个需求的两张面孔——两者都要”一次性、可写、接近生产”的数据环境，谁能把这种环境的创建成本压到元数据级别，谁就把测试环境和 Agent 沙箱这两块预算拿到了自己手里。Snorkel 的选型理由里”数据不出 VPC 也能过安全合规”排在前面，说明这类方案的落地门槛已经从性能转移到了身份与审计的设计完整性上。

相关链接

CloudJump III 落地 SIGMOD 2026：冷热分层从块层工具的猜测收进缓冲管理器

事件概述

10 月 30 日，阿里云 ApsaraDB 发布 CloudJump III 解读文章，论文已被 SIGMOD 2026 接收。这是该系列的第三篇：CloudJump（VLDB 2022）解决存储介质从本地盘换到云存储后的 I/O 路径重设计，CloudJump II（SIGMOD 2025）用 Multi-Version Data 解决共享存储下多计算节点的一致性，CloudJump III 回答下一个自然问题——云存储从来不是单一介质，而是本地 NVMe、ESSD 网络块存储、OSS 对象存储构成的层级，数据库如何在动态 OLTP 负载下把热数据放快介质、冷数据放便宜介质，还保住性能与正确性。文章开篇给出动机：数据量持续增长后，含 DRAM 在内的存储成本已是数据库服务 TCO 的主导项，“要不要分层”不再是问题，“怎么分层”才是。

现有分层方案的共同短板是都跑在数据库内核之外——dm-cache、bcache、LVM Cache 这类主机侧缓存，ILM/HSM 管道，存储阵列与云服务的自动分层。它们看得到 I/O 模式，看不到存储引擎的内部状态，而正确的分层恰恰依赖后者。

技术解析

  • 外部分层为什么系统性误判：最热的页驻留在 DRAM 缓冲池里几乎不产生外部 I/O，基于 I/O 痕迹的分析会把它们判冷；结构性关键的索引页与元数据页被过早下沉；ILM/HSM 粒度太粗，一次小读触发整个文件或大区间的召回，周期性批量迁移与前台 I/O 抢带宽形成召回风暴；数据搬移不配合 LSN 语义与快照协议，零停机场景下的正确性难有保证。分层之后每次快层未命中都要付同步取回的代价，抖动不可控。
  • 四层架构与逐出中心设计：InnoDB 缓冲池（DRAM，热页与分层决策触发点）、BPE（本地 SSD，缓冲池只读扩展，属易失缓存层，丢失不影响持久性）、OSS Buffer（ESSD，吸收脏页刷盘，把页级更新聚合成块级写入并先行落地）、OSS（2 MB 对象即 128 个 16 KB 页，追加式版本化 PUT）。放置决策只发生在缓冲管理器的两个天然控制点——逐出与刷盘，用的是只有引擎看得见的元数据：页类型与生命周期、页表关系与配额、临时表识别、脏页状态、缓冲池驻留情况。
  • S3-FIFO 式幽灵准入：DRAM 缓冲池旁挂一个只存页 ID 的幽灵列表，从 old 子链表逐出的页先进幽灵列表，再次被访问证明有复用价值才准入 SSD。消融实验里，相比全量准入，幽灵准入让 TPS 提升 12%，命中率从 63.4% 升到 72.7%，BPE 写 IOPS 从 22369 降到 2082、降幅约 91%。工程细节：64 GB BPE 实例仅需约 184 MB 控制元数据，空间按 64 MB chunk 在线秒级扩缩，热实例可临时扩缓存再释放。
  • 交叉写序与快照版本化：OSS Buffer 的崩溃一致性靠一对互补约束——本地写先记元数据再写数据（记录意图），远端同步先传数据再标清元数据，两条恢复路径都幂等。备份走快照版本化协议：全局版本号在备份启动时短暂加锁递增，之后每个被修改的 2 MB 对象写出新版本、旧版本留给备份读，配合 OSS fast-copy 只复制对象元数据不搬数据，几个 TB 的表建快照也只要秒级。实测快照 0.64 秒，接近 ESSD-only 路径的 0.52 秒，远快于 OSS-only 路径的 53.73 秒。
  • 实测结果：小配置（8 核、1 GB 缓冲池、50 GB 数据）与大配置（64 核、100 GB 缓冲池、5 TB 数据），快层覆盖数据集 5% 到 50%，负载含 Sysbench、YCSB（Zipf 偏斜 0.8 到 2.0）、Voter 与一个真实游戏客户的大 BLOB 突发写负载。中等偏斜（Zipf α 不低于 1.4）下 20% 到 30% 缓存比例即接近 ESSD-only 吞吐上限；真实游戏负载全程在基线 ±5% 以内，中等并发下还快 3% 到 4%。

行业影响

文章的三条经验比数字更有分量：快层应当是全局共享缓存而非按表划分的专用存储；逐出中心的被动放置胜过带预测模型的主动迁移（迁移线程自带锁层级，与缓冲池锁交互有死锁风险，带宽仲裁在突发时会饿死一方，迁移中途崩溃还要额外恢复路径）；分层必须与恢复和备份协议协作，放置变更只改页的物理位置、与 LSN 标识的逻辑版本正交。对照 Aurora 路线，CloudJump 系列不建自己的 page-server 层，把复杂度留在引擎、把存储层保持简单通用，存储介质的进步可以直接吃到。对做自建数据库内核的团队，这篇给出了一个可复用的判断：分层的正确性问题（召回风暴、崩溃一致性、零停机备份）多数源自决策位置放错了地方，搬进内核的自然控制点后，问题形态会从”难测的竞态”退化成”可枚举的约束”。

相关链接

数据库最大的用户变成 Agent：四条边界与一个网关

事件概述

10 月 30 日，阿里云社区发布数据库安全主题文章，切入点很直白：数据库安全过去是关于人的——DBA 有账号、应用有账号、权限授予身份、审计追溯到身份。当 Agent 成为主要用户，三个盲区随即打开：Agent 用的是谁的账号、权限怎么发的、出事能不能追到那个 Agent；Agent 日复一日对数据库做了什么，有没有人在看、有没有记录；数据库的攻击面变了，凭证散落在代码、配置文件和 Agent 自己的记忆里。文章把阿里云数据库产品在 Agent 场景下的能力组织成四条边界：每条连接有身份、每个动作有限额、风险能被浮出、数据层有防御。

需要说明的是，这是一篇解决方案页面性质的文章，把既有产品串成矩阵，价值不在单品发布，而在它标记的厂商判断：「Agent 访问数据库」值得作为一个一等安全场景来组织产品。

技术解析

  • Agent Data Gateway：坐在 Agent 与数据库之间，每个 Agent 有自己的身份与令牌，权限收敛到库、表、列、行四级；数据库凭证留在网关内、不进 Agent 之手。网关在访问路径上，审计日志把每次操作归因到发起它的那个 Agent。
  • DataGuard for Agent：免费公测，覆盖 Agent 侧行为——检查输入、工具调用、输出与会话，能直接拦截高风险操作而不只是记录。与网关形成分工：网关管”Agent 以什么身份碰库”，DataGuard 管”Agent 被注入后在干什么”。
  • 审计与风险可见性：引擎层只见数据库用户和源 IP、分不清人与 Agent，安全审计负责让流量可重建；PolarDB、ApsaraDB RDS、AnalyticDB、Tair、Lindorm 均已内置 AI 助手，把例行巡检和诊断部分交给助手；DAS Agent 周期性汇总异常、潜伏风险与优化建议。
  • 数据库之外的三道门：身份与凭证——IDaaS 的 ITDR/PAM 管账号权限，KMS Secrets Manager 管密钥凭证，按策略轮转让 Agent 连库的凭证路径始终明确可执行；数据外泄——Data Security Center 持续识别敏感数据异常读取，云防火墙的 Agentic NDR 盯数据出口通道、在批量外传前告警；云侧配置——CSPM 与 CIEM 持续扫错配与过度授权。

行业影响

这份矩阵的深层信息是凭证与归因模型的变化：人类交互登录（SSO、浏览器流）天然不适合无人参与的流水线与 Agent，短时令牌加服务身份正在成为两类非人类用户的统一答案——这与本期 Lakebase 案例里”开发者走 Okta SSO、CI 走 service principal 加短时 OAuth”的设计完全同构。两个方向合起来看，2026 年的数据库访问控制正在从”账号”迁移到”身份类型 × 令牌生命周期 × 审计归因”的三元组，谁先把 Agent 的身份、限额、审计做成一等原语，谁就拿到 Agent 工作流落库的守门权。

相关链接

编者评

三条新闻合起来读，是同一个判断的三次落地：对数据的决策应该发生在离数据最近、看得最清的位置。CI 环境的副本问题，Lakebase 的答案是别复制数据、只动分支元数据，让”每个 PR 一份生产数据”从奢望变成默认配置；冷热分层问题，CloudJump III 的答案是别让块层工具猜，把放置决策定格在缓冲管理器的逐出与刷盘——这两个点上引擎知道页的类型、脏净与亲缘关系，快照版本化顺手把零停机备份的正确性也收了进去；Agent 访问问题，阿里云的答案是别让 Agent 借人类的账号，在网关处给它自己的身份、行级权限与完整审计链。三个案例共同的动作都是删掉一层中间机制——复制管道、外部缓存、共享账号——把省下的复杂度换成引擎内部可枚举的约束。值得留意的是两条中文来源全部来自阿里云社区博客，且都是数据库主题；当英文侧的开源版本线（Iceberg 1.12.0、Trino 484、Delta 4.4.1、DuckDB 2.0.0 本周全部静默，Milvus 3.0.5 与 Materialize v26.48.2 只出了无说明的补丁）进入发布间歇期，云厂商的工程深度文章正在填补内容空档。Google Cloud 本周的周报条目（Knowledge Catalog 自学习富化与 Knowledge Studio 预览）与 10 月 23 日（Vol.101）报道的属同一系列，未作展开。