作者：徐润柏
用户背景
37手游着重强化自身游戏运营能力、市场推广能力、广告设计能力，提出了立体化、AI智能化营销的“流量经营”策略。37手游秉承“创新点亮梦想，分享成就未来”和“相信创造奇迹”的文化理念，强调创新、分享、自信、梦想和追求的经营理念。
业务需求
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 对上下游生态的开放、对全局索引的支持、对 Flink 1.13 版本的支持，以及对 Hive 版本的兼容性 (Iceberg 不支持 Hive1.x 的版本) 等原因，选择了 Hudi 作为湖仓一体和流批一体的存储引擎。
综合对比之后，37手游采用的最终方案为：以 Flink1.13.2 作为计算引擎，依靠 Flink 提供的流批统一的 API，基于 Flink-SQL 实现流批一体，Flink-CDC 2.0 作为 ODS 层的数据同步工具以及 Hudi-0.10 作为存储引擎的湖仓一体，解决维护两套代码的业务痛点。
平台建设
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 架构已经足够。
未来规划
37手游选择的湖仓一体以及流批一体架构对比传统数仓架构主要有以下几点好处：
Hudi 提供了 Upsert 能力，解决频繁 Upsert/Delete 的痛点；
提供分钟级的数据，比传统数仓有更高的时效性；
基于 Flink-SQL 实现了流批一体，代码维护成本低；
数据同源、同计算引擎、同存储、同计算口径；
选用 Flink CDC 作为数据同步工具，节省了 Sqoop 的维护成本。
目前尚未解决的主要是频繁增加表字段的痛点需求，需要同步下游系统的时候能够自动加入这个字段，希望 Flink CDC 社区能在后续的版本提供 Schema Evolution 的支持。
