datainfra前沿动态 · Vol.100

DuckDB 2.0.0 以 LTS 身份发布，服务端、异步 I/O、VARIANT、触发器与 PEG 解析器一次打包；Databricks AI Runtime GA，把 GPU 训练收进湖仓治理边界；Lance 2.3 打出 v14.0.0-rc.1，btree 索引换行地址域、JSONB 转为自有实现；Google Cloud 同日给 Dataflow 补上跨区流式高可用

本期聚焦四条 10 月 21 日的进展，动作形状一致：把一道原本跑在系统外面、靠人或靠外部服务兜住的工序搬进系统内部——DuckDB 把服务端、异步 I/O、扩展托管与触发器搬进内核，Databricks 把 GPU 平台搬进 Unity Catalog 的治理边界，Lance 把格式契约冻结成 RC，Google Cloud 把跨区容灾、文档切分与元数据编目变成开关或函数。

DataInfra DuckDB LTS Quack 异步IO VARIANT PEG解析器 触发器 Databricks AI Runtime GPU Unity Catalog Lance 列存格式 Google Cloud Dataflow BigQuery Looker

本期四条动态全部落在 10 月 21 日这一天，来自两个开源项目与两个平台方，做的是同一件事：把一道原本要在系统外面绕一道的工序搬进系统内部，然后把搬进来带来的代价逐条写在明面上。DuckDB 发布 2.0.0 LTS「Cinnamon Teal」，距 1.5 累计近 20,000 次提交，把客户端-服务端模式、异步 I/O、一等公民的 VARIANT、触发器、PEG 解析器与自托管扩展仓库一次性收进内核，代价是存储格式单向不兼容——2.0 之前版本读不了 2.0 写的文件。Databricks 宣布 AI Runtime GA，把 GPU 采购、健康检查、环境缓存与可观测性收进湖仓，代价是 GPU 工作负载从此落在 Unity Catalog 的权限与 serverless 隔离语义之内。Lance 打出 v14.0.0-rc.1，2.3 格式从 beta 进入 RC，代价是一份含 8 条破坏性变更的公开清单，其中 btree 标量索引换行地址域会直接打乱在 crate 之外自建索引的做法。Google Cloud 同日在发布说明里给出三项：Dataflow 流式高可用让后端状态跨区复制、BigQuery 的 AI.CHUNK_DOCUMENT 转 GA、Looker 元数据自动编目进 Knowledge Catalog 转 GA，代价分别是强制区域放置与资源计费、依赖 Document AI layout parser、血缘集成仍留在 Preview。

DuckDB 2.0.0 LTS：把服务端、异步 I/O、VARIANT、触发器与 PEG 解析器一次收进内核

事件概述

10 月 21 日，DuckDB 团队发布 2.0.0，代号「Cinnamon Teal」（Spatula cyanoptera），并明确这是一次长期支持版本。官方博文的定性很直接：1.0 是关于稳定性与向后兼容的，2.0 首先是特性版本。累计提交数接近 20,000，起点是 DuckDB 1.5。

版本线一并变成三条。2.0 是 LTS，支持至至少 2027 年 10 月；上一个 LTS 版本 1.4 仍支持到 2026 年 11 月下旬；为了让迁移有足够测试窗口，1.5 的支持期被延长到 2027 年 3 月，实际上也被转成 LTS。客户端侧 CLI 与 Python 已可用，Go、R、Java 与部分扩展因为改动较大、需要额外评审，会晚几天。

发布形态上的另一个变化是 DuckDB 第一次以「服务器」的身份出现。Quack 协议在 1.5.3 引入，2.0.0 交付的是打磨过的版本，并新增 CONNECT 语句；CLI 也配套了 -serve 与 -connect。

