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

主要观点总结

文章介绍了作业帮大数据团队在历史数据采集过程中遇到的问题以及解决方案。由于历史采集能力存在资源消耗多、稳定性弱、维护成本高的问题，团队决定使用新的方案来解决这些问题。新的方案包括将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%的迁移资源，架构收益包括表级采集独立、解除中心式依赖、平台化管理、血缘链路完整等。

文章预览

来自公众号： InfoQ 作者 | 作业帮大数据团队（孙建业、白振冬）  历史背景 历史采集链路比较陈旧，随着公司业务变化，对数据采集要求变高。历史采集能力主要暴露出三个方面的问题。 资源消耗多 ：采集 3000 多张表增量数据约 1T，消耗资源 1W 多核，表就绪时间 TP90 6 点多甚至更晚，影响数仓表产出和业务看数，尤其是业务高峰期月份； 稳定性弱 ：表间采集链路、资源不隔离，互相影响明显。例如同集群大表刷数影响小表就绪时间、偶发性更新数据量太大导致任务运行失败、单条数据太大超过 Kafka 限制导致异常等等； 维护成本高 ：历史包袱重，链路冗长且复杂，全增量采集程序异构。多套采集链路并行，平台管控有限，强依赖研发人员熟悉程度。采集表基数大，出现问题概率比较高，需要持续人工解决。 目标和挑战 23 年我们完成了日志采 ………………………………