TCIceberg 实时入湖：百万级/秒背后的六大技术

当开放湖仓成为 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 月到各平台 Preview2026 年 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 的实时湖仓。