技术解析

  • Quack 与 CONNECT：服务端用 CALL quack_serve(token = 'my_token') 起，客户端 ATTACH 'quack:localhost' AS qk (TOKEN 'my_token') 后 CONNECT qk 即可切过去。默认只监听 localhost；跨机器访问的建议做法是保持 localhost 并置于 TLS 终止反向代理之后，allow_other_hostname 这个直接暴露服务端的选项仅供测试。CONNECT 不限于 Quack，也指向任何支持它的远端库（PostgreSQL、MySQL），配套的新 remote pushdown 优化器会把查询直接推到远端，而不是把表拉过网络。
  • 异步 I/O：2.0 为 Parquet、CSV 与 DuckDB 自有存储格式引入异步 I/O。I/O 层现在独立于查询处理层扩展，后台发出读请求并保持多个请求在飞，远端读的并行度大幅提升，对象存储（s3://）上的查询显著变快。设计细节在 7 月 31 日的专门博文里，官方在其中给出了开启前后网络吞吐随查询时间变化的对比。
  • VARIANT 成为一等公民：1.5 引入 VARIANT，2.0 完成全面整合——检测数据中的公共结构并做 shredding，压缩与执行都走列式路径，端到端从存储里的 shredded 执行一直到 Parquet 的 shredded 读写，背后是 variant_* 函数族。它与 JSON 的差别在于不是文本格式：'{"user": {"id": 42}}'::JSON::VARIANT 之后，variant_type() 与 variant_keys() 直接作用在类型化值上。
  • CLI 的 agent 模式：编码 agent 越来越多的场景下，2.0 的 CLI 会检测自己是否被 agent 驱动，然后切进 agent 模式——输出紧凑 Markdown 表而不是填充对齐的方框、明确声明结果被截断、提前终止失控查询、用 JSON 报告错误。长时间运行的 SQL 会先报出预估代价，让 agent 判断是否等待。官方在 TPC-H 上的实验结果是：agent 模式下模型需要读的 DuckDB 输出量减少 59%。手动测试可用 -agent，反向可用 -no-agent。
  • PEG 解析器转正：DuckDB 一直用派生自 PostgreSQL 的解析器，2.0 里自家现代可扩展的 PEG 解析器（1.5 中以可选项形式首次出现）成为默认。扩展现在可以挂进语法本身，错误信息带精确源码位置。官方说明它被设计成与旧解析器兼容，如果发现问题可以 SET enable_legacy_parser = true 退回（对应 legacy_parser 扩展）。换掉的理由写得很具体：旧解析器自 2018 年第一个提交起服役，语法用 YACC/Bison 生成，产出的是 LALR(1) 解析器，DuckSQL 每加一点语法都可能与既有规则冲突并引发 shift/reduce 或 reduce/reduce 冲突；PEG 按书写顺序逐个尝试备选，加语法不再有破坏无关规则的风险。Python 在 3.9 换成 PEG 解析器，理由相同。
  • 自托管扩展仓库：2.0 交付了改动很大的 C API v2，暴露文件系统、表函数等组件给扩展，官方希望在标为稳定前先在实战中验证。配合它的是可信扩展仓库：SET allow_extension_repositories = 'allowed' 之后可 CREATE EXTENSION REPOSITORY my_repo WITH PREFIX 'https://extensions.example.org'，再 INSTALL AND LOAD my_ext FROM my_repo。仓库定义是一个名字、一个 URL 前缀与一个或多个被信任的 RSA 公钥；前缀可以指向任何 DuckDB 能读的位置（本地路径、https、s3）。CREATE 时 DuckDB 会取回公钥钉进仓库定义，并打印每个密钥的 SHA-256 指纹供带外比对。官方标注该功能仍在推进中，语法后续可能变。
  • 触发器：CREATE TRIGGER 支持 BEFORE 与 AFTER、FOR EACH ROW 与 FOR EACH STATEMENT、REFERENCING OLD/NEW TABLE 过渡表、同一事件挂多个触发器、被触发表上使用 RETURNING，以及 DROP TRIGGER。部分组合（BEFORE ... FOR EACH ROW、以及 UPDATE ... FOR EACH ROW）暂不支持。官方给的例子不止审计表：用插入与删除两个触发器增量维护一张物化聚合表，把 sum_age、num_people 与平均值一起存下来，删除时人数归零就删掉该国籍的行。官方把这一步表述为「离物化视图更近一步」——物化视图长期挂在路线图的未来工作里。
  • SQL 方言补充：$x 简写替代 getvariable('x')；数据修改 CTE 允许把 INSERT、UPDATE、DELETE、COPY 当作流水线步骤；NEAREST join 把 top-k 相似度搜索变成 join 子句；嵌套 schema（CREATE SCHEMA finance.reports）；JSON 修改函数 json_set、json_insert、json_replace、json_remove 返回修改后的副本；支持 SQL 标准的 FETCH FIRST；GROUP BY 中允许 UNNEST；MERGE 与 UPDATE ... FROM 在匹配到多行的情况下语义被明确定义。
  • 核心扩展：DuckLake 1.1 发布，含新规范与参考实现；Iceberg 扩展朝完整实现推进，新增 REST catalog 的 ATTACH 选项（从 namespace 推导表位置，或从 catalog 返回的 metadata-location 文件加载表元数据），并控制 URL 前缀与 namespace 分隔符；Delta 扩展可以用 CREATE TABLE 建 Delta 表（含分区与 Delta 表属性），支持 time travel，VARIANT 支持改进。
  • 迁移与内部变更：最可能出问题的是存储格式——2.0 之前的版本读不了 2.0 创建的数据库文件，2.0 能读写既有文件且这些文件仍可被旧版本读。官方建议先在影子系统上测，关键负载可以等 11 月的第一个补丁版。编译器要求从长期坚持的 C++11 提到 C++17，发布构建默认切到 Clang（Linux 与 macOS 上 DuckDB 与核心扩展均用 Clang，Windows 上 CLI 用 Clang、多数核心扩展仍用 MSVC）。ICU 库整体移除：时区、日历与排序改由 icu 扩展自己实现，时区数据直接从 IANA 数据库构建并压缩到约 45 kB，行为不变且更快。弃用三项：单箭头 lambda（x -> x + 1）默认禁用，改 lambda x: x + 1，可用 SET lambda_syntax = 'enable_single_arrow' 临时开启，该开关与语法在 v2.1 全部移除；amalgamation 构建弃用；osx_amd64 逐步退场（社区扩展不再为该平台构建，2.1 停止支持）。

