datainfra前沿动态 · Vol.116

AlloyDB 直读 Iceberg 进 Preview，运营库把五年历史拉进单条 SQL；EDB 收购 Altinity，让 Postgres 与 ClickHouse 共用一个 Iceberg catalog；ClickHouse 26.10 用 104 项新特性补齐函数管道与写入配额；四家厂商给 streamhouse 立下厂商中立的开放定义

本期聚焦开放表格式下沉进运营路径：Google 让 AlloyDB 原地读 GCS 上的 Iceberg 表并给出按延迟分层的三条通路，EDB 把 Postgres 与 ClickHouse 缝在同一个 Iceberg catalog 上并承诺一次定义三处执行的治理，ClickHouse 26.10 把函数组合管道、写入行数配额与扫描期字符串过滤落进版本，Confluent、Aiven、StreamNative、Ververica 发布 streamhouse 的厂商中立开放定义——四条合流指向同一件事：分析数据正在走进业务动作发生的路径，Iceberg 是两侧共同的交换语言。

DataInfra AlloyDB Apache Iceberg EDB Altinity PostgreSQL ClickHouse Streamhouse Kafka Flink 开放表格式 数据新鲜度

开放表格式这一周从分析引擎的公共底座下沉进了运营引擎的嘴边：Google 给 AlloyDB 开了直读 GCS 上 Iceberg 表的通路（Preview），注册一次就能在单条 SQL 里把在线交易表与湖上五年历史 join 起来，配套的 AlloyDB sync 与 Lakehouse federation 同期 GA；EDB 宣布收购 Altinity，把 Postgres 的第一大代码贡献者与 ClickHouse 软件的第二大公司贡献者放进同一个 roadmap，两个引擎之间那条 CDC 链路被点名成「没人要的产品」；ClickHouse 26.10 版本盘点落地 104 项新特性，函数组合管道让嵌套调用变成 | 串联，written_rows 配额第一次让写入侧限流与读取侧对等；Confluent、Aiven、StreamNative、Ververica 四家发布 streamhouse 的厂商中立开放定义，给 agent 时代的实时层立了一个进得了预算表的名字。四条线背后是同一个判断：决策正在发生在动作那一刻，数据必须原地可达。

AlloyDB 直读 Iceberg：运营库接进 borderless Lakehouse 的三条通路

事件概述

Google Cloud 宣布 AlloyDB for PostgreSQL 的 direct Iceberg access 进入 Preview，同一篇公告里 AlloyDB sync 与 Lakehouse federation 双双 GA。开发者把一张 Iceberg 表注册一次（给桶路径或 Lakehouse runtime catalog），之后在 AlloyDB 里当普通 PostgreSQL 表查询，与在线运营表在单条 SQL 里 join——公告给的示例是反欺诈：进来的支付对照数据库里最近 30 天的交易，再看 Iceberg 上五年的客户历史，算出「往常消费」与「历史最大单笔」。

这是 borderless Lakehouse 补齐 OLTP 侧的最后一块拼图。10 月底 Google 刚发过 BigQuery 零拷贝查 Databricks 管理的 Iceberg 表——经 UniForm 产出的 Iceberg 元数据，走 REST Catalog 加 credential vending，元数据刷新最快每 5 分钟——那一步轮到的是分析引擎，这一步轮到运营数据库。

技术解析

  • 三条通路按延迟分层：direct Iceberg access 原地读湖表，由 AlloyDB columnar engine 加速，跑在应用同一个实例上，不需要独立的 reader 实例，读到的是团队刚发布到湖里的最新数据；AlloyDB sync 把 BigQuery 数据按自定计划复制成 AlloyDB 本地表，本地表能建索引、能挂读池、能吃 columnar engine 与向量检索，SQL 一句话建同步：alloydb_sync.create_bq_sync_table('project.dataset.table', 'name', INTERVAL '1 hour')；Lakehouse federation 原地查原生 BigQuery 表，谓词、聚合与 LIMIT 下推给 BigQuery 处理，能指定计费项目与可调用角色。
  • 注册即查：CREATE TABLE ... USING iceberg WITH (uri = 'gs://...')，之后 recent_transactions 与 transaction_history 按普通 join 语义连接，没有新方言要学。
  • 厂商基准：Google 给出的口径是 Cloud Storage 上 1 TB 数据集的聚合查询，称比 Amazon 同类 PostgreSQL 兼容服务快最高 7 倍、比开源 PostgreSQL 扩展快最高 3.5 倍——自家基准，采买前自测。
  • 门槛与边界：需在 PostgreSQL 18 实例上开启；direct access 是读通路，写回湖表不在本次范围；agent 侧只拿到在 AlloyDB 里显式授予的表与权限。

行业影响

运营与分析的合流此前的主流答案是 HTAP——把两套负载塞进一个内核。AlloyDB 走的是另一条路：保留两个引擎，共享一份开放格式数据，中间不搬运。Google 引用的 Etsy 案例是 3 PB 数据统一进 borderless Lakehouse、管道查询提速 60%。值得对照的是 Databricks 用 Change Data Feed 与共享表流读增量、ClickHouse 用 WalShadow 做物理复制——大家都在回答 agent 时代同一个问题，只是各自从自己离数据最近的那一端伸手。

