腾讯云基于 Iceberg 的批流一体实践

Amoro Community 2025-03-28

293

导读腾讯云自 2019 年就开始接触 Apache Iceberg 项目，并开始基于 Iceberg 构建湖仓一体数据架构。经过多年深入使用和优化，沉淀出了一套基于 Iceberg 的完整的全场景批流一体解决方案。本次分享将简单介绍腾讯云湖仓一体的架构、方案简介、核心特性，以及使用批流一体 Iceberg 的业务实践，最后还将分享未来规划与社区合作。

主要内容包括以下几个方面：

1. 腾讯云湖仓一体架构

2. 批流一体 Iceberg 简介

3. 批流一体 Iceberg 核心特性

4. 批流一体 Iceberg 业务实践

5. 未来规划与社区合作

分享嘉宾｜周劲松腾讯专家工程师

编辑整理｜梁维

内容校对｜李瑶

出品社区｜DataFun

腾讯云湖仓一体架构

1. 腾讯云大数据产品全景图

首先，简要介绍腾讯云的湖仓一体架构。这是腾讯云大数据产品的全景图。最底层是 IaaS 层，包括 CVM 云主机、TKE 容器服务、CBS 云硬盘、COS 对象存储、CHDFS 云上 HDFS 以及 CFS 文件存储等基础能力。在这之上是丰富的大数据组件，包括大家熟知的云上弹性 Hadoop（EMR 弹性 MapReduce）、Serverless 数据湖计算服务（DLC）、数仓服务（TCHouse）等。此外，还有数据集成服务（InLong）、流计算平台（Oceanus）以及ES服务等。再上一层是数据开发平台（WeData）和 BI 平台，为用户提供便捷的数据处理和分析工具。基于这些大数据组件与服务，我们支持了各种云上用户，包括教育、金融、互联网、出行、政务等。同时，我们还提供面向私有云的私有化方案——TBDS 统一大数据处理套件。以上就是腾讯云的产品架构。

DLC 是一个高度云原生化的产品，其底层完全 Serverless 化，用户无需关注底层的资源部署，只需要使用 SQL/Table 等上层概念完成自己的大数据需求。DLC 内部的数据存储在对象存储 COS。COS 存储的数据量和访问流量将生成存储账单。在 COS 之上，DLC 提供 Iceberg 表的托转存储服务，管理平台会对 Iceberg 表进行自动优化。再上层是计算引擎平台，主要支持的计算引擎包括 Spark 和 Presto 的 Serverless 版本，使用时才会分配计算资源，任务结束后资源即被释放。

此外，DLC 还包括权限管理、引擎管理以及统一元数据和数据治理等组件。DLC 产品的核心特点包括：灵活的弹性计算资源、百万级/秒级的实时数据更新，智能的数据治理以及是云原生湖仓托管存储。

基于上面丰富的大数据产品，腾讯大数据支撑了内部包括微信、QQ、QQ 音乐、企业微信等众多腾讯内的互联网产品。同时这些产品还在腾讯云上服务了更多云上用户，覆盖政务、金融、互联网、出行、教育等多个行业。

批流一体 Iceberg 简介

批流一体 Iceberg，是腾讯云自 2019 年以来，在开源 Iceberg 基础上的五年沉淀。开源 Iceberg 功能丰富，提供了强大的基础能力，但要基于它构建完整的湖仓一体数据架构，仍然需要一些额外的组件与服务。

上图展示了整体的湖仓一体架构。最底层是存储层，包括 COS、HDFS、S3 等。之上是 Format 层，Iceberg 是重要的湖仓 Format，甚至被很多人视为湖仓格式的标准。同时，还有 Delta、Hudi、Paimon 等其他湖格式。腾讯在 Iceberg 原生湖格式上进行了诸多增强和改进，内部命名为 TC-Iceberg，即腾讯版本的 Iceberg。

再上层是服务层，这是 Iceberg 社区不涉及的部分，开放给更多开源项目、公司或供应商完成。腾讯在服务层提供了优化服务和索引服务和元数据服务。

最顶层是计算层，包括 DLC 这样的 Serverless 计算产品、TC-House 等数仓产品，以及开源的 Flink、Spark、Doris 等计算引擎。

TC-Iceberg 方案主要涉及 TC-Iceberg 的 Format 和服务两个层面，后文中将着重讲解这两部分内容。

批流一体 Iceberg 表基于具体的使用场景分为无主键表和有主键表。

无主键表常见于用户行为日志和传输器数据，数据量大且增量写入频繁，写入以实时或批量 insert 操作为主，偶尔会有离线更新需求，如根据 GDPR 协议删除用户数据。原生的 Iceberg 能很好地支撑这种场景，因此无主键表的底层采用原生的 Iceberg 格式。上图右侧给出了使用 TC-Iceberg 扩展创建无主键表的例子。