行业影响

嵌入式分析引擎的边界在这一版被向外推了一大圈。Quack 与 CONNECT 让 DuckDB 从「一个进程里的库」变成「可以被多个进程共享的服务」，而 remote pushdown 又把联邦查询的代价从「搬数据」改成「推查询」，这两件事合起来会改变它在小型数据栈里的位置——过去它通常待在管道末端做本地计算，现在可以挂在中间做一层可远程访问的执行节点。异步 I/O 的意义同样在位置层面：I/O 层与执行层解耦之后，瓶颈从 CPU 核数转向并发请求数，对象存储上的分析不再需要先落盘。

代价也写得同样清楚。存储格式单向不兼容意味着任何把 DuckDB 文件当持久化产物保存的系统，升级路径是单向门；三条版本线并行意味着运维上要并行跟踪各自的支持期；C++17 与 Clang 的切换会影响自建与嵌入；osx_amd64 退场直接命中仍在 Intel Mac 上做开发的团队。官方把这些逐条列出来，并明确建议关键负载等一个补丁版，这种自我标注边界的做法本身就值得照做。

相关链接

Databricks AI Runtime GA：GPU 基础设施进入湖仓的治理边界

事件概述

10 月 21 日，Databricks 宣布 AI Runtime（AIR）正式可用，作者为 Tejas Sundaresan、Jianwei Xie、Mike Del Balso、Hanlin Tang、Julia Powell 与 Cynthya Peranandam。定位是把全托管的 GPU 基础设施直接放进 Databricks，让训练发生在企业数据已经在的地方。

官方给出的问题描述是：AI 团队花在抢 GPU 容量、处理故障、等待实验启动上的时间，往往多于改进模型的时间；把 GPU 基础设施与湖仓分开运行会带来治理缺口，并让敏感训练数据暴露在风险中；当编码 agent 开始驱动越来越多的训练实验时，这些瓶颈与风险一起放大。

采用侧的数字：数百家公司已在用 AIR 训练并上线深度学习模型，点名的有 Robinhood、PicPay、Merck、Flo Health、TinyFish 与 FactSet，场景覆盖医疗、制造与面向消费者的 agent；Databricks 自己的 AI Research 团队用它训练 KARL 与 AI Parse 背后的模型。可靠性口径是 100,000+ GPU 小时的训练运行。

