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

主要观点总结

文章介绍了作业帮大数据团队将Mysql数据采集从Hive改为Iceberg的过程，包括历史背景、目标和挑战、方案设计、运行细节和对数迁移等方面。目标是解决历史采集能力暴露出的问题，提高数据采集的稳定性和效率。实施过程中遇到了包括OOM问题、锁问题、主从切换、资源消耗等问题，并给出了相应的解决方案。

关键观点总结

关键观点1: 历史背景和问题

作业帮大数据团队面临数据采集的三大问题：资源消耗多、稳定性弱、维护成本高。

关键观点2: 目标和挑战

为了解决上述问题，决定将Mysql采集由入Hive改为Iceberg，需要平衡的问题包括数据准确性、迁移速度等。

关键观点3: 方案设计

提出了三种方案来解决数据采集问题，包括Flink Upsert方式直接写Iceberg表、增加定时同步分区快照数据等方案，并详细设计了Iceberg表设计和基于Flink CDC采集设计。

关键观点4: 运行细节

实际运行中的细节包括设计数据同步批次大小和并行度、避免业务线上访问影响等。

关键观点5: 收益和效果

迁移后的收益和效果包括资源收益和架构收益，例如资源节省占比达到81%，新的数据就绪时间减少等。

文章预览

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