点击蓝字 关注我们
本文共计3923字 预计阅读时长12分钟
当开放湖仓成为 AI Native 数据平台的底座，实时入湖的工程化能力决定了数据就绪的速度。
Iceberg Summit 2026 之后，开放湖仓进入 AI Native 时代，实时性成为硬门槛
今年四月的 Apache Iceberg Summit 2026（旧金山），把开放湖仓的几个关键玩家第一次在同一周集齐到了同一张桌子上。
Databricks 宣布 Iceberg v3 公开预览，把行血缘、删除向量、VARIANT 半结构化类型三项能力一次性推到了预览可用。Snowflake 同期公布 v3 路线图，顺手把治理可移植性、Polaris 开源 Catalog 两张牌也打了出来。Dremio 走得更前，成为首家 v3 全面 GA 的平台。Google Cloud 也在 4 月 9 日发布了 BigQuery-Iceberg 双向互操作预览。
两天、七十多场技术分享，一个清晰的信号：开放表格式的竞争，已经从"谁兼容 Iceberg"彻底移到了"谁能在 Iceberg 之上把治理、Catalog、AI 集成做到生产可用"这一层。
这个信号背后有一个更大的趋势在驱动——数据平台正在从"分析就绪"走向"AI Native"。当 AI Agent 需要实时访问最新业务数据、当特征工程要求秒级数据新鲜度、当大模型微调依赖持续更新的训练集，湖仓的实时入湖能力不再是"锦上添花"，而是 AI 数据就绪的硬门槛。
Gartner 分析师 Aaron Rosenbaum 在最近的交流中反复强调一个判断：开放表格式是 AI 就绪数据的关键赋能技术。Iceberg 已经不再是一个选型问题，而是整个数据行业的基础设施共识。
但"共识"只是起点。回到国内的数据平台一线现场，当 Iceberg 真正要承接百万级/秒 Upsert、TB 级表规模、亚秒级查询延迟的混合场景时，开源版本的几个老问题会被急剧放大。
腾讯云数据湖计算 DLC 的自研 TCIceberg，正是针对这一层"生产可用性"的答卷。过去两年，DLC 联合 WeData 已经支撑了多个 PB+ 的分钟级实时湖仓商用案例，是突破百万级/秒数据实时入湖 Upsert QPS 的实时湖仓引擎。背后不是单点优化，而是六项核心技术叠加出来的稳定性。
这篇文章，就讲清楚这六项技术分别解决了什么、怎么解决、为什么要这么解决。
Iceberg 跑到百万级/秒，绕不开的四道坎
在讲 TCIceberg 做了什么之前，先把实时湖仓的真问题摆出来。
开源 Apache Iceberg 在设计之初是一个典型的"分析优先"表格式——事务原子性、隐藏分区、Schema 演进，这些能力让它在批量写入+批量查询的场景表现优秀。但一旦把它放到高频 Upsert 的生产管线里，四个问题会相继暴露：
第一道坎：写入放大。开源 Iceberg 的 Copy-on-Write 模式下，任何一条记录更新都要重写整个数据文件。一天上亿条 CDC 变更进来，存储 I/O 和计算资源会被放大几个量级。切到 Merge-on-Read 固然能缓解写入，但随之而来的是读放大——查询需要合并 delete files 和 data files，延迟变得不可控。
第二道坎：小文件泛滥。实时写入天然产生小文件，而 Iceberg 的社区 Compaction 并没有统一、自动化的调度机制。业务团队要么自己写调度脚本，要么让小文件不断堆积、查询越跑越慢、直到必须停机重组。
第三道坎：下游消费延迟。实时湖仓很少是"只有一个下游"的架构。CDC 进入湖后，通常还要再分发到多个实时消费方——BI 报表、实时特征、OLAP 查询都要看到同一份变更。开源 Iceberg 缺少针对"增量消费"的原生流式能力，下游拿到的往往是批式快照，不是增量流。
第四道坎：多表打宽与 Upsert 语义薄弱。实时数仓里有一类常见场景：下游要的不是单表更新，而是"用户维度 + 订单维度 + 营销标签"的打宽表。每张上游表只能写自己负责的字段，多张流同时 upsert 到一张宽表上，开源方案要么靠应用层手工 join，要么等到 merge 环节再拼——复杂度和延迟都不可接受。
Iceberg Summit 2026 上讨论的 v4 方向——单文件提交、高效列更新、相对路径迁移——其实正是对上述问题的社区级应答。只是社区演进有自己的节奏，Péter Váry 提出的高效列更新提案进入 GA 可能还要一到两年。而生产系统不会等。
TCIceberg 的六大技术，按问题组织
TCIceberg 不是另起炉灶的孤立引擎，它基于 Apache Iceberg 深度优化，保持与社区格式的完全兼容。真正的价值在六项针对上述痛点的工程化能力。
1.Merge-On-Read：把写入延迟从分钟压到秒级
TCIceberg 把 MoR 模式做到了生产级稳定可用。写入路径上，数据先落到 ChangeStore 的轻量级增量文件；读取路径上通过智能合并，把 base 文件和 change 文件按主键合并返回。对写入者而言，单次 commit 只涉及少量增量文件，写入延迟从开源 CoW 的分钟级压到秒级；对查询者而言，合并逻辑在引擎侧自动完成，SQL 语义不变。
关键在于 MoR 不是简单开关，而是配合后文的 Auto Compaction 持续收敛 delete 与 data 的配比，让读性能不会因为增量文件堆积而恶化。
2.Auto Compaction：小文件治理不再是运维活
开源 Iceberg 的 Compaction 需要用户自己调度 Spark 作业去合并小文件、清理过期快照、移除孤儿文件。TCIceberg 把这整套治理做成了原生、自动、托管的能力。
系统持续感知文件分布，智能识别小文件对任务的影响，自动调起 Spark 引擎完成合并，并同步处理数据生命周期管理和 Iceberg 快照清理。业务方只写入、只查询，治理这件事对他们是透明的。
这对长期运行的实时湖仓意味着什么：过去需要专门一位运维工程师"盯着"Iceberg 表的小文件数、Compaction 任务的成功率、快照膨胀情况，现在这些都被系统自动完成。DLC 托管存储上，小文件治理从运维负担降为背景行为。
3.自动分桶：1-2GB/桶，让查询稳定可预测
小文件合并之后，文件粒度要控制在多大？开源方案通常依赖 target-file-size 静态配置，对大表和小表都是同一个值。TCIceberg 引入自动分桶机制，按数据分布和主键哈希动态选择 1-2GB/桶的目标粒度。
这个数字不是拍的。它是在大量生产负载上反复验证出的甜蜜点：对象存储（COS）上单文件太小会放大元数据请求开销，太大又会影响并行度和缓存命中率。1-2GB 这个区间，配合 Alluxio 的本地缓存和亲和性调度，能让交互式分析在亚秒级返回，同时写入侧也不会因为分桶粒度过细而打爆元数据。
4.CDC 流式消费：让 Iceberg 表变成一条增量流
TCIceberg 原生支持把一张 Iceberg 表作为流式 source 暴露给下游。这意味着 Oceanus、Flink 作业可以像消费 Kafka 一样消费 Iceberg 表的增量变更，而不需要额外的 CDC 中间件。
这一能力背后，是 BaseStore + ChangeStore 双层存储为流式消费提供的天然增量视图——ChangeStore 本身就是按时间序组织的变更流。下游消费者看到的是统一的 change log，订阅、回放、断点续传都按流语义工作。
对实时湖仓架构师来说，这消掉了过去必须引入一个外部 CDC 中间层的复杂度。数据从 CDC 入湖到下游 Flink 作业消费，整条链路的延迟从分钟级的"CDC → Kafka → 湖"压到了秒级的"CDC → 湖 → Flink"。
5.Merge Function：宽表打宽的原生语义
宽表场景下，TCIceberg 提供了 Merge Function 扩展。支持两种核心模式：replace 模式下，新行整行替换旧行；partial update 模式下，只更新来源字段，未提及的字段保持原值。
这听起来像一个 SQL 语法糖，但在百万级/秒的高并发场景下，它消除了应用层 join 的必要性。上游用户表、订单表、标签表三条流同时 upsert 到同一张湖上宽表，每条流只更新它负责的列，读者拿到的永远是三方合并后的最新视图。
这类能力在开源 Iceberg 的 upsert 语义里是缺失的——开源只认"整行替换"，partial update 要靠用户自己实现读取-合并-回写的模式。TCIceberg 把它内置到了表操作的原语层面。
6.Primary Key 语法扩展：Upsert 不再是实现细节
开源 Iceberg 的 Upsert 语义是通过 MERGE INTO 语句组合实现的，对用户而言是一段显式 SQL 逻辑。TCIceberg 扩展了 Primary Key 语法，把"这是一张 upsert 表"变成了表级声明。
CREATE TABLE ... WITH ('primary-key' = 'user_id')
之后，后续所有 INSERT 语句自动以 upsert 语义执行。对使用 Flink SQL、Spark Streaming 的流式作业来说，SQL 的可读性和可迁移性大幅提升；对原来习惯了 Kudu、Hudi 等 Upsert 语义表格式的团队来说，迁移到 TCIceberg 几乎零语义成本。
这是一个看起来很小、但对生态迁移影响很大的改动。
百万级/秒是怎么跑出来的：底层配合是关键
六项能力单拿任何一项出来都不稀奇。真正让 TCIceberg 在 PB+ 规模跑出百万级/秒 Upsert QPS 的，是底层三件事的配合。
BaseStore + ChangeStore 双层存储。BaseStore 承载存量数据，按批量优化；ChangeStore 承载增量变更，按流式优化。两层存储在元数据层面打通，批处理作业和流处理作业在同一张逻辑表上共享一致性视图。这是 TCIceberg 区别于"单层对象存储 + 应用层分层"方案的关键架构点。
Alluxio 本地缓存 + 亲和性调度。对象存储（COS）的顺序读性能不错，但随机读、小文件读延迟较高。DLC 在 Serverless Spark 集群上部署了 Alluxio 本地缓存，热数据命中本地缓存后延迟逼近本地盘。同时引入亲和性调度，把同一张表的查询尽量路由到已缓存该表数据的节点上，进一步放大缓存价值。
存算分离 + 独立扩缩。写入、Compaction、查询三类负载在 DLC 上由不同的 Serverless 计算集群承接，互不干扰。Upsert 洪峰来临时写入集群自动扩容，查询端完全不受影响；同样，Compaction 在后台独立运行，不会挤占生产查询的资源。
某在线教育APP 的实时湖仓场景：原先 MySQL + 分析型数据库的双栈架构存在数据同步延迟、存储成本高、扩缩容不灵活三个问题。迁移到 DLC + TCIceberg 后，端到端数据可见性从"天"级提升到"分钟"级，2000+ 张表实时写入，单表更新比例接近 20%，整体降本 30%。
TCIceberg 在 Iceberg v3/v4 时代的定位
Iceberg Summit 2026 之后，经常被问一个问题：Iceberg v3 的行血缘、删除向量、VARIANT 这些新特性上来之后，各家的自研优化还有意义吗？
我们的答案是：生态演进和生产可用性，是两件需要分开看的事。
v3 的删除向量确实在规范层面解决了"逻辑删除重写文件"的问题，开源基准下写入性能有几倍提升。但从规范批准（2025 年 8 月）到各平台 Preview（2026 年 Q1-Q2）再到真正 GA，还需要一到两年。生态支持也仍然分层——社区的某些主流引擎当前公开版本只支持 v1/v2，对 v3 的 time-travel、upsert、行级安全能力覆盖度差异很大。
v4 的方向——单文件提交降低元数据开销、高效列更新面向 AI/ML 宽表场景——与 TCIceberg 的六大技术思路是高度一致的：让 Iceberg 从"批优先"走向"实时就绪 + AI 友好"。只是社区的路径更通用、更保守，而商业引擎有空间在保持兼容的前提下提前落地。
从更宏观的视角看，AI Native 数据平台对湖仓层提出的核心要求是数据新鲜度——Agent 需要实时数据做决策、特征需要秒级更新、模型需要持续学习。TC-Iceberg 的六大技术本质上都在回答同一个问题：如何让开放湖仓在保持兼容性的前提下，达到 AI 工作负载所需的数据就绪水平。腾讯云与信通院共同制定的 DIOps 标准，也将实时湖仓的数据治理能力纳入了规范化评估框架，为行业提供了可参照的成熟度基准。
TCIceberg 的设计原则始终是兼容优先，增量创新。底层数据文件和元数据完全遵循 Apache Iceberg 规范，用 Spark、Trino 等开源引擎也能读取。Iceberg 社区的新版本特性，DLC 会持续跟进并集成。同时，腾讯云在 Apache Iceberg 和 Apache Amoro（实时湖仓治理）两个开源社区都有持续贡献。
对企业而言，这意味着：今天用 TCIceberg 解决百万级/秒 Upsert 的生产问题，不会被锁定在任何私有格式里；未来社区标准化了同类能力，迁移回开源也是平滑的。
什么场景值得用 TCIceberg
不是每个 Iceberg 使用场景都需要 TCIceberg。下面是一个判断框架：
值得用 TCIceberg 的场景
- 上游有高频 CDC 流入，Upsert QPS 目标在十万级以上
- 需要在湖上直接做实时分析，容忍延迟在秒到分钟级
- 有多张上游流向同一张宽表打宽的需求
- 小文件和 Compaction 已经是运维团队的重点投入项
- 对开源 Iceberg 的兼容性和后续迁移可逆性有要求
回到开放湖仓的大势
开放湖仓正在成为 AI Native 数据平台的基础设施层。当数据平台的核心使命从"支撑分析"扩展到"供给 AI"，实时性、开放性、治理自动化三者缺一不可。标准在演进、能力在收敛的过程中，真正的差异化战场在于——谁能在保持开放格式兼容的前提下，把生产可用性做到可信赖的水平。
TCIceberg 的六大技术（Merge-On-Read /Auto Compaction /自动分桶 /CDC 流式消费 /Merge Function / Primary Key 扩展），加上底层 BaseStore + ChangeStore 双层存储、Alluxio 缓存、存算分离三件事的配合，是 DLC 在这条路径上的工程化答卷。
国内首个突破百万级/秒 Upsert QPS 不是终点。接下来 DLC 会在秒级数据延迟、物化视图商业化、开源社区贡献（Iceberg + Amoro）三个方向继续投入，也会持续跟进 Iceberg v3/v4 的社区进展。
腾讯云大数据，帮助企业构建 AI Native 的实时湖仓。
END
关注腾讯云大数据╳探索数据的无限可能
往期精彩
求点赞
求分享
求喜欢