技术解析

  • 托管范围：Databricks 接下 GPU 采购、集群配置与网络，用户按需拿到容量。健康保障的做法是在训练前、训练中以及空闲期周期性执行几十项 GPU 与网络检查，检测并移除不健康节点，目标是让负载可靠扩展到数百张 GPU。
  • 数据加载：内置 data loader 负责流式传输与缓存训练数据，减少等 I/O 的时间；官方点名 UCVolumeDataset 作为提升吞吐、免于自建加载管道的手段。
  • 秒级启动：官方把启动路径逐层优化，即使是有数十张 GPU、启用 RDMA 的大规模集群也能在秒级起来。机制是温 serverless GPU 池加懒加载镜像——不必像传统 GPU 栈那样先完整下载容器镜像再跑代码，剩余镜像数据在后台继续加载。环境缓存让环境只需构建一次。
  • 调试与可观测：MLflow 侧是一套新的可观测体验，日志在提交后几秒内流式返回，加 --watch 即可看；更深的排查走为多节点训练专门做的日志查看器。Genie Code 嵌入整个使用流程，分析 AIR 训练日志、定位问题并给出下一步建议，预置的 agent skills 里包含研究与性能团队发现的经验，例如把 Qwen 训练时间降到 1/6 的那次优化。
  • 治理与隔离：Unity Catalog 对 GPU 工作负载的各个方面（数据访问、checkpoint、日志）统一强制读写权限，让 GPU 平台与数据治理层说同一种语言。隔离层面强调 VM 级隔离，与那些暴露宿主内核的 GPU 隔离机制做对照，并支持 PrivateLink 与 serverless 出网控制。成本侧走 Databricks 计费系统表，可拿到 workload 级使用记录来定位 GPU 预算去向。
  • 编排与迁移：与 Lakeflow 原生集成，GPU 工作负载可与上下游管道保持同步；上生产只需多写几行 YAML，内建优先级与抢占以减少 GPU 空闲，配套 Genie ZeroOps 降低运维负担。从 Kubernetes 或 SLURM 集群迁移，官方称用 Databricks AIR Skills 一条自然语言提示即可。
  • 客户口径：Superhuman 的 Kostia Omelianchuk 给出的是从单机 8 张 A100 迁到多机 16 张 H100，训练时间从约 7 天降到 48 小时，即 3.5 倍加速。FactSet 的口径是把模型从搭建、训练到部署的时间从数天压到数小时。
  • 同日配套：10 月 21 日另有《Databricks AI Runtime and NVIDIA make it easier to customize open models with enterprise data》，讲的是与 NVIDIA 合作降低用企业数据定制开源模型的门槛。

行业影响

这条发布的重点不在「又一家提供托管 GPU」，而在 GPU 平台与数据平台合并后，治理边界被重新划了一次。过去训练栈与数据栈分属两套系统时，权限、审计与数据副本的一致性靠跨系统的配置与流程维持；AIR 把 checkpoint 与日志这类 GPU 侧产物也纳入 Unity Catalog 的权限模型，意味着训练过程的每一次读写都落到与数据表相同的策略上。在 agent 并发发起大量训练实验的场景里，这个差别会从「合规上更好看」变成「能不能靠策略自动管住」。

代价是把 GPU 调度的自由度交了出去：集群形态、镜像加载方式、健康检查节奏、日志与计费口径都由平台定义，习惯自建 SLURM/K8s 的团队需要用 AIR Skills 之类的迁移路径重做一遍工程；VM 级隔离与 serverless 出网控制也意味着网络访问方式要按 Databricks 的模型重新设计。这是一次典型的「用控制面换取运维面」的交换。

相关链接

Lance 2.3 进入 RC：btree 索引换行地址域，JSONB 收进自有 crate

事件概述

10 月 21 日 17:09 UTC，Lance 格式仓库打出 v14.0.0-rc.1 标签——这是 2.3 格式线的第一个 RC。changelog 的对比基准是 release-root/14.0.0-beta.N，累计 228 条。LanceDB 侧同日 10:48 UTC 打出 v0.41.0-beta.12。

