资源节省 81%，作业帮 MySQL 千表入湖仓实践

运维 · 公众号 · 运维 · 2025-03-12 12:28

主要观点总结

文章介绍了作业帮大数据团队在历史数据采集过程中遇到的问题以及解决方案。由于历史采集能力存在资源消耗多、稳定性弱、维护成本高的问题，团队决定使用新的方案来解决这些问题。新的方案包括将Mysql采集由入Hive改为Iceberg，并使用Flink CDC进行数据采集。文章还介绍了方案设计、数据迁移、资源收益和架构收益等关键点。

关键观点总结

关键观点1: 历史采集能力存在的问题

资源消耗多、稳定性弱、维护成本高，影响数仓表产出和业务看数。

关键观点2: 解决方案概述

决定将Mysql采集由入Hive改为Iceberg，并使用了Flink CDC进行数据采集。

关键观点3: 方案设计

介绍了三种方案的优势和劣势，包括Flink Upsert方式、增加定时同步分区快照数据、写入改为增量等。

关键观点4: Iceberg表设计

为保证采集流程表级别隔离，采用每组MySQL表对应一个Iceberg表的设计。利用Iceberg表存储Change Log数据。

关键观点5: 数据迁移的挑战和风险

包括数据准确性保障、历史包袱和迁移效率平衡、以及遇到的技术问题等。

关键观点6: 资源收益和架构收益

资源收益方面节省了81%的迁移资源，架构收益包括表级采集独立、解除中心式依赖、平台化管理、血缘链路完整等。

正文

请到「今天看啥」查看全文

方案对比

方案一：Flink Upsert 方式直接写 Iceberg 表

优点：可提供更高数据更新时效性；
缺点：1）历史天级别快照 vs 最新数据，业务接受程度低；2）Flink Iceberg Upsert 实现通过 equality delete 完成，受数据更新速度、单行大小等情况影响，查询时会导致不稳定，如果文件太多还有 OOM 风险。还需额外维护 Compaction 动作；

方案二：较方案一增加定时同步分区快照数据

优点：提供更高时效性数据（需求较少），同时一定程度兼容历史用法
缺点：1）Spark Snapshot 按照事件准确切分实现复杂度高；2）较方案一，Iceberg 读稳定问题未能解决

方案三：写入改为增量，利用 Spark 做 Merge 写入历史 ODS

优点：技术栈成熟，稳定性容易把握，迁移对业务无感；
缺点：数据更新本质是批处理，时效性多为小时级别；

设计细节

Iceberg 表设计

Iceberg 表存储的是 Change Log 数据。为了保证采集流程做到表级别隔离，避免互相影响导致核心表就绪时间晚，采用每组（适配单集群分库分表场景） MySQL 表对应一个 Iceberg 表。将 Iceberg 表抽象为灵活且一致的 Schema，既可以保障字段变化的扩展性，也降低了字段类型映射等平台的开发成本。Iceberg 查询场景为全列 Scan，也不用顾虑复杂类型查询无法下推的影响。

基于 Flink CDC 采集设计

Flink CDC Source 读 Mysql Binlog 数据，同时加入了一些 ETL 处理。例如加解密、数据内容转义等等