相关链接

EDB 收购 Altinity：Postgres 写记录，ClickHouse 读记录

事件概述

EDB 宣布收购 Altinity，交易条款未披露。两家来头都不小：EDB 是 Postgres 代码 20 多年来的第一大贡献者（自家口径），Altinity 是 ClickHouse 软件的第二大公司贡献者，888 个已合并 PR，旗下维护着 Altinity Stable Builds（三年安全与修复回溯）、拉取量超 1 亿的 Kubernetes Operator，以及 Altinity.Cloud。公告特意划清边界：ClickHouse, Inc. 与开源项目保持独立，ClickHouse 软件维持 Apache 2.0，Stable Builds、Operator、Project Antalya 继续开源，CLA 与 RFC 流程不变。

The New Stack 的稿子把这单收购要拆的墙写得很直白：Postgres 与 ClickHouse 之间那条 CDC 链路——复制槽、连接器、消息中间件、sink、去重、每一跳的监控——没有一行是业务产品代码，全部计入 on-call。agent 时代的账更狠：一个跑在 20 分钟前聚合值上的退款审批 agent，错会以机器速度复制上千次。

技术解析

  • 共享层是 Iceberg：技术路线一句话——「Postgres 写记录，ClickHouse 回答问题」。ClickHouse 软件经一个 Iceberg catalog 查询 Postgres 刚写入的同一份实时数据，秒级返回业务问题。现状要分清：今天 Postgres、WarehousePG（EDB 的 MPP 仓库）与 ClickHouse 已能读同一批 Iceberg 表并互查；共享 catalog 与统一治理模型属于 roadmap，TNS 的原话是「正在建的东西，不是今天能下载的东西」。
  • 治理一次定义：目标是行级、列级、掩码策略在数据所在处定义一次，三个引擎各自执行；Postgres 侧今天已支持面向 agent 的 purpose-bound access，ClickHouse 侧目前是自己的 RBAC。
  • 运维收敛：EDB 创建并捐给社区的 CloudNativePG 已是 CNCF 项目，加上 Altinity Operator，一个供应商把两套 Operator 的支持责任一肩挑起；计划用一个主权控制平面统管 Postgres 与 ClickHouse，部署形态随客户：自带云账号、自管 Kubernetes/OpenShift、气隙、全托管都行。
  • 背书与赌注：Jump Trading CTO Alex Davies 的引语点在主权交付实时分析与事务负载；IDC 预计到 2029 年 60% 的企业数据平台将统一工作负载，EDB 押的是 Postgres 侧的入口。

行业影响

AWS 八月收购 DuckLabs（DuckDB 背后公司）时给出的姿势是「开源内核与基金会不动，云化交付权归我」，EDB 这单结构相同：内核社区保持独立，收购方买的是组合交付与支持入口。对多引擎团队，这类合并的兑现标准很具体——共享 catalog 什么时候可用、治理模型是不是真的一次定义三处执行；在那之前，CDC 链路还是自己的。

相关链接

ClickHouse 26.10 版本盘点：函数管道、写入配额、扫描期过滤

事件概述

ClickHouse 刊出 26.10 版本发布长文：104 项新特性、225 项性能优化、739 个 bug 修复。连接重排优化器（DPsub，非内连接第一次进搜索空间）此前已单独深潜（本专栏 Vol.112），本篇盘点的价值在它之外的三条线：SQL 表达力、租户治理、内存与扫描控制。26.10 系列 stable 二进制 10 月 24 日已经流出（v26.10.2.103-stable），本篇是正式的版本总账。

