37手游如何基于FlinkCDC + Hudi湖仓一体方案开展实践？

37 手游的湖仓一体方案，是 37 手游流批一体架构的一部分。通过湖仓一体、流批一体，准实时场景下做到了：数据同源、同计算引擎、同存储、同计算口径。数据的时效性可以到分钟级，能很好的满足业务准实时数仓的需求。

MySQL 数据通过 Flink CDC 进入到 Kafka。之所以数据先入 Kafka 而不是直接入 Hudi，是为了实现多个实时任务复用 MySQL 过来的数据，避免多个任务通过 Flink CDC 接 MySQL 表以及 Binlog，对 MySQL 库的性能造成影响。通过 CDC 进入到 Kafka 的数据除了落一份到离线数据仓库的 ODS 层之外，会同时按照实时数据仓库的链路，从 ODS->DWD->DWS->OLAP 数据库，最后供报表等数据服务使用。实时数仓的每一层结果数据会准实时的落一份到离线数仓，通过这种方式做到程序一次开发、指标口径统一，数据统一。

在架构上还有专门的数据修正 (重跑历史数据) 处理链路，这主要是考虑到有可能存在由于口径调整或者前一天的实时任务计算结果错误，导致重跑历史数据的情况。一方面存储在 Kafka 的数据有失效时间，不会存太 久的历史数据，重跑很久的历史数据无法从 Kafka 中获取历史源数据。再者如果把大量的历史数据再一次推 到 Kafka，走实时计算的链路来修正历史数据，可能会影响当天的实时作业。

所以针对重跑历史数据，会通过数据修正这一步来处理。 总体上说，37 手游的数据仓库属于 Lambda 和 Kappa 混搭的架构。流批一体数据仓库的各个数据链路有数据质量校验的流程。第二天对前一天的数据进行对账，如果前一天实时计算的数据无异常，则不需要修正数据，Kappa 架构已经足够。

以上内容摘自《Apache Flink 案例集（2022版）》电子书，点击https://developer.aliyun.com/ebook/download/7718 可下载完整版