datainfra前沿动态 · Vol.107

Databricks 把 Real-Time Mode 收进声明式管道并 GA，毫秒级流不再需要另养一套引擎，自家基准比 Flink 快最多 92%；Google Cloud 用 Iceberg REST 联邦直查 Databricks 托管表，跨云不复制、元数据最快每 5 分钟刷新一次；阿里云把 Kafka 消息落 Iceberg 的摄入从 7 个自建节点压到 3 个，五类复杂度换归属而不消失；Lance v15 把六类索引的行地址域写进规范并给老 writer 加围栏，LanceDB v0.41.0 随之转 GA

本期聚焦 10 月 28 至 29 日四条动作，形状一致：把用户原本要自己长期维护的那一段搬进平台或格式内部——另养的流引擎、另复制的一份数据、另搭的摄入管道、另靠口头约定的兼容性。四处都把搬进去之后的代价留在明面上：联邦查询有刷新上界，托管摄入仍是预览，v15 主线仍是 beta。

DataInfra Spark Declarative Pipelines Real-Time Mode Apache Spark Databricks 流式计算 Apache Iceberg BigQuery Unity Catalog credential vending 跨云 ApsaraMQ Kafka 存算分离 湖仓摄入 Lance LanceDB 列存格式 行地址 ZoneMap

本期四条动态落在 10 月 28 至 29 日这两天，两处来自云厂商，一处来自阿里云云原生社区，一处来自开源格式项目，做的是同一件事：把用户原本要自己长期维护的那一段搬进系统内部。Databricks 把毫秒级流处理的那套执行路径收进声明式管道，原先为低延迟单独养一套 Flink 的理由被拿掉，代价是这套能力绑在 SDP 与 Databricks serverless 上；Google Cloud 把跨云查询的那份数据副本拿掉，BigQuery 通过 Iceberg REST 联邦与凭据分发直接读 Databricks 写进 GCS 的 Parquet，代价是可见性要等下一次元数据刷新，最快 5 分钟；阿里云把 Kafka 到 Iceberg 的摄入管道从 7 个自建节点压到 3 个，五类复杂度一项没少，只是换了归属，代价是产品形态仍处在公开预览、区域与实例版本都有限制；Lance 把六类索引的行地址域写进规范并给更老的 writer 加围栏，代价是这条 v15 主线还停留在 beta，且行序相关的改动刚被 revert 过一次。四处动作都把边界写在了明处，这正是本期值得读的地方。

Databricks 把 Real-Time Mode 收进声明式管道：毫秒级流不再需要另养一套引擎

事件概述

Databricks 在 10 月 29 日宣布 Real-Time Mode（RTM）在 Spark Declarative Pipelines（SDP）上正式可用。RTM 本身不是新东西——它在 2025 年 8 月进入公开预览，2026 年 5 月随 Structured Streaming 正式可用；这次变化的是承载它的那层壳：原先要用户自己拼 Structured Streaming 作业的低延迟路径，现在交给 SDP 的声明式 API 接管，依赖解析、增量处理、编排、失败恢复与数据质量约束一并沿用。

RTM 的做法是把微批这道边界拆掉：数据持续流过，全部查询阶段并行运行，一个阶段产出即传给下一个阶段。Databricks 给出的对照是自家基准——在真实客户的特征计算负载上，RTM 比 Flink 这类专用引擎快最多 92%；与传统微批架构相比，延迟改善最高 100 倍。同一套架构落到 Feature Store 上，Kafka 到在线特征存储的端到端 p99 延迟是 200 毫秒。

技术解析

  • 触发方式是一次配置加一个装饰器：管道模式必须设为 continuous，并打开 spark.databricks.streaming.realTimeMode.enabled；随后用 dp.create_sink() 声明输出目标，再用 @dp.update_flow 装饰器把 pipelines.trigger 设为 "RealTime"、target 指向该 sink。
  • 落地到在线存储走 ForEach sink：欺诈检测与实时个性化要的不只是算得快，还要算完立刻可查。SDP 允许自定义写入器注册为 foreach_sink 再接到 update_flow 上，特征在产出后数毫秒内进入 Lakebase、Redis 或别的 OLTP 存储，中间没有离线到在线的同步环节。
  • Serverless 把选型也一并拿掉：SDP serverless 下无需选机型、无需调集群规模，按查询实际用到的核心计费；RTM flow 一并继承 SDP 的无版本升级与低停机维护。
  • 路线图上的两项：把多条 RTM flow 打包进同一条管道，避免每条查询各自起一份资源，源与 shuffle 分区改由系统按负载自动调；以及原生 Lakebase sink，自带批写、自动重试与 Unity Catalog 托管的认证。