技术解析

  • 函数组合管道：| 运算符把函数串成管道，arrayMap(lower | domainWithoutWWW | firstSignificantSubdomain | upper, urls) 替代多层嵌套；_ 占位符标记管道值的位置，多输入用 _1、_2。分析阶段重写为普通 lambda，执行路径不变——是表达层的甜头，不是新算子。
  • written_rows 配额：按用户在时间窗口内写入的行数封顶摄取，示例 MAX written_rows = 100000, query_inserts = 250 每分钟，用量在 system.quotas_usage 可查。多租户平台侧等的就是这个：读取侧早有限流，写入侧现在对等了。
  • IN 子查询落盘：max_bytes_before_external_set 让 IN 构建的大集合溢写磁盘。原文实测口径：4 GiB 内存下不落盘峰值 1.96 GiB；512 MiB 限制不落盘直接超限失败；同样 512 MiB 限制加 128 MiB 落盘阈值后峰值 203 MiB 跑通。
  • 扫描期字符串过滤：apply_string_filters_during_scan（默认开启）在反序列化列时直接检查 LIKE、startsWith、endsWith，跳过不匹配字符串的拷贝；Amazon 评论数据集上峰值内存从约 129 MiB 压到 2.54 MiB，三次运行各返回 293,115 条命中。
  • GROUP BY 两处加速：多列 LowCardinality 分组直接从字典序列化分组键并缓存聚合状态查找；enable_group_by_top_k_dynamic_filtering 把 25.12 引入的动态过滤扩展到 GROUP BY ... ORDER BY ... LIMIT，实测少读约 94% 的行（三次运行分别跳过 3,529、3,521、3,529 个 granule）。
  • JOIN 放宽：实验性 LATERAL JOIN（allow_experimental_lateral_join = 1，子查询可引用前序表的列，IMDb 示例是按演员找出评分最高的三部片）；ON 条件不再要求等值，LEFT JOIN ... ON p.path LIKE c.pattern 这类模式匹配连接可用，无等值条件时按 block nested loop 执行，文档自己标注为最后手段。
  • 周边补齐：Freeform 输入格式从结构一致的文本推断列与类型（ls -l 输出直接灌进 clickhouse-local 查询）；SQLite 成为输入输出格式，INTO OUTFILE 'films.sqlite' 直接导出库文件、file() 读回；sql_compatible_division_for_integers 让 7 / 2 返回 3 对齐 PostgreSQL 语义（默认关，开启后除零报错而非返回 inf）；实验性 columns cache 把反序列化后的列数据留在内存，当前仅支持 wide MergeTree parts；新数组与 map 函数 arrayMinIndex、arrayMaxIndex、arrayRemoveAt、mapRemove、mapContainsKeyValue。

行业影响

单看每一项都是小刀，合起来方向清楚：易写、可管、省内存三条线齐头并进。函数管道与任意条件 JOIN 对齐的是分析师的表达习惯，written_rows 配额对齐的是平台运营的租户治理，扫描期过滤与 columns cache 对齐的是成本——这三个方向的对手都不在 OLAP 引擎内部，是 Postgres 生态、云厂商托管服务与预算表。

相关链接

streamhouse 开放定义：给实时层一个厂商中立的名分

事件概述

Confluent、Aiven、StreamNative、Ververica 四家数据基础设施公司发布 streamhouse 的开放定义（streamhouse.com），名字任何人免费可用。用意与 lakehouse 当年一致：这套模式在各家客户环境里已经独立长出来，缺的是一个统一定义，让「我们需要一个 streamhouse」这句话在架构师与 CFO 之间可翻译。定义描述的目标是：持续把业务的当前状态交付给应用与 AI agent，数据随事件发生保持新鲜，以机器速度送达。

技术解析

  • 三属性定义：实时——数据随事件发生保持当前状态，不按批计划刷新；生产原生——坐在业务关键路径上，容错与服务等级按运营系统的标准要求，这个标准是分析系统从来不需要背的；去中心化——数据转换的目的是可发现、带上下文，一次产出供 agent、应用、看板多方消费，区别于集中式摄取-加工中心的单一出口。
  • 开放技术栈：可由 Kafka、Flink、Iceberg 等开源组件构成，可用商业产品，也可混搭。
  • 为 AI 整形数据：几十年的范式化把领域关系压成两张外键拼成的小表，对模型几乎不可读；stream 的解法是把变更捕获为事件、实时附加上下文后送达 agent，每次模型调用携带的无关信息更少，成本直接摊薄。
  • 与 lakehouse 共存：历史分析、报表、模型训练继续留在 lakehouse（小时级新鲜度可接受）；streamhouse 接管 lakehouse 没设计过的实时运营负载。落地第一步是列出 agent 要做的决策清单，核对每个决策依赖的数据今天散在哪些运营系统里。

行业影响

命名即地盘。四家的背景值得看一眼：Confluent 刚被 IBM 以 110 亿美元宣布收购（事件驱动 AI 是核心叙事），StreamNative 背着 Pulsar，Ververica 是 Flink 的母公司——流处理阵营在 agent 实时性需求爆发的时间点，把「实时层」从 lakehouse 的补充件升格为并列科目。定义本身没有新技术，意义在采购清单上从此多了一行可谈判的东西；对架构师，真正的功课是三属性里的第二条：「生产原生」四个字背后，是 SLA、容错与 on-call 向流栈转移的隐性成本。

相关链接

编者评

把本期四条放在一张桌上，能看出 Iceberg 的角色变化：它先是分析引擎之间的公共底座——Spark、Trino、BigQuery 互读开放格式；这一周它下沉成了运营引擎也直接说出口的语言：AlloyDB 原地读，EDB 拿它当 Postgres 与 ClickHouse 的共享层，streamhouse 把它与 Kafka、Flink 并列为三件套。引擎竞争的焦点正从「谁能读开放格式」转向「谁能在开放格式之上多做事」——AlloyDB 的三条通路按延迟分层，EDB 承诺一次定义三处执行的治理，ClickHouse 用写入配额把多租户治理补到与读取对等。驱动力是新鲜度：agent 在机器速度上消费聚合值，二十分钟前的数据不是慢，是错。存储层的资本动作也落在同一周：Dropbox 买下 Tigris，把 S3 兼容存储卖给 AI 开发者。湖仓与流仓、运营与分析的边界还在，但两侧说同一种表格式语言的日子已经开始了。