本专栏在 Vol.99 已展开过 beta 线里的 planar 六段栈（#9920 → #9925）与 LanceDB 把 MemWAL 改名为 RTE 的那次破坏性变更。本期看的是 RC 这一步真正定下来的东西：一份包含 8 条破坏性变更、4 条关键修复的清单。RC 的含义是编码契约冻结，生态可以开始对齐；代价是清单里每一条都要有人去改。

技术解析

  • btree 标量索引换行地址域（#9481）：这是清单里对用户影响最直接的一条。btree 现在训练并存储物理行地址（_rowaddr）而不是 row id，与 ZoneMap、BloomFilter 对齐，从而可以与稳定行 ID 数据集上的 fragment-reuse index 共存。此前 FRI、稳定行 ID 与 row-id 域的组合对 btree 是 outright 拒绝的，原因是 FRI 作用在裸 row id 上会静默损坏它们。BTREE_INDEX_VERSION 提到 1；已存在的 row-id 域段仍能正确读取，且永不与地址域数据合并。PR 正文明确提醒：在 crate 之外自建 btree 索引的用户（例如通过 Spark 构建）需要修改列名，并确保读的是行地址而不是 row id，作者表示会在社区同步会上专门提出。
  • JSONB 转为自有实现（#9534）：Lance 把 JSONB 载荷持久化在 lance.json 列里，但字节布局与读侧语义（JSONPath、以及 json_get_int 这类严格转换）原本来自外部 jsonb crate。该 crate 的 semver 兼容版本改过可观察行为（0.5.6 重写了 to_i64 的取整），而 Lance 无法让编码与自己的文件格式一起演进。这次把 databendlabs/jsonb 的 fba895c vendor 成新的 lance-jsonb crate，lance-arrow、lance-datafusion、lance-index 一并切换。持久化布局不变，tests/it/compat.rs 把 0.5.6 在两条写入路径（parse_value 与 OwnedJsonb::from_str）上产出的字节，以及 decimal 与 extension 载荷的解码文本全部钉住。可观察差异只有一处：JSONPath 算术与过滤字面量现在走同一个编码器，decimal 编码输入上的算术保留 decimal 结果而不再转 f64——Lance 不写 decimal 载荷。
  • 索引插件拿到版本号（#9518）：把 index_version 传进 ScalarIndexPlugin::load_index。与 #9481 是同一组改动，索引插件现在必须知道自己在读哪个版本。
  • memtable 上的模糊合取（#9526）：支持带 fuzzy 匹配并用 AND 连接的 FTS 查询，在活跃 memtable 上求值。PR 正文记下一条已存在并被 ticket 化的限制：当配置了 max_extensions 时，它对每个 tier 单独生效，而 memtable、sstable 与基表各自的 FTS 索引语料不同，算出来的扩展词可能不一致；有提案是预建语料供查询使用，但那会在查询热路径上多一个 RTT。
  • v2.3 mini-block 的 offset 压缩（#8331）、Blob v2 写入与提升优化（#9717）、清理删除的并发可配置（#9774）、f32 l2/dot 内核只选一次并通过 _into API 批量填充（#10086）：前三条是格式与运维面，最后一条是线性代数层的破坏性提速。
  • 关键修复四条：#9760 展平嵌套 FSL 时使用每一层自己的 dimension；#9789 保留来自非精确标量索引结果的候选；#9865 把 overlay 里的陈旧行纳入 indexed merge insert；#10145 修 RLE 压缩的 mini-block 字典值读取。
  • 查询与格式侧的新增：#9331 支持 SQL IS [NOT] DISTINCT FROM 作为空安全比较；#9750 在 top-k 下对非排序列做延迟物化；#9611 在稳定行 ID 表上为延迟压缩记录行地址移动；#9871 让 optimize_indices 可以分布式执行；#9878 定义 provider-managed clustering 元数据；#9967 加实验性 PCA 模型与查询预变换。
  • 回退两条：#9885 撤销过早的稳定化（spilled row lineage），#9889 回退 JSONB 逻辑与物理存储的文档说明。RC 前把没准备好的东西撤掉，与 Vol.97 里 PostgreSQL 19 那批回退是同一种动作。

行业影响