行业影响

这条公告的分量不在延迟数字，在它把”低延迟”从一类需要单独选型的能力降级成一条配置项。过去几年的默认分工是：批处理与 ETL 归 Spark，亚秒级流处理归 Flink 或 Kafka Streams，两套代码、两套可观测、两套治理。Databricks 给出的替代方案是让同一套声明式 API 覆盖全部三类负载，换来的收益写得很直白——一套可观测栈、一种计费模型、API 不再分裂。

代价同样清楚：92% 与 100 倍都来自 Databricks 自家基准，基准脚本与数据集虽已开源，对照方是”真实客户负载上的特征计算”，不是通用基准；RTM 只在 Databricks 平台上成立，开源 Spark 侧能拿到的仍是此前合并进 Spark 4.1 的无状态转换那一部分；自定义 sink 的写入器要用户自己写，原生 Lakebase sink 还排在路线图上。对已经把 Flink 用得很深的团队，这条公告改变的是新管道的选型起点，不是存量资产的重构理由。

相关链接

Google Cloud 用 Iceberg REST 联邦直查 Databricks 托管表：跨云不复制，元数据最快每 5 分钟刷新一次

事件概述

Google Cloud 在 10 月 29 日给出 borderless Lakehouse 的一条具体接法：BigQuery 直接查询 Databricks 托管的 Apache Iceberg 表。此前打通这两套系统通常意味着建一条复制管道把数据搬过去，存储成本翻倍、新鲜度打折、安全控制被切成两半。现在的做法是零复制——BigQuery 读的就是 Databricks 写进 Google Cloud Storage 的那批 Parquet 文件，新变更在下一次元数据刷新后可见，刷新周期最快 5 分钟。

关键在目录这一层。Databricks 托管 Iceberg 表在写 Delta 日志的旁边生成 Iceberg 兼容元数据；Unity Catalog 充当 Iceberg REST Catalog，BigQuery 管理员建一个指向它的联邦运行时目录。查询发生时，Lakehouse 向 Unity Catalog 取当前表状态，再通过凭据分发（credential vending）拿到短期令牌，凭它临时读 GCS。权限收拢在 BigQuery 一侧：行级、列级安全与动态脱敏都能作用在这张外部 Iceberg 表上，Databricks 只管摄入。

技术解析

  • 剪枝靠 manifest 而不是元数据缓存：BigQuery 每次查询直接读 Iceberg manifest 做规划，没有需要开启的元数据缓存。Iceberg 的隐藏分区让用户按时间戳这类逻辑列过滤，无需知道目录布局；WHERE 里的分区列要与字面量比较，剪枝才生效。manifest 里的列级统计边界让 BigQuery 跳过无法命中的 manifest 记录与 Parquet 文件。
  • Databricks 托管 Iceberg 表不支持分区变换：这是文章明写的一条限制，替代方案是 liquid clustering。
  • 跨云要付的账仍在：联邦目录由用户指定 Google Cloud 区域，建议贴着数据放；Amazon S3 与 Azure Blob 上的表也能这样读，Remote-cloud egress 费用照收，Cross-Cloud Interconnect（AWS）与 Lakehouse 缓存（预览）可削掉一部分。跨云表重复查询时，Lakehouse 缓存把已取数据块留在 Google Cloud 侧。
  • 维护责任分在两边：小文件由 Databricks 侧处理——OPTIMIZE 合并，或用 Predictive Optimization；托管在 Databricks 之外的 Iceberg 表走 rewrite_data_files，binpack 策略把文件聚到 256MB–512MB。VACUUM 清理活跃快照之外的文件，避免 GCS 上继续计存储费。文章给的理由很直接：几千个小文件意味着几千次到 GCS 的连接与大量元数据页脚解析，向量化执行的优势会被吃掉。

行业影响

