作业帮 MySQL 千表入湖仓实践：资源节省 81%，数据采集效率大幅提升
InfoQ 作者 | 作业帮大数据团队（孙建业、白振冬）
背景
随着作业帮业务的快速发展，对数据采集的要求也越来越高。然而，传统的 MySQL 数据采集链路存在着诸多问题，例如资源消耗过高、稳定性不足、维护成本高昂等，严重影响了数仓表产出和业务分析。
挑战
为了解决这些问题，作业帮决定将 MySQL 数据采集从 Hive 迁移到 Iceberg。然而，迁移过程中也面临着诸多挑战：
- 部分 MySQL 表更新频率高，存量数据多（百亿级别），单行大小差异很大（Byte 到 10M+），如何自动适配避免人工维护？
- 如何以最少的资源消耗，同时兼顾采集稳定性？
- 数据准确性如何保障？迁移过程中需要考虑哪些风险？
- 历史包袱和迁移效率如何平衡？
- 项目启动时 Iceberg 1.1、Flink CDC 2.4 存在一些功能缺陷，如何解决？
方案设计
经过深入分析，作业帮团队最终选择了将 MySQL 增量数据写入 Iceberg 表，并利用 Spark 进行 Merge 写入历史 ODS 的方案。
方案对比
| 方案 | 优点 | 缺点 |
|—|—|—|
| Flink Upsert 直接写 Iceberg 表 | 可提供更高数据更新时效性| 1）历史天级别快照 vs 最新数据，业务接受程度低；2）Flink Iceberg Upsert 实现通过 equality delete 完成，受数据更新速度、单行大小等情况影响，查询时会导致不稳定，如果文件太多还有 OOM 风险。还需额外维护 Compaction 动作； |
| Flink Upsert + 定时同步分区快照数据 | 提供更高时效性数据（需求较少），同时一定程度兼容历史用法 | 1）Spark Snapshot 按照事件准确切分实现复杂度高；2）较方案一，Iceberg 读稳定问题未能解决 |
|写入改为增量，利用 Spark 做 Merge 写入历史 ODS | 技术栈成熟，稳定性容易把握，迁移对业务无感 | 数据更新本质是批处理，时效性多为小时级别 |
方案细节
- Iceberg 表设计: 作业帮团队根据数据特点和业务需求，设计了高效的 Iceberg 表结构，并利用分区和索引优化数据查询效率。
- 增量数据采集: 利用 Flink CDC 采集 MySQL 增量数据，并将其写入 Iceberg 表。
- 历史数据迁移: 利用 Spark 将历史 Hive 数据迁移到Iceberg 表，并进行数据清洗和转换。
- 数据质量保障: 通过数据校验和监控机制，确保数据迁移和采集过程中的数据准确性。
- 资源优化: 通过优化 Flink CDC 和 Spark 任务配置，以及利用资源隔离技术，将资源消耗降低了 81%。
成果
- 资源节省 81%: 通过优化方案和技术手段，将资源消耗降低了 81%，有效提升了资源利用率。
- 采集效率提升: 数据采集速度大幅提升，表就绪时间 TP90缩短至 2 小时内，有效提升了数仓表产出效率。
- 数据稳定性提升: 采集链路更加稳定，减少了数据采集失败和数据丢失的风险。
- 维护成本降低: 简化了数据采集流程，降低了维护成本，提高了运维效率。
未来展望
作业帮团队将继续优化数据采集方案，探索更先进的技术，进一步提升数据采集效率和数据质量，为业务发展提供更强大的数据支持。
参考文献
关键词: MySQL, Iceberg, 数据采集, 湖仓, 资源节省, 效率提升, 稳定性, 维护成本, 数据质量, 作业帮
Views: 0