列存格式的 RC 与应用程序的版本不同：它是给整个生态的信号，告诉所有读写这个格式的引擎可以开始对齐了。Lance 的处境特殊之处在于它还是 AI 工作负载的存储层——向量索引、FTS、blob 与结构化列挤在同一份格式里，任何一条编码变更都会一并打到检索与分析两条路径上。这次 RC 里的 #9481 就是典型：为了让 btree 与 fragment-reuse index 共存，索引的取值域被换掉，代价转嫁给所有在 Rust crate 之外构建索引的集成方。

值得注意的还有 #9534 的处理方式。外部依赖在 semver 兼容范围内改了可观察行为，这在依赖管理上是常见困境；Lance 的选择不是锁版本，而是把代码 vendor 进来、把字节级兼容测试钉住，换取编码与文件格式同步演进的自由。这条路径的成本是长期维护一份 fork，收益是格式演进不再受上游节奏牵制——对一个把字节布局当契约的项目来说，这笔交换是划算的。

相关链接

Google Cloud 同日三项：Dataflow 跨区流式高可用、BigQuery 文档切分 GA、Looker 元数据编目 GA

事件概述

10 月 21 日的 Google Cloud 发布说明里，与数据基建直接相关的有三项，分属三个产品。

Dataflow 的流式高可用进入 Preview。文档把问题说得很具体：默认情况下 Dataflow 流式作业的部分后端资源跑在单个 Compute Engine zone 里，zone 级故障期间这些作业会丢数据。开启流式高可用后，后端状态跨区域内的多个 zone 复制，单 zone 故障不再导致作业中断——作业从 zone 级资源变成区域级资源。

BigQuery 的 AI.CHUNK_DOCUMENT 函数转 GA。这是一个表值函数，把非结构化文档切分为语义连贯的文本块，切分依据是文档版面结构而不是字符数或词数。

Looker 侧是 Knowledge Catalog 对 Looker（Google Cloud core）元数据的自动编目与摄取转 GA，粒度更细，资产类型更多。

技术解析

  • Dataflow 流式高可用的五条约束：第一，必须使用 Streaming Engine，作业必须是流式管道。第二，Compute Engine worker 必须使用区域级放置；如果作业只在某个特定 zone 里有 worker，那个 zone 不可用时作业依旧无法处理数据——后端状态虽然复制了，worker 也没了，开启后 Dataflow 会拒绝指定了具体 worker zone 的作业（--workerZone、--worker_zone 或 --zone）。第三，只能在创建作业时开启，不能通过原地管道更新开关；要改运行中管道的这项设置，得走 automated stop-and-replace 更新，或者 stop/drain 后不带 --update 重启。第四，额外的 watermark 延迟：开启后 watermark 只在数据先被处理、再被跨 zone 复制之后才推进，会有几秒额外延迟。第五，强制资源计费且永不走 data-processed 计费，Preview 期间不额外收费。
  • 开启方式：Java 用 --dataflowServiceOptions=requires_high_availability，Python 与 Go 用 --dataflow_service_options=requires_high_availability；gcloud 跑模板或 Flex Template 时是 --enable-streaming-engine 加 --additional-experiments=requires_high_availability。
  • AI.CHUNK_DOCUMENT 的工作方式：底层用 Document AI layout parser 分析文档结构（标题、章节、段落、列表、表格），并跨结构边界保留语义上下文，产出面向向量嵌入与 RAG 工作流优化的块。BigQuery 自动配置并管理 layout parser，无需创建或训练模型；每个项目只用一个 processor（名为 bq-created-layout-parser），避免跨查询重复开通。输入三种形式：Cloud Storage URI 字符串字面量（目录路径末尾支持单个 *，也可按扩展名过滤）、含名为 ref 的 ObjectRef 列的对象表、返回 ref 列的子查询。可选参数有 connection_id 与 chunk_size。使用该功能需要先启用 Document AI API。
  • Looker 侧：GA 的范围是自动编目与摄取，包含更细粒度的元数据（dimension/measure 定义、默认查询、关系）与新的资产类型（LookML 仪表盘、LookML 仪表盘元素、agents）。数据血缘集成仍是 Preview。

行业影响