这条把”多引擎共用一张表”从口号推进到了跨云、跨厂商的实操层。技术上看，三个成熟部件凑齐了才做得到：托管 Iceberg 表在写侧一并产出 Iceberg 元数据、Unity Catalog 提供标准 REST Catalog 接口、BigQuery 侧接受外部目录并接住凭据分发。缺任何一件，退路就还是复制一份。

值得注意的是它重新划了责任线：数据不动，但表健康仍归写方。compaction 与 VACUUM 依旧要在 Databricks 侧跑，BigQuery 只是读，读得慢了得回去改写侧的布局。新鲜度上限 5 分钟也意味着这类联邦表不适合当作实时链路的末端，它的位置是分析侧，不是服务侧。Databricks 托管 Iceberg 不支持分区变换这一条，则提醒”同一份 Iceberg 元数据”在不同引擎上的可用子集并不相同。

相关链接

阿里云把 Kafka 到 Iceberg 的摄入从 7 个自建节点压到 3 个：五类复杂度换归属，不消失

事件概述

阿里云云原生社区在 10 月 29 日刊出一篇改编自 Apache 2026 会议演讲的长文，讲 ApsaraMQ for Kafka 的存算分离如何撑起两条价值路径。存算分离带来的显性收益是 broker 变轻、存储独立伸缩；更深一层是长期持久化不再绑在某个 broker 的本地盘上，同一份 topic 数据就此原生地流进两个方向：一条是 Table，消息持续沉降为 Iceberg 开放表，成为多引擎可复用的长期资产；另一条是 SQL，消息在到达瞬间被过滤、开窗、聚合、路由，持续产出业务侧的实时结果。

文章反复强调的一点值得单独拎出来：native 不等于省掉了工作。Table 侧依旧要处理记录映射、schema 演进、CDC 重建、原子提交、exactly-once 与小文件治理；SQL 侧依旧要有自己的运行时、资源隔离、失败恢复与作业级可观测。变的是谁长期承担这些能力，用户面对的外部责任边界有多大。

技术解析

  • 从 7 个可见节点到 3 个：传统外部方案暴露 7 个用户可见节点——Kafka、记录映射、schema、文件布局、提交、恢复，以及 Iceberg 加对象存储。原生模式下只剩 Kafka topic、Iceberg 表、对象存储三个，其余五项照旧存在，只是搬进平台内部。文章明确说价值不在图上的框变少，在故障域变小：不必为摄入单独养一个计算集群，不必在多个控制面之间反复同步任务状态，提交与消费进度在同一条托管路径内协调，schema、compaction 与快照清理不再每个作业重实现一遍。
  • 一次可信快照的诞生有明确边界：先按配置把 key、value、header 或时间戳映射到表字段，再做 schema 判断——DECIMAL(10,2) 放宽到 DECIMAL(12,2)、必填字段改可选、新增可选字段这类变更，属于旧数据在新 schema 下仍可被合法解释，可以在演进规则内更新；若新类型容不下旧数据，系统不能静默猜，要拦下提交并报错。随后生成候选 DataFile 与 DeleteFile、构建新的 Manifest 与 Snapshot——文件已在存储上，对读者却不可见；最后条件更新 Catalog 里的元数据位置，从 N 切到 N+1，确认之后整批才一次性可见。文件是物理载体，Snapshot 是逻辑版本。
  • exactly-once 的准确含义被重新定义：以 orders-0 的 offset 100–199 为例，起始是 Snapshot 41、已确认进度 99。第一次尝试写完 File-Set-A 后在提交前崩溃，恢复后重放同一批产出 File-Set-B；只有当 Snapshot 42 与消费进度 199 被一致确认，这 100 条事件才对下游可见，下一批从 offset 200 开始。物理存储上先后存在两份文件，不被任何有效快照引用的那份由后台孤儿文件清理回收。所以 exactly-once 指的是”一批输入即便经历重试，在表的逻辑版本里只生效一次”，不是”底层只写过一份”。
  • CDC 靠 equality delete 重建当前视图：插入写进 DataFile，删除写一条按主键匹配的 DeleteFile，更新读作”旧键删除加新版本写入”。读取侧引擎并非简单拼接全部 DataFile，而是把 DeleteFile 合进来过滤失效记录。这背后有两个容易被忽略的前提：CDC 需要稳定可标识的主键，否则说不清删的是哪一行；源端事件顺序与重复投递语义必须明确，否则同一键上的多次更新会被重建错。
  • 四类边界问题先问清楚再选：数据是否只需持续落表，还是含复杂计算；谁长期负责表的健康（小文件合并、快照过期、孤儿文件清理，怎么观测）；失败后的正确性边界在哪（输入进度、文件写入、快照提交如何关联，若下游还有二段写入，端到端 exactly-once 还取决于目标系统的事务或幂等能力）；未来哪些引擎来消费（Catalog 接口、Iceberg 版本与具体特性要逐条对 Spark、Flink、Trino 的支持矩阵）。
  • 文章自己标了时效：正文注明所述能力截至 2026 年 8 月仍在演进，消息湖摄入在产品文档里是公开预览能力，对 serverless 实例版本与区域有要求，流计算在区域、SQL 能力与端到端一致性上也有显式限制。

