米哈游在平台建设和迭代过程中遇到了不少的挑战，也产生了一些比较好的实践，主要包括哪四个方面？

1. Executor Service开发和维护 Executor 主要涉及到 Jar 和 Sql 任务解析提交部分。一开始的方案为了解决跨地区传输效率问题，特别是大的jar 包传输，由后端进行任务解析，最后传输 job graph 到 Executor，Executor 再通过资源管理器 Api 提交， 这个因为后端解析环境不一致问题，部分任务解析过程中会存在 action 动作，特别是涉及到 Hive 表和 Iceberg 表部分。最后采用后端不执行，改由 Executor 解析的方案。Executor 在解析过程中，遇到了Executor 在运行很长一段时间后，会出现元空间 OOM 的情况。这个主要是因为 Executor 不断的加载任务需要 Class 类，会导致使用的元空间内存不断增加。这个主要是通过任务解析完成之后，卸载类加载器和堆GC 设置来解决。

2. 监控 监控采用的是 Influxdb 加 Grafana 的方案。随着任务量的不断增加，Influxdb 存储的 Series 超过百万，影响监控查看的稳定性，查询响应缓慢。一是扩展 Influxdb，执行端通过一致性 hash 的方案，分配任务 Metric 上 报到不同 Influxdb。本身通过对 Flink 任务上报 Metric 进行一定程度的精简。其次在监控上，比如 Kafka 消费 监控，目前是支持消费条数的延迟监控，自定义了 Kafka 消费延迟时间的监控，主要是采集了 Kafka 最慢并行度消费的时间，能够反映 Kafka 消费的最大延迟时间，能够反映某个时间点的数据一定被消费了。

3. Connector二次开发 在 CDC 1.0 版本基础上迭代，支持 Mysql 采集的时候动态扩展字段和基于时间启动消费位点、采集的库表、位点等 Schema 信息。在 CDC 2.0 版本基础上，增加了全量读取库表流控和不需要 MySQL 开启 Binlog 的全 量初始化功能。其中多 CDC 实例同步可能会对上游 Mysql 造成压力，采用了 Kafka 作为数据中转，根据库表主键字段作为 Topic 的 Key，保证 Binlog 的顺序，在下游不会出现数据乱序。Iceberg 作为数据湖方案，改造的点主要是 Iceberg V2 表的支持上面，也就是 Upsert 表。建立 Iceberg 管理中心，会根据合并策略定期优化和清理，Flink 写入主要保证在 CDC 到 Iceberg V2 表顺序性，在如何减少 Delete File 上，在 Iceberg 写入上增加了 BloomFilter 的支持，能够显著减少 Delete File 大小。Iceberg 管理中心，支持了 V2 表合并和 Flink 提交冲突问题。Clickhouse 方面，重构了 Clickhouse 写入代码，优化了 Clickhouse 的写入性能，支持了本地表和分布式表写入。

4. 数据入湖和离线调度 实时平台集成了 Iceberg，并支持 Iceberg Hadoop、Hive、Oss、S3 多种 Catalog。CDC 到 Iceberg 入湖链路已经在部门生产业务上线使用。在数据入湖或者入仓中，如果下游表有被离线数仓用到的地方，都会有依赖调度问题，离线任务何时启动？目前米哈游主要通过计算任务的延迟时间和 Checkpoint 时间来确保数据已经入仓入湖。以 CDC 或者 Kafka 到 Iceberg 为例。首先采集 CDC 端采集延迟时间，Kafka 采集最慢并行度延迟时间，同时采集任务 Checkpoint 时间。现在的 Checkpoint 完成，Iceberg 版本不一定会更新，基于此，对 Iceberg 写入进行了改造。这样一个同步任务，如果 CDC 采集端没有延迟，Checkpoint 也已经完成，可以保证某个小时的数据一定已经入仓。实时平台提供任 务延迟查询接口。离线调度以此接口为调度依赖节点。这样就保证了离线任务启动时候，入仓数据的完整性。

• 一是 Flink 动态表存储能够尽快实现落地，实现真正的实时数仓和流表一体； • 二是 Flink 任务动态扩缩容、基于任务诊断的主动资源调整、细粒度资源调整； • 三是 Flink 对批任务的读写优化，目前批任务 Flink 的使用面不如 Spark，如果未来能够在此补足，可以 做到流批操作一个引擎，开发成本会显著降低； • 四是 Flink 加数据湖更好的落地推广。

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