37手游为什么需要FlinkCDC + Hudi湖仓一体方案实践？

37手游的原有技术架构如上图所示，主要存在如下业务痛点：

1. 数据实时性不够 • 日志类数据通过 sqoop 每 30min 同步前 60min 数据到 Hive； • 数据库类数据通过 sqoop 每 60min 同步当天全量数据到 Hive； • 数据库类数据通过 sqoop 每天同步前 60 天数据到 Hive。

2. 业务代码逻辑复杂且难维护 • 目前 37 手游还有很多的业务开发沿用 MySQL + PHP 的开发模式，代码逻辑复杂且很难维护； • 相同的代码逻辑，往往流处理需要开发一份代码，批处理则需要另开发一份代码，不能复用。

3. 频繁重刷历史数据 • 频繁地重刷历史数据来保证数据一致。

4. Schema 变更频繁 • 由于业务需求，经常需要添加表字段。

5. Hive 版本低 • 目前 Hive 使用版本为 1.x 版本，并且升级版本比较困难； • 不支持 Upsert； • 不支持行级别的 delete。

由于 37 手游的业务场景，数据 upsert、delete 是个很常见的需求。所以基于 Hive 数仓的架构对业务需求的满足度不够。

针对上述业务痛点，37手游在技术选型方面做了如下考虑： • 在同步工具的选型上，考虑过 Canal 和 Maxwell。但 Canal 只适合增量数据的同步并且需要部署，维护起来相对较重。而 Maxwell 虽然比较轻量，但与 Canal 一样需要配合 Kafka 等消息队列使用。对比之下，Flink CDC 可以通过配置 Flink connector 的方式基于 Flink-SQL 进行使用，十分轻巧，并且完美契合基于Flink-SQL 的流批一体架构。 • 在存储引擎的选型上，目前最热门的数据湖产品当属：Apache Hudi，Apache Iceberg 和 DeltaLake，这些在37手游的场景下各有优劣。

最终，基于 Hudi 对上下游生态的开放、对全局索引的支持、对 Flink1.13 版本的支持，以及对 Hive 版本的兼容性 (Iceberg 不支持 Hive1.x 的版本) 等原因，选择了 Hudi 作为湖仓一体和流批一体的存储引擎。 综合对比之后，37手游采用的最终方案为：以 Flink1.13.2 作为计算引擎，依靠 Flink 提供的流批统一的 API，基于 Flink-SQL 实现流批一体，Flink-CDC 2.0 作为 ODS 层的数据同步工具以及 Hudi-0.10 作为存储引擎的湖仓一体，解决维护两套代码的业务痛点。

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