行业影响

这篇的价值不在产品介绍，在它把”托管”这个词的责任边界拆开讲了一遍。湖仓摄入这几年被反复简化成”消息转文件”，而这篇文章列出小文件治理、schema 演进、CDC 重建、原子提交、失败恢复五类责任，逐项说明它们不会因为能力被托管而消失，只是从用户可见的外部作业移到平台内部。这个判断对正在做选型的团队直接可用：真正要问的不是谁的架构图更短，是团队想长期拥有哪一部分复杂度。

它和本期 Google Cloud 那条构成一组对照：两家都在拆”中间那份拷贝”，路径却相反——Google Cloud 是让计算走到数据所在的位置，阿里云是让数据在原地裂成两条价值路径。落到开放格式的判定上，两家给出的答案一致：写侧不必预先决定未来的计算方式，Trino 今天做交互式查询、Spark 明天做批处理、后天做特征工程，数据资产都不必跟着搬。

需要说明的是，这篇文章改编自会议演讲，文中自述的产品状态截至 2026 年 8 月，落地范围要以控制台与最新官方文档为准；文中 2,380 → 940 → 420 → 189 那组文件数递减，原文的用途是演示分区、Manifest 与文件级统计三层过滤的机制，不是压缩前后对比，也不代表任何真实负载的固定收益。

相关链接

Lance v15 把六类索引的行地址域写进规范，并给老 writer 加围栏；LanceDB v0.41.0 随之转 GA

事件概述

Lance 格式在 10 月 28 至 29 日两天里打了六个标签：v15 主线从 beta.4 走到 beta.7，v14 线（格式 2.3）连出 v14.0.1 与 v14.0.2。LanceDB 在 10 月 29 日发布 v0.41.0 正式版，底座就是 Lance 14.0.2。

这一批改动的主线是把”靠使用方自行约定”的兼容性，变成”写在规范里、由代码强制”的契约。beta.6 里的 #10299 为 json、inverted、vector、ngram、rtree、minhash_lsh 六类索引指定了行地址域（row-address domain）；beta.7 里的 #10352 被标为关键修复，作用是把更老的 writer 挡在行地址索引之外。ZoneMap 索引 v1 在 beta.4 由 #10217 落地实现——Vol.101 报道时它还只是一条文档条目；beta.6 的 #10165 让 zone map 的 write seeds 跨 zone size 复用，并把 null bitmap 改成可选。

技术解析

  • 围栏与规范是配套动作：先有 #10299 把六类索引各自的行地址域定义清楚，才有 #10352 能判定”这个 writer 版本不该写这类索引”。没有规范，围栏无从判；没有围栏，规范只是纸面约束。
  • 并行任务下的行序这件事还在反复：beta.4 的 #8400 让 compaction 在并行任务之间保持行序，beta.6 的 #10440 又把其中的行序后缀重标部分 revert 了；同一批里 #10445 另开一条路，允许就地压缩显式选定的 fragment 分组。beta.4 的另一条破坏性变更是给 merge_insert 的索引 join 加了内存上界（#8374）。
  • v14 线的两个补丁都属于”不能等”的类型：v14.0.1 去掉对尚未发布的 object_store 的依赖（#10364）；v14.0.2 把切片 validity 对齐的修复回拣到 v14（#10412），同一修复在 v15 侧对应 #10413。
  • LanceDB v0.41.0 把 beta 期的两条决定带进正式版：嵌入配置的信任源留在进程侧——SentenceTransformerEmbeddings.trust_remote_code 默认为 False，从表元数据恢复出的远程代码模型或自定义端点必须由本进程显式批准，未批准的配置在计算嵌入时抛 UntrustedEmbeddingConfigError；列举类 API 改成惰性迭代器。这两条在 beta 阶段已出现过（见本专栏 Vol.98 与 Vol.104），这次随 v0.41.0 进入正式版。本地 SQL 计算列与物化视图仍是实验特性，需要 experimental-functions 构建开关，官方发布的 Python 与 Node 包默认关掉。

