本文共计3975字 预计阅读时长12分钟
导语
国内首场 Apache Iceberg Meetup 在深圳成功举办，腾讯云在活动中分享了 Iceberg 在腾讯云大数据中的成功实践，并推出了 TC-Iceberg 批流一体开放智能数据湖解决方案，帮助企业高效维护数据湖架构。
1、活动概览
2025年1月17日，国内首场 Apache Iceberg Meetup 在深圳圆满落幕。
本次活动由 Apache Iceberg 社区、腾讯云大数据与 AutoMQ 联合主办，汇聚了微信、华为终端云、Bilibili等行业先锋企业。活动吸引了数百名 Iceberg 技术爱好者踊跃报名，现场50余位来自各企业的技术专家与行业精英齐聚一堂，线上直播间观看量突破万人，展现了 Iceberg 技术在国内的广泛关注与影响力。
活动探讨了 Iceberg 在湖仓一体架构中的业务实践，包含5场深度技术分享，覆盖流批一体、实时分析、指标计算、特征加工等前沿话题：
● 腾讯云大数据专家 & Amoro PMC 成员周劲松：《腾讯云 TC-Iceberg：基于Iceberg 批流一体智能湖仓》，分享了在云原生湖仓场景下腾讯云大数据基于 Iceberg 构建的完备涵盖批流一体、智能数据优化的湖仓前沿解决方案。
● AutoMQ 联合创始人 & CTO 周新宇：《AutoMQ Table Topic：基于 Iceberg 构建流式数据湖新范式》 ，展示了如何通过 AutoMQ 流表一体化的解决方案 Table Topic 构建 Iceberg湖仓 “流式写入 + 实时分析” 一体化链路。
● B站资深开发工程师张明磊：《Iceberg助力B站商业化模型样本行级更新的实践》 ，分享了B站针对广告场景模型样本的行级更新需求，实现了 Iceberg 的 Update on Column技术，显著提升 Label 更新时效的实践。
● 微信专家工程师王龙：《Iceberg在微信实验平台的应用实践》分享 ，基于Iceberg 改造实验平台湖仓架构，通过技术优化并结合实时查询引擎 ，实现千万级存储与计算成本节约的业务实践。
● 华为终端云技术专家李立伟：《Iceberg 在华为终端云的应用实践》，分享了华为终端云基于Iceberg 优化离线特征管理，解决特征冗余、计算效率低及任务阻塞问题，实现显著资源消耗降低与高可用实时分析的业务实践。
这些分享主题全方位展现了 Iceberg 的成熟应用及技术价值，也反映了腾讯云作为社区核心贡献者的引领作用。参会者通过行业头部企业的落地案例，深入理解了湖仓技术如何驱动业务创新。
2、TC-Iceberg——
腾讯云数据湖与Iceberg的技术邂逅
腾讯云自 2019 年起就开始接触 Apache Iceberg 项目，开始基于 Iceberg 构建湖仓一体数据架构。并在 2021 年以 Iceberg 为底层标准存储格式推出了核心产品数据湖计算服务（DLC）。DLC底层依托腾讯云对象存储（COS），集成 Spark、Presto 计算引擎，用户无需关注硬件资源即可完成数据分析与开发。DLC作为云上 Serverless 湖仓产品，具备弹性计算（按需分配资源，任务结束后资源自动释放）、百万级数据实时写入（结合 Iceberg 快照机制实现分钟级延迟分析）以及高效治理（自动优化碎片文件、清理过期数据）。本次分享的腾讯云 TC-Iceberg 解决方案也已在 DLC 产品上线，为用户带来完美覆盖批流一体业务的智能湖仓构建体验。
基于 Iceberg 拓展的批流一体统一湖格式底座
TC-Iceberg 表基于具体的使用场景分为无主键表和有主键表。
无主键表常见于用户行为日志和传输器数据，数据量大且增量写入频繁，写入以实时或批量insert操作为主，偶尔会有离线更新需求，如根据 GDPR 协议删除用户数据。原生的 Iceberg 能很好地支撑这种场景，因此无主键表的底层采用原生的 Iceberg 格式。上图右侧给出了使用 TC-Iceberg扩展创建无主键表的例子。
有主键表常用关系型数据库同步的数据或 DWS、ADS 层的数据，这些数据有主键且操作复杂，包括插入、更新、删除等。有主键表的特点是除了 insert 外，还有实时的 update、delete 写入需求及离线更新和数据分析需求。开源 Iceberg 表格式在有主键表场景下能力存在一些不足，TC-Iceberg 在这个场景做了一些增强。因为原生Spark不支持主键定义，我们扩展了 Primary key语法以定义主键。同时支持在 TBLPROPERTIES 中定义 merge function。
TC-Iceberg 有主键表由 BaseStore 和 ChangeStore两部分构成。BaseStore存储存量数据，包含Insert File 和 Position Delete File 两种文件；而 ChangeStore 则专门存放增量数据，通常由实时引擎如 Flink 进行写入和读取，其中的数据会自动合并至 BaseStore，且仅保留一段时间，过期后自动删除，ChangeStore 仅包含 Insert File。
除了两张表独立存储之外，TC-Iceberg 还有两个核心能力：Merge-On-Read 和 Auto Compaction。Merge-On-Read在读取时同时读取 BaseStore 和 ChangeStore 的数据，并在读取过程完成合并，提供分钟级延迟的分析能力。而 Auto Compaction 则负责及时合并 ChangeStore 的数据到 BaseStore 中，避免读放大问题，与 Merge-On-Read 共同平衡增量更新场景下的读写放大问题。
此外，ChangeStore 和 BaseStore 作为独立的Iceberg表，均可通过 Iceberg 原生方式进行读写。当对数据延迟要求不高时，可直接读取 BaseStore 的数据，以获得更好的分析性能。
Merge-On-Read 和 Auto Compaction 的过程非常类似，在 数据源写入量较大时都存在较大性能风险。为了提升数据合并效率，TC-Iceberg 通过自动分桶技术来降低合并开销。
数据写入时，TC-Iceberg会根据写入数据的主键进行 hash 分桶，这样能够保证只有相同桶内的 change 数据和base 数据才需要合并，从而减少了合并的数据范围，提升了合并并行度。把 ChangeStore 和BaseStore 的数据合并看作两个表的 join 操作，而自动分桶则利用了 hash join 的分布式 join思路，不同的是在数据写入时就完成了 hash 分桶过程，减少了计算时的 shuffle 开销。
值得注意的是，BaseStore 和 ChangeStore 支持采用不同的分桶策略。一般来说，BaseStore 的数据量更大，因此每个桶的数据量会控制在1到2GB之间；而 ChangeStore 则根据写入流量来设置，通常保证每次写入的数据文件不小于1MB。即使两者的分桶数量不同，只要分桶规则采用成倍扩张的方式，仍能实现有效的合并优化。虽然这可能导致 ChangeStore 的数据在任务中被读取多次，但相较于拆分数据带来的碎片文件和元数据压力，这种开销是可以接受的。
TC-Iceberg 将 ChangeStore 和 BaseStore拆分为两部分，以一种简单自然的方式支持了 CDC 数据的流式消费。增量数据以 append 方式写入 ChangeStore，支持通过流式读取方式获取 CDC 数据。这种拆分方式很好地实现了 CDC 案例。Iceberg社区也一直在讨论如何支持 CDC 和更高效的实时更新写入。目前，大家认为 TC-Iceberg 提出的使用两张表的方案最为合理，对 Iceberg 表侵入最小且可以灵活扩展。
最后，我们来讨论 TC-Iceberg 合并过程的扩展。具体而言，写入 ChangeStore 的数据如何合并到 BaseStore，其合并方式是可扩展的。这种需求非常普遍，TC-Iceberg通过merge function来支持。目前，已实现的 merge function 包括 replace，即使用增量数据覆盖原有全部数据；以及 partial update，即增量数据仅覆盖部分列，其他列保持不变。partial update 常用多张表的实时打宽。
智能化 Iceberg 湖仓管理服务
上图是 TC-Iceberg Service，即智能存储服务的架构图。管理服务作为核心组件，它本身是无状态的且支持多节点部署，提供 Rest API、table 元数据管理、数据优化任务管理以及 metrics 统计等功能。
Optimizers 负责具体执行优化任务，同样是无状态的，可根据集群负载动态伸缩，并能在Flink、Spark 引擎或 K8s pod 中原生部署。
Metrics reporter 作为关键组件，以插件的形式集成到引擎中，上报表上的 metrics 至管理服务，助力更智能的数据优化任务调度。Metrics 包括表提交 metrics 和表查询 metrics，前者通知管理服务表上有新写入，后者则揭示表的查询频率、查询条件及常用查询字段，使数据优化更具针对性，避免资源浪费。
批流一体 Iceberg 业务实践
实践一：在线教育平台 ODS 层实时入湖
以某在线教育客户为例，他们使用数据湖最初的目标是用 Iceberg 替换 Hive，将 ODS 层从 Hive 转为 Iceberg 湖格式，并将实时数据写入数据湖，从而降低实时数据同步的成本并减少延迟。
他们的业务数据存储在 MySQL 数据库中，这部分数据通过入湖工具导入 TC-Iceberg。随后，DLC 中的 Spark 和 Presto 直接查询 TC-Iceberg 中的数据，进行数据分析或数据开发。最终，得到的结果数据被用于 BI 报表。
在这个客户实践中体现了批流一体 Iceberg 在数据湖应用中的优势，为用户提供了高效、低成本的数据处理方案。
实践二：票务平台DWD层流批统一处理
另一个案例来自国内某头部票务服务商，在他们的订单分析、内容推荐相关业务系统中，有一个案例值得分享。该用户最初也经历了将 ODS 层进行湖仓一体化的过程。他们不仅在 ODS 层，还在DWD 层和 DWS 层中推进了湖仓一体化建设。根据业务需求，使用 Spark 进行离线数据加工，使用Flink进行实时数据加工，但底层存储统一采用 TC-Iceberg。
我们帮助用户落地湖仓一体化时，通常经历两个步骤：首先解决 ODS 层问题，然后逐步推进到DWD/DWS 层。在此过程中，我们根据用户需求，选择一种能平衡成本和需求的方案，确定使用实时链路还是离线链路。这样的策略确保了湖仓一体化建设的顺利进行。
未来规划与展望
TC-Iceberg 方案致力于打造全场景湖仓一体解决方案。目前，本方案仅支持分钟级或小时级数据延迟，而 TC-Iceberg 计划拓展秒级数据延迟能力。具体而言，我们将尝试将 ChangeStore 拓展至支持秒级传输的系统，如 MQ 或 KV 系统，以满足特定场景的需求。这与当前社区的 Log Store、ChangeStore、BaseStore 三层架构有所不同，我们计划整合 LogStore 和 ChangeStore以减少数据重复，并提供秒级数据处理能力。
此外，物化视图是当前热门技术之一，无论是 Spark、Flink 等引擎社区，还是 Iceberg 等湖格式社区都在积极探讨。我们计划将物化视图技术商业化落地，通过一套 SQL 统一批流一体计算。用户只需设定物化视图的刷新频率，底层即可根据需求选择批计算、微批或实时计算模式。在此方案中，TC-Iceberg Format 将支持物化视图的定义，而 TC-Iceberg Service 将支持物化视图的刷新。
与社区共生共长
腾讯云大数据团队坚持拥抱开源生态，与开源社区一同成长，共同推动湖仓一体的技术发展。在数据湖表格式方面，团队持续参与到 Apache Iceberg 社区当中，未来还将持续优化 Iceberg Flink Connector 的性能，二级索引方面社区定义了元数据标准，但是具体的实现还较欠缺，团队会将生产实践中验证过的二级索引实现贡献给社区，再就是物化视图的标准和管理，这一块团队也在和社区积极讨论中。
数据湖表管理方面，团队积极参与到 Apache Amoro 社区当中，计划将已经得到大量实践的 Metric Reporter 贡献给社区，帮助其实现事件驱动的优化，以减少数据优化成本。同时会与社区一起实现 Table Statics / Partition Statics 收集等特性。同时 TC-Iceberg 有主键表的部分列更新，聚合函数等特性我们也在与社区讨论集成进 Amoro Mixed Format 中。
本次盛会不仅是国内社区的里程碑，更展现了 Iceberg 生态“厚积薄发”的蓬勃力量，这一技术盛会落地生根的底气，不仅在于腾讯云作为核心推动者在技术、资源与场景实践中的全方位支持，更源于 Iceberg 在国内外的海量用户基础及成熟的场景应用。
作为 Iceberg 社区的重要共建者，腾讯云大数据将持续深化开源协同，联动开发者打磨数据湖标准范式，驱动行业突破实时分析、湖格式治理等关键技术挑战。未来期待以 Iceberg 为纽带的技术生态持续加速协同，在各领域持续解锁更多数据价值场景，为国内数字化底座赋予更强大的跃迁动力。
3、结语
本次盛会不仅是国内社区的里程碑，更展现了 Iceberg 生态“厚积薄发”的蓬勃力量，这一技术盛会落地生根的底气，不仅在于腾讯云作为核心推动者在技术、资源与场景实践中的全方位支持，更源于 Iceberg 在国内外的海量用户基础及成熟的场景应用。
作为 Iceberg 社区的重要共建者，腾讯云大数据将持续深化开源协同，联动开发者打磨数据湖标准范式，驱动行业突破实时分析、湖格式治理等关键技术挑战。未来期待以 Iceberg 为纽带的技术生态持续加速协同，在各领域持续解锁更多数据价值场景，为国内数字化底座赋予更强大的跃迁动力。
腾讯云数据湖计算（DLC）已集成 TC-Iceberg，提供开箱即用的云上流批一体 Serverless 智能湖仓构建体验，助力企业低门槛构建高性能、免运维的开放数据湖生态，更多产品信息请访问我们官方网站（点击下方阅读原文即可跳转）
期待下一次与您相逢！
腾讯云大数据始终致力于为各行业客户提供轻快、易用，智能的大数据平台。
END
