datainfra前沿动态 · Vol.60

Databricks 把 Kafka 与 RabbitMQ 做成托管流式摄取连接器，消息总线入湖不再自建管道；DuckDB 切出 v2.0-cyanoptera 分支进入功能冻结，Quack 协议随 alpha 升到 1.0；EMR Trino 用 Iceberg REST 端点直连 S3 Tables，SigV4 签名名固定为 s3tables；StarTree 给 Pinot 加 Segment Groups，把约 100 个物理 segment 的元数据折叠成一个控制面对象

本期聚焦同一个动作在不同层的重演：把协调或接入的单位从物理实体上摘下来。管道变成声明、库变成服务、目录变成标准端点、控制面对象变成组，四处的代价也各自换了个位置。

2026年9月7日 DataInfra Databricks Lakeflow Connect Kafka RabbitMQ Zerobus DuckDB Quack v2.0 Cyanoptera Amazon EMR Trino S3 Tables Iceberg REST Catalog SigV4 Apache Pinot StarTree Segment Groups DataInfra前沿动态 Vol.60

本期四条动态在做同一件事：把”协调的单位”从物理实体上摘下来。Databricks 让 Kafka 与 RabbitMQ 的摄取从”每个 topic 一套自建管道”变成一份声明式 bundle，路由规则用表达式写在配置里；DuckDB 切出 v2.0-cyanoptera 分支进入功能冻结，Quack 协议从 0.x 升到 1.0，接入单位由进程变成网络端点；AWS 让 EMR 上的 Trino 通过标准 Iceberg REST 端点直连 S3 Tables，签名名固定为 s3tables，目录不再需要引擎专属集成；StarTree 给 Pinot 引入 Segment Groups，把约 100 个物理 segment 的元数据折叠成一个控制面对象，文件本身一个字节都不动。四处都赢在让物理布局得以自由变化——代价则各自换了个位置：入站网络、生产就绪度、版本锁定、以及 Broker 剪枝粒度的变粗。

Lakeflow Connect 把 Kafka 与 RabbitMQ 变成托管摄取：管道从代码退化为声明

事件概述

Databricks 于 2026 年 9 月 4 日在官方技术博客宣布，Kafka 与 RabbitMQ 摄取以全托管流式连接器（Beta）的形式进入 Lakeflow Connect。此前要把消息总线里的数据搬进湖仓，通常要为每一个 topic 或 queue 单独搭一条摄取管道，并长期承担扩缩容与运维；新连接器把这件事压缩成两步：在 Catalog Explorer 里建一个 Connection，再写一份描述目标的 bundle，数据就持续流进 Delta 表。

值得注意的是官方一并给出的选型矩阵。Lakeflow Connect 的托管连接器是拉模型——它主动探入源端拉取数据，代价是要求对源站有入站网络访问能力，换来的是用户不需要运行任何软件；Zerobus Ingest 则是推模型，用户用 SDK 在自己边界内跑一个 sidecar 往外推，流量全部是出站的，代价是这个 agent 由用户自己构建和运维。官方明确二者是互补而非竞争，并给出了一组可以直接对照的维度。

技术解析