这三项的共同点是把原本要在管道外面补的工序收进平台。流式高可用对应的过去做法是靠作业重启与重放兜住 zone 故障，代价是数据处理语义上的不确定；现在它是创建作业时的一次开关，代价是五条约束——其中「强制区域放置」与「强制资源计费」是实打实的架构限制，前者会让指定了 worker zone 的既有作业被拒，后者会改变计费模型，从按处理数据量变成按资源。AI.CHUNK_DOCUMENT 对应的过去做法是在管道里自己写切分逻辑，按固定长度硬切；换成版面感知的切分之后，检索质量的上游决定权从自己的代码转给了 Document AI layout parser，也就继承了它的文件格式支持范围与限制。Looker 元数据编目对应的过去做法是靠人维护资产清单，现在的代价是血缘这一环还没跟上，仍留在 Preview。

把三者放在一起看，Google Cloud 这一天的动作是把「可靠性」「RAG 前置处理」「元数据目录」三件长期被当作周边工具的事，变成平台的原生能力。对已经在用这些产品的团队，取舍点不在功能本身，而在那些被写进约束里的代价是否可接受。

相关链接

编者评

本期四条动态落在同一天，形状却完全一致：把一道原本跑在系统外面、由人或外部服务兜住的工序搬进系统内部，然后把搬进来带来的代价逐条写清楚。DuckDB 把服务端、异步 I/O、扩展托管与触发器搬进内核，代价是存储格式单向不兼容、编译器提到 C++17、三条版本线并行、osx_amd64 开始退场。Databricks 把 GPU 平台搬进湖仓，代价是 GPU 工作负载的调度与网络方式都要按平台的模型重做。Lance 把格式契约冻结成 RC，代价是一份公开到 PR 级别的破坏性清单，其中 btree 换域这一条直接要求 crate 之外的集成方改列名与读取方式。Google Cloud 把跨区容灾、文档切分与元数据编目变成开关和函数，代价写成了五条约束、一个外部 parser 依赖与一个仍在 Preview 的血缘环节。

四处代价的共同点是都可以提前核对——不需要等到故障发生才知道。这是一条与 Vol.99 一致的脉络：把「默认由谁负责」重新指派一次，并要求每次交接留下可核对的凭据。DuckDB 留下的是发布日历上三条版本线的支持期与一个明确建议（关键负载等 11 月的补丁版）；Databricks 留下的是 Unity Catalog 对 checkpoint 与日志的权限记录与计费系统表里的 workload 级用量；Lance 留下的是 RC changelog 里的 PR 号与 compat 测试钉住的字节；Google Cloud 留下的是文档里逐条列出的限制与 Preview 期间的计费说明。工程上的含义是，选型评估可以不依赖厂商的承诺，而是读这些凭据本身。

本期还需要交代几处没有单独立篇但值得记录的观察。中文源方面，阿里云官方博客、阿里云开发者社区大数据页、火山引擎文档站与火山引擎开发者社区四个入口在 10 月 21 日至 22 日仍然解析不出可确认日期的发布条目，这是本专栏连续第 19 期遇到同样情况；本期改以开源侧的国产项目作为观察点——MatrixOne 在 10 月 21 日打出 v4.2.6-hotfix-20261021 与 v4.1.6-hotfix-20261021 两个 hotfix 标签，Doris 仍停在 10 月 15 日的 4.1.5，Paimon、Amoro、Kyuubi、Linkis、InLong 在窗口内均无新版本。AWS 侧 10 月 21 日的 what’s new 共九条，全部落在 Connect、Direct Connect、Aurora/RDS、Cognito、SageMaker、Neuron、CloudWatch 等方向，没有一条属于数据基建主线；AWS Big Data Blog 最新仍停在 10 月 19 日。开源侧另有 ClickHouse 在 10 月 21 日发布 v26.9.24.8-stable 与 v26.8.33.10-lts 两个分支，release body 为空；Ray 的 2.58.1 与 2.57.1、dbt State 的永久免费档已在 Vol.99 记过，本期不重复。

本专栏这一期是第 100 期。回看这 100 期的取材，一个稳定的变化是：厂商越来越少地把能力发布成「一个新产品」，越来越多地把过去散落在文档、最佳实践与人工经验里的边界，写进版本说明、迁移指南与限制清单。对读者而言，最有价值的信息往往不在标题里，而在那些被显式写出来的代价条目中。