有主键表则用户关系型数据库同步的数据或 DWS、ADS 层的数据，这些数据有主键且操作复杂，包括插入、更新、删除等。有主键表的特点是除了 insert 外，还有实时的 update、delete 写入需求及离线更新和数据分析需求。开源 Iceberg 表格式在有主键表场景下能力存在一些不足，TC-Iceberg 在这个场景做了一些增强。因为原生 Spark 不支持主键定义，我们扩展了 Primary key 语法以定义主键。同时支持在 TBLPROPERTIES 中定义 merge function。

除了表格式之外，批流一体方案还提供了丰富的表服务，涵盖数据湖表的三类优化：首先是文件合并，包括合并碎片文件、将增量数据合入存量数据中，以及合并 delete 文件和 insert 文件。其次是数据清理，如自动处理湖仓表快照过期、清理孤儿文件，以及设置数据生存时间（TTL）以自动删除过期数据。最后是无效 delete 文件的清理。

此外，分析加速也至关重要。为满足湖仓一体的存储需求，我们已实施多项措施加速分析性能，如数据排序、二级索引（支持 Bloom Filter 和 Bitmap）以及表统计信息和分区统计信息的构建，这些优化一方面可以帮助查询条件更准确的赛选需要读取的内容，另一方面帮助查询引擎制定更合理的执行计划，它们一同帮助提升表上的分析性能。

批流一体 Iceberg 核心特性

批流一体 Iceberg 有主键表由 base store 和 change store 两部分构成。Base store 存储存量数据，包含 Insert File 和 Position Delete File 两种文件；而 change store 则专门存放增量数据，通常由实时引擎如 Flink 进行写入和读取，其中的数据会自动合并至 base store，且仅保留一段时间，过期后自动删除，change store 仅包含 Insert File。

除了这两张表，批流一体 Iceberg 还有两个核心过程：merge on read 和 auto compaction。Merge on read 在读取时同时读取 base store 和 change store 的数据，并在读取过程完成合并，提供分钟级延迟的分析能力，同时解决写放大问题。而 auto compaction 则负责及时合并 change store 的数据到 base store 中，避免读放大问题，与 merge on read 共同平衡增量更新场景下的读写放大问题。

此外，change store 和 base store 作为独立的 Iceberg 表，均可通过 Iceberg 原生方式进行读写。当对数据延迟要求不高时，可直接读取 base store 的数据，以获得更好的分析性能。

merge on read 和 auto compaction 的过程非常类似，在写入量较大时都存在较大性能风险。为了提升数据合并效率，TC-Iceberg 通过自动分桶技术来降低合并开销。

数据写入时会根据写入数据的主键进行 hash 分桶，这样能够保证只有相同桶内的 change 数据和 base 数据才需要合并，从而减少了合并的数据范围，提升了合并并行度。把 change store 和 base store 的数据合并看作两个表的 join 操作，而自动分桶则利用了 hash join 的分布式 join 思路，不同的是在数据写入时就完成了 hash 分桶过程，减少了计算时的 shuffle 开销。

值得注意的是，base store 和 change store 支持采用不同的分桶策略。一般来说，base store 的数据量更大，因此每个桶的数据量会控制在 1 到 2GB 之间；而 change store 则根据写入流量来设置，通常保证每次写入的数据文件不小于 1MB。即使两者的分桶数量不同，只要分桶规则采用成倍扩张的方式，仍能实现有效的合并优化。虽然这可能导致 change store 的数据在任务中被读取多次，但相较于拆分数据带来的碎片文件和元数据压力，这种开销是可以接受的。

TC-Iceberg 将 change store 和 base store 拆分为两部分，以一种简单自然的方式支持了 CDC 数据的流式消费。增量数据以 append 方式写入 change store，支持通过流式读取方式获取 CDC 数据。这种拆分方式很好地实现了 CDC 案例。Iceberg 社区也一直在讨论如何支持 CDC 和更高效的实时更新写入。目前，大家认为 TC-Iceberg 提出的使用两张表的方案最为合理，对 Iceberg 表侵入最小且可以灵活扩展。

最后，我们来讨论 TC-Iceberg 合并过程的扩展。具体而言，写入 change store 的数据如何合并到 base store，其合并方式是可扩展的。这种需求非常普遍，Paimon 和 Hude 等系统都提供了 merge function 的扩展，TC-Iceberg 同样如此。

目前，已实现的 Merge function 包括 replace，即使用增量数据覆盖原有数据；以及 partial update，即增量数据仅覆盖部分列，其他列保持不变。partial update 常用多张表的实时打宽。