两个可组合的部件：Connection 是 Unity Catalog 的一个 securable，保存 broker 端点与凭据，建一次后按名字引用；ingestion pipeline 定义在 bundle 里，映射源到目标表，跑在 serverless 计算上。最小示例里，kafka_pipeline 用 connection_name 指向 UC 连接，用 topics: [user-events, power-user-events] 把两个 topic 写进同一张 user_events 流表，channel: PREVIEW、continuous: true。
bin-packing 是成本故事的核心：官方称托管摄取可以用单个 CPU 核在一个 task 内处理多个 Kafka partition，把 topic 的摄取在算力上做装箱。这与两类传统做法形成对照：一个 topic 一条专用管道耐久性好但贵，多个 topic 捆进一条管道则扩容时难维护。叠加 serverless 后按实际用量计费，应对流量峰谷时的弹性由平台承担。
Variant 承接非齐整消息：key_transformer: format: STRING 与 value_transformer: format: JSON 把消息体解析进 variant 列；starting_offset 可选 latest 或 earliest。
schema 演进是向前滚动的：json_options: schema_evolution_mode: ADD_NEW_COLUMNS 让新出现的字段自动加列，保持表仍是 schematized 的，避免退化成一整列 JSON 字符串。
fanout 用表达式取代”一表一管道”：单个 topic 里混着多种事件类型时，topic_pattern: 'events-.*' 配 fanout_by: 'cast(value as string):event_type::string'，路由规则就从管道拓扑变成配置里的一行表达式。
拉与推的四条硬边界：托管连接器方向为 Pull、由 Lakeflow Connect 全托管、需要入站访问、数据真源留在消息总线、当前源为 Kafka 与 RabbitMQ；Zerobus 方向为 Push、由用户构建并运行 agent、仅出站、数据真源是湖仓、可对任何能写代码对接的系统生效。选型取决于安全姿态与运维约束。
当前的缺口写得很直白：连接器目前只能用 Declarative Automation Bundles 配置（RabbitMQ 支持即将到来）与 pipeline API，点选式 UI 尚在开发中；Avro 与 Protobuf（含 schema registry 集成）在路线图上；Zerobus 一侧则在补 Kafka 兼容与 MQTT 兼容的 producer API。

行业影响

消息总线入湖这件事的竞争焦点，正从”能不能连上”转向”连接这件事占不占用用户的运维编制”。把管道退化为声明后，topic 数量的增长不再线性转换成管道数量的增长，fanout 与 bin-packing 把路由与装箱这两件原本手工的活交给了平台。

代价的形态也变了。拉模型要求源站对 Lakeflow Connect 开放入站访问，这在不少网络姿态下不可接受——那些场景仍要回到 Zerobus 自建 agent，也就是把运维成本从一个地方挪到另一个地方，而不是消掉。官方把这条边界连同”数据真源在谁手里”一起列进矩阵，比单纯宣称”全托管”更有参考价值。

相关链接

DuckDB 切出 v2.0-cyanoptera 分支进入功能冻结，alpha 客户端开放安装

事件概述

2026 年 9 月 2 日，DuckDB 官方发布《Try DuckDB v2.0-alpha》，宣布已从 duckdb/duckdb 的 main 开发分支切出 v2.0-cyanoptera 分支。这标志着功能冻结：接下来的开发集中在测试、修 bug 与打磨上，正式版 v2.0 Cyanoptera 预计在 10 月下半月发布。

对一直跟踪这个项目的人来说，这一步的意义在于把此前只有第三方转述的路线图钉死在了官方源上。官方给出的冻结理由也很工程化：duckdb/duckdb 是整个生态的中心依赖，先稳定它，才能解锁客户端与扩展两侧的工作。

技术解析