行业影响

格式项目的成熟度往往不体现在新特性上，体现在它怎么处理”老数据遇到新实现”。Lance 这一批给出的答案是三步：先把语义写进规范（#10299），再让代码按规范判定（#10352），最后把不能等的修复一并回拣到旧主线（#10412 进 v14、#10413 进 v15）。这让”能不能打开这个索引”从一条需要查文档、问维护者的经验问题，变成一次有版本号的判定。

代价也摆在明处：v15 仍是 beta 主线，beta.4 引入的破坏性变更在 beta.6 就被 revert 掉一条，说明这条线的语义还在收敛；围栏意味着更老的 writer 会被明确拒绝，升级路径上多了一道要提前规划的关卡。对下游的 LanceDB 而言，v0.41.0 选择站在已经打了两个补丁的 14.0.2 上转正式版，而不是追 v15 的 beta，这个取舍本身也说明了两条主线的当前定位。

相关链接

编者评

把这四条并排看，搬走的东西各不相同，动作的方向却一致：原先散在用户手上、要靠额外投入才能维持的一段，被收进了系统自身的契约。Databricks 收走的是”为低延迟另养一套引擎”，Google Cloud 收走的是”为跨云另复制一份数据”，阿里云收走的是”为摄入另搭一条管道”，Lance 收走的是”为兼容性另立一份约定”。四处都不讳言收进去之后留下的代价——联邦表有 5 分钟的刷新上界与仍然归写方的维护责任，托管摄入仍是公开预览且区域受限，92% 是自己测出来的数字，v15 还停在 beta 且刚 revert 过一次。这种把边界写在明面上的写法，比”零复制""统一引擎""原生支持”这类词更值得从业者照着做判断。

另一条暗线是开放表格式的定位又挪了一格。Google Cloud 与阿里云在同一天给出了各自的答案，前者让计算走到数据所在的位置，后者让数据在原地裂成两条价值路径，两家都把 Iceberg 的 manifest 与 Snapshot 当成唯一的判定依据——剪枝靠 manifest，可见性靠 Snapshot，责任划分也沿着这两条边界切。Iceberg REST Catalog 在这两套方案里都是那个不起眼却不可替换的部件。

同期还有几条未列入主题但值得留意：AWS 在 10 月 29 日发了《Optimizing Apache HBase availability on Amazon EMR》系列第一篇，把 coordinator 启动慢、RegionServer 掉队、region 卡在 transition 三种情况做成三级排障流程，配了一张日志签名对照表（SafeModeException 对应 HDFS 安全模式、YouAreDeadException 对应 RegionServer 会话过期、503 Slow Down 对应 S3 限流），并明确规定删 znode 属于要开支持单的动作；Google Cloud 同日宣布 Knowledge Catalog 对 Looker LookML、BigQuery Graph、dbt MetricFlow、Snowflake Semantic Views、Databricks Metric Views 与 SAP CSN 六类语义模型的摄入转 GA，内部基准称准确率近 4 倍、延迟降最多 33%、token 少最多 75%（口径未公开）；DuckDB 在 10 月 29 日刊出一篇 DuckLake 实践访谈，给出的对比是目录操作从 Iceberg 的秒级降到亚毫秒级。中文源方面，阿里云云原生社区在连续多期无可确认日期的条目之后，本期拿到了 10 月 29 日发布的两篇数据基建相关长文（另一篇为 RocketMQ LiteTopic 支撑百万级多智能体会话），火山引擎文档站与开发者社区仍未检索到对应日期的条目。开源侧版本快照：Iceberg 1.12.0、Delta Lake 4.4.1、Trino 484、DuckDB v2.0.0、Ray 2.58.1、Daft 0.7.26、Polars py-2.1.0、Spark 打出 v4.3.0-rc3（尚无正式发布公告）。