此外，还支持 Aggregation，类似于预聚合过程，base 表中存储的是增量数据与原有数据经过聚合函数（如 min、max、count 等）计算后的结果。

上图是 TC-Iceberg Service，即智能存储服务的架构图。管理服务作为核心组件，它本身是无状态的且支持多节点部署，提供 Rest API、Table 元数据管理、数据优化任务管理以及 Metrics 统计等功能。

Optimizers 负责具体执行优化任务，同样是无状态的，可根据集群负载动态伸缩，并能在 Flink、Spark 引擎或 K8s pod 中原生部署。

Metrics reporter 作为关键组件，以插件的形式集成到引擎中，上报表上的 Metrics 至管理服务，助力更智能的数据优化任务调度。Metrics 包括表提交 Metrics 和表查询 Metrics，前者通知管理服务表上有新写入，后者则揭示表的查询频率、查询条件及常用查询字段，使数据优化更具针对性，避免资源浪费。

批流一体 Iceberg 业务实践

批流一体 Iceberg 方案已经帮助腾讯云上的大量用户完成湖仓一体大数据存储架构的升级。以某在线教育客户为例，他们使用数据湖最初的目标是用 Iceberg 替换 Hive，将 ODS 层从 Hive 转为 Iceberg 湖格式，并将实时数据写入数据湖，从而降低实时数据同步的成本并减少延迟。

他们的业务数据存储在 MySQL 数据库中，这部分数据通过入湖工具导入 TC-Iceberg。随后，DLC 中的 Spark 和 Presto 直接查询 TC-Iceberg 中的数据，进行数据分析或数据开发。最终，得到的结果数据被用于 BI 报表。

这一实践展示了批流一体 Iceberg 在数据湖应用中的优势，为用户提供了高效、低成本的数据处理方案。

另一个案例来自国内某头部票务服务商，在他们的订单分析、内容推荐相关业务系统中，有一个案例值得分享。该用户最初也经历了将 ODS 层进行湖仓一体化的过程。他们不仅在 ODS 层，还在 DWD 层和 DWS 层中推进了湖仓一体化建设。根据业务需求，使用 Spark 进行离线数据加工，使用 Flink 进行实时数据加工，但底层存储统一采用 TC-Iceberg。

我们帮助用户落地湖仓一体化时，通常经历两个步骤：首先解决 ODS 层问题，然后逐步推进到 DWD/DWS 层。在此过程中，我们根据用户需求，选择一种能平衡成本和需求的方案，确定使用实时链路还是离线链路。这样的策略确保了湖仓一体化建设的顺利进行。

未来规划与社区合作

腾讯云批流一体 Iceberg 在设计与实现上与开源社区保持着紧密的合作。

TC-Iceberg Format 方面，我们在 Apache Amoro Mixed Format 上拓展了 merge function，支持部分列更新和聚合函数，弥补了其仅支持 replace 的不足。同时，我们用 change file 替换了 change store 中的 insert file 和 equality delete file，以适应腾讯云大部分 upsert 场景的需求，提升了 upsert 性能，并使 CDC 数据更加准确。

在管控方面，我们拓展了 Metric Reporter，这是 Iceberg 社区天然支持的拓展能力，可智能调度策略并丰富监控信息。此外，我们还优化了 table statistics 和 partitions statistics 等统计信息，以加速 Iceberg 表的分析性能。

目前，我们正计划将这些功能推向社区，预计将在 0.9 版本中与大家见面，敬请期待。

TC-Iceberg 方案致力于打造全场景湖仓一体解决方案。目前，本方案仅支持分钟级或小时级数据延迟，而 TC-Iceberg 计划拓展秒级数据延迟能力。具体而言，我们将尝试将 change store 拓展至支持秒级传输的系统，如 MQ 或 KV 系统，以满足特定场景的需求。这与当前社区的 log store、change store、base store 三层架构有所不同，我们计划整合 log store 和 change store 以减少数据重复，并提供秒级数据处理能力。

此外，物化视图是当前热门技术之一，无论是 Spark、Flink 等引擎社区，还是 Iceberg 等湖格式社区都在积极探讨。我们计划将物化视图技术商业化落地，通过一套 SQL 统一批流一体计算。用户只需设定物化视图的刷新频率，底层即可根据需求选择批计算、微批或实时计算模式。在此方案中，TC-Iceberg Format 将支持物化视图的定义，而 TC-Iceberg Service 将支持物化视图的刷新。

下一步我们将主要尝试实现上述两大功能，并与 Amoro 社区共同建设。若您对这些功能感兴趣，欢迎加入社区，与我们携手共建这些特性。