版本号与安装方式已经公开：CLI 用 curl https://install.duckdb.org | DUCKDB_VERSION=alpha bash 安装，SELECT version() 返回 v2.0.0-alpha39998；Python 用 pip install duckdb --pre --upgrade，duckdb.version() 一并打印客户端与库的版本，形如 1.6.0.dev379 (with duckdb 2.0.0-alpha39998)。Windows 提供 AMD64 与 AArch64 的 tarball（位于 artifacts.duckdb.org/v2.0-cyanoptera/）。
Windows 客户端暂不带扩展：官方在页面里以 Warning 明确标注 “Extensions are not yet available for the Windows client”，并称后续补齐。这是当前 alpha 覆盖面最实际的一处缺口。
Quack 从 0.x 升到 1.0：官方表述是新版将解锁更高的查询吞吐（服务端到客户端与客户端到服务端双向）以及更好的兼容性。Quack 让任意 DuckDB 进程把自己的库通过网络提供服务，配合 CONNECT 语句把会话指向远端——这也是 v2.0 被官方称为”DuckDB 作为服务器元年”的落点。
核心扩展同步进入 alpha：httpfs、ducklake、iceberg、spatial 均已提供 alpha 版本。社区扩展可以通过提供 ref_next SHA 提前针对 v2.0-cyanoptera 分支构建；不提供则在 v2.0.0 定稿后使用 ref SHA。
官方对适用范围的态度不含糊：alpha 客户端”明确不是生产就绪”（explicitly not production-ready）。官方预期大多数现有负载能跑通、一部分明显变快、一部分可能报错，并明确说最想要的是最后一类反馈——哪些环境、哪些情形下 v2.0 alpha 兜不住。
被冻结的范围：v2.0 之所以值得一个大版本，是因为它打包了新 SQL 解析器、新的默认存储格式、重做的 C API 与少量刻意选择的破坏性变更；官方称这是自 3 月发布 v1.5 以来一万余次提交的结果。这些内容的细节在 8 月 17 日的预览博客中已披露，本次冻结意味着它们不再变动。

行业影响

把一个嵌入式分析库变成可被远程连接的服务器，改变的是它在架构里的位置。过去 DuckDB 的部署单位是一个进程、一份文件，接入方式等于”把库链进你的程序”；Quack 1.0 之后，接入单位变成网络端点，同一份引擎可以在本地做计算，也作为共享服务被多个会话连接。这让”单机分析引擎”与”服务化数据基础设施”之间的界线变得模糊——AWS 此前把 DuckDB 称作跨引擎的”数据结缔组织”，其前提正是这种可联网形态。

需要提醒的是时间差：功能冻结不等于可用。从 9 月 2 日切分支到 10 月下半月正式版，中间有约六周的窗口，且官方已声明 alpha 不可上生产、Windows 侧扩展缺失。真正值得在这段时间做的是把代表性负载丢进 alpha 跑一遍，而不是规划升级。

相关链接

EMR Trino 通过 Iceberg REST 端点直连 S3 Tables：`sigv4-enabled` 与 `signing-name=s3tables` 是硬要求

事件概述

2026 年 9 月 2 日，AWS Big Data Blog 给出一份把 Amazon EMR 上的 Trino 接到 Amazon S3 Tables 的操作指南，路径不是任何 AWS 专属连接器，而是标准的 Iceberg REST catalog endpoint。Trino 侧只需一份 catalog 属性文件，就能对 S3 Tables 中的表做完整的读写、时间旅行与 schema 演进，压缩、快照过期、元数据管理等表维护则由 S3 Tables 自动承担。

版本号是这篇指南里最该先看的约束：Trino 必须 475 或更高，对应 EMR 7.11 及以上（文章示例使用 EMR 7.12）。低于这个组合就没有可用的 Iceberg REST 集成。

技术解析

catalog 文件长什么样：CloudFormation 在部署时动态生成 /etc/trino/conf/catalog/s3tables_irc.properties，关键项包括 connector.name=iceberg、iceberg.catalog.type=rest、iceberg.rest-catalog.uri=https://s3tables.<REGION>.amazonaws.com/iceberg、iceberg.rest-catalog.warehouse=arn:aws:s3tables:<REGION>:<ACCOUNT-ID>:bucket/<BUCKET-NAME>。
SigV4 是认证方式，签名名固定：iceberg.rest-catalog.sigv4-enabled=true 与 iceberg.rest-catalog.signing-name=s3tables 两项均为必需，signing-name 必须写成 s3tables。授权走 IAM 角色，文章使用 EMR service role 本身，并要求其信任策略一并允许 elasticmapreduce.amazonaws.com 与 AmazonEMR-InstanceProfile 代入。
view-endpoints-enabled=false 是必需项：这一项被明确列为必须设为 false，意味着该集成路径下不使用 view endpoints。
文件系统二选一被钉死：fs.hadoop.enabled=false 且 fs.native-s3.enabled=true，即读写 S3 必须走原生 S3 文件系统，而非 Hadoop 的 S3 实现。
一个 catalog 绑定一个 bucket：warehouse 属性决定绑定关系，要访问多个 S3 table bucket 就得注册多个 catalog。
网络与部署：模板会创建 S3 Tables 的 interface VPC endpoint 与私有子网，用于私有访问；示例栈 emr-s3tables-trino 的创建约需 15 分钟。
引擎侧能拿到的 Iceberg 能力：时间旅行可用 SELECT * FROM "customers$snapshots" 查快照，再用 FOR VERSION AS OF <snapshot_id> 读历史版本；schema 演进支持 ALTER TABLE ... ADD COLUMN 与 RENAME COLUMN；建表可指定 format = 'PARQUET' 与 sorted_by = ARRAY['customer_id'] 做文件内排序。查询侧由 Iceberg 元数据层承担分区裁剪与谓词下推，写入则经 REST endpoint 原子提交。
维护默认值与限制：压缩、快照过期等 Iceberg 属性由 S3 Tables 以默认值自动处理；要改需用 S3 Tables 的 maintenance API，并且存在维护限制（正文链接指向具体限制页，未列出数值）。细到列与行的权限可再叠 Lake Formation。

行业影响

这条路径的价值在于它用的是标准件。S3 Tables 暴露的是 Iceberg REST catalog 端点，Trino 用的是 Iceberg 连接器的 rest 类型，两边都不是对方专属的——文章也点明 Spark、Flink、Dremio 等其他 Iceberg 兼容引擎可以访问同一批表。对已经押注 Iceberg 的团队，这意味着存储侧的托管能力（自动压缩、快照过期）与引擎侧的选型可以分开决策。

代价写在必需项里：Trino 475+ / EMR 7.11+ 的地板、view-endpoints-enabled=false、原生 S3 文件系统、以及每个 bucket 一个 catalog。这些都是”想用就得接受”的前置条件，而不是可以绕过的选项。把它们与 Vol.59 报道过的七家 REST Catalog 实测放在一起看会更清楚——规范统一了接口形状，但各家在必填字段与未启用能力上的取舍，仍然要逐条读文档才能对齐。

相关链接

Query Amazon S3 Tables from Amazon EMR Trino using the Iceberg REST endpoint

StarTree 给 Apache Pinot 引入 Segment Groups：合并元数据，不合并 segment

事件概述

Data Engineering Weekly 第 286 期（2026 年 9 月 7 日）收录了 StarTree 的一篇工程文章，处理的是一个在超大规模下才会暴露的瓶颈：控制面元数据膨胀。StarTree 给出的答案是 Segment Groups——一项 opt-in 能力，把约 100 个物理 segment 的元数据聚合为一个控制面对象，而底层 segment 一个都不合并、一个都不重写。官方的说法很凝练：“We merge metadata, not the segments themselves.”

这篇文章值得单列的原因，是它把”换掉协调单位”这个动作的成本与收益都写成了可核对的数字，而不是一句”可扩展性提升”。

技术解析

为什么控制面先撑不住：segment 数超过约 100 万后，控制面工作开始主导，数据面往往还有余量。具体数字是——约 100 万 segment 时，一次 IdealState 更新约需 25 秒；约 150 万 segment 时，一次完整 Helix reconciliation 可能超过 2 分钟。ZooKeeper 反序列化占约 40% CPU 与 65% 内存分配，GC 再吃掉约额外 30% CPU。
规模从哪来：约 1 亿 events/秒的摄入速率下，每天新建约 30 万个 segment，可累积到约 1000 万个活跃 segment。开放表格式让这个问题提前出现——一张含 500 万文件的 Iceberg 表，在 Pinot 里第一天就是约 500 万 segment 的表。
分组系数约 100（可配置）：按此系数，1000 万物理 segment 只需约 10 万个控制面 group，控制面对象数下降约两个数量级。官方称这让集群从”管理约 100 万个可协调 segment”走向”1000 万 segment 及更高”。
控制面与数据面用不同的粒度：官方概括为 “The control plane operates on groups. The data plane continues operating on individual segments.” Server 最终会把 group 重新展开为成员 segment，逐个加载与查询。
建组通常是元数据操作，不是数据搬运：server 让一个 group 上线时，对每个成员按成本从低到高选来源——已加载且 CRC 符合就直接重新注册，本地磁盘有文件就从磁盘加载，只有真正缺失的才从 deep storage 拉取。
原子切换与过渡期：group 创建借助 Pinot 已有的 segment lineage 机制做原子切换；在 group 的所有副本在线之前，原有的独立 segment 表示仍保持活跃。过渡期内同一物理 segment 可能被两种表示一起引用。
Iceberg 侧的语义：group 在文件元数据摄入时形成，不可变且按快照作用域划分；底层文件集变化会创建新 group、旧 group 保留，由快照 manifest 决定查询用哪个 group。group 名基于成员集合做内容寻址，重建相同集合是幂等的，未变化的分区可跨快照复用。
代价是 Broker 剪枝粒度变粗：Broker 只能看到 group 元数据，其剪枝粒度从单个 segment 退化为 group（一个 group 可能覆盖比单个 segment 更宽的时间范围）；不过 server 展开 group 后仍可按各 segment 的时间范围与分区信息做精确剪枝。
一条反直觉的对照数据：把负载拆成 10 张物理表，controller GC 时间在同一总 segment 数下从约 30% 降到约 15%，但在相同 segment 创建速率下每秒 IdealState 更新数约为 5 倍，且不减少集群最终要处理的元数据总量。分表不是这个问题的解。
它不解决什么：Segment Groups 只减少控制面对象，不减少物理 segment 数。若目标是简化物理布局或真正需要更大更少的 segment，仍要走 Minion merge/压缩——那需要重写数据，且可能降低基于时间的剪枝精度。

行业影响

“换掉协调单位而不动物理布局”这件事，在存储与计算分离之后正成为下一类通用优化。Iceberg 靠 manifest 与快照把文件列表折叠成可裁剪的元数据树，Pinot 的 Segment Groups 则是同一思路在实时 OLAP 控制面上的版本：让控制面按组记账，数据面继续按细粒度工作。二者都不改写数据，也都把代价转移到了别处——这里是 Broker 剪枝精度。

对正在把 Iceberg 这样百万文件级的数据集接进实时引擎的团队，这篇文章给出的不是配置技巧，而是一组判断阈值：什么时候 segment 数本身已经成为架构约束（controller 协调落后、server 恢复时间随表增长显著变长、controller CPU/GC 大量消耗在元数据上），以及哪些应对手段（人为分表）实际上无效。

相关链接

编者评

四件事看起来分属摄取、数据库、云上集成与实时 OLAP，做的是同一个动作的四个版本：把协调或接入的单位从物理实体上摘下来。Databricks 让路由规则从管道拓扑变成配置里的一行表达式，DuckDB 让接入单位从进程变成网络端点，AWS 让目录访问从引擎专属集成变成标准 REST 端点加一个固定的签名名，StarTree 让控制面按组记账而数据面仍按 segment 工作。四处都由此获得了一个此前没有的自由度——物理布局可以变，而上层的结构不用跟着变。

真正值得记住的不是收益，而是代价换到了哪里。托管的拉模型要求源站开出入站访问，否则就得回到自建 agent；功能冻结换来的六周窗口里 alpha 不可上生产，Windows 侧连扩展都没有；标准 REST 端点下面压着 Trino 475+、EMR 7.11+、view endpoints 必须关闭这一串硬门槛；控制面轻了，Broker 的剪枝粒度却粗了一档。工程上的取舍从来不会消失，只会换位置——判断一项新能力是否适用于自己，最快的办法是先去找官方文档里那些被标成”必需”的小字，代价通常就写在那里。