摘要：本文整理自米哈游大数据实时计算团队负责人张剑，在 FFA 的分享，本篇内容主要分为三个部分：
- 发展历程和平台建设
- 场景应用实践
- 未来展望
一、发展历程和平台建设
米哈游成立于 2011 年，致力于为用户提供高品质、超出预期的产品和服务。公司陆续推出多款人气产品，如崩坏学园 2、崩坏 3、未定事件簿、原神以及社区产品米游社等。
随着公司的快速发展，实时计算需求应运而生。我们基于 Flink 计算引擎构建了实时计算平台。依据需求及主要工作的不同划分为三个阶段。
第一阶段，以 Datastream API 开发为主的 Flink 平台。第二阶段，以 Flink SQL 为主的一站式开发平台。第三阶段，一站式开发平台的功能深化和场景覆盖。
为什么选择 Flink？首先是基于 Flink 框架优异的特性，如毫秒延迟、窗口计算、状态管理、容错恢复。同时蓬勃发展的社区，对 Flink 的引入充满信心。
1.0 阶段主要是以 Datastream API 开发为主，初步具备了任务管理以及运维能力。但随着开发人员增多，基于 Datastream API 开发弊端稍加显现，如开发难度大，版本易冲突、运维难度大等。
2.0 阶段为了解决大家的问题，构建了以 Flink SQL 为主的一站式开发平台，主要基于 Flink 1.10 和 1.12。平台的主要工作主要分为如下四个方面：
- 加强多云跨区域任务管理能力的建设。
- 增强 Flink SQL 能力以及丰富上下游连接器。
- 构建指标和日志体系。
- 完善元数据以及任务血缘的管理。
基于一站式开发平台较大的提高了大家的开发效率。截止目前，Flink SQL 占比总任务数达 90%以上。
随着业务的发展，大家提出了新的期望。总结起来有如下几点：
- 越来越多的同学加入，对任务的调优和调参方面希望能够降低成本。
- 部分业务的流量波动性较大，希望能有任务的自动扩缩容管理机制。
- 部分常见的 ETL 任务，用 Flink SQL 开发也有较大的成本，希望能够基于配置生成 Flink 任务。
- 对数据的时效性有了新的期望，希望数据入仓能够分钟可查，或者基于近实时数仓开发。
基于此，3.0 阶段主要是一站式平台开发功能深化和场景覆盖。我们思考的方向主要有如下四个方面：
- 静态和动态资源调优。
- 自动扩缩容。
- 资源弹性能力。
- 加强近实时数仓的建设。
静态资源调优指用户开发完一个任务，依据其基本的业务逻辑及探测当前时刻的任务流量，结合本身任务的设置来给定初始资源，同时优化一些不合理的选项，避免用户反复调试。动态调优指一个任务已经上线运行。根据作业收集的指标信息，不断调整任务的资源，来满足任务的正常运行，避免反压及流量波动所带来的影响。从中可以看出，动态调优需要平台具备自动扩缩容的管理机制。而自动扩缩容的管理机制又对底层资源的弹性具有一定的要求。
平台的整体架构，主要分三个部分：
- 用户权限及鉴权。
- 功能和服务。主要包含：概览大盘、作业开发、版本管理、作业运维、作业日志、元数据及血缘、监控告警、资源调优、自动扩缩容、弹性资源管理、安全管控。
- 资源和环境。主要包含：多元环境执行端、资源管理器、跨云跨区域的环境管理。
二、场景应用实践
第一个重要的应用场景是全球游戏日志标准化采集加工。众所周知，日志处理是大数据处理的重要方面，有些日志的重要性不亚于数据库里的数据。Flink 承担着公司全球游戏业务每天近百亿的日志处理，峰值流量过千万。依据采集方式的不同将数据来源分为两大类。
- 通过 Filebeat 的采集。
- 通过日志上报服务接收之后传输到 Kafka 实时数据总线。
经过 Flink SQL 处理、加工、写入下游的存储，比如 Clickhouse、Doris、Iceberg。同时，我们会对采集、加工、处理等环节的数据延迟和数据质量加以监控和校正。提供给下游的业务，比如客服查询系统、运营实时分析、离线数仓等。
第二个应用场景是实时报表和实时大屏。放到一起是因为它们通常会涉及到聚合指标的计算。我们针对重要的指标，根据业务需求提供实时大屏服务，同时针对运营基于 BI 报表提供实时指标的应用查看，让运营能够及时了解当前游戏的运行状况，方便给业务侧做分析判断。
基于实时指标的应用的案例：社区帖子排序。主要用到的是实时指标。社区帖子排序通常会涉及到数据关联，这也是 Flink 比较强项的能力。
社区帖子排序的数据主要源于两个方面。第一个是通过客户端埋点上报，通过 Kafka 接收，Flink 通过流式消费 Kafka 来实现数据的接入。第二个是在业务库，比如 MySQL 的分库分表，我们通过 Flink CDC 能够很方便的获取 Binlog 的实时数据，然后将分库分表的数据写入下游 KV 存储，通过另外一个任务进行流表关联，实现数据打宽的目的。
但为什么和上图内容不一样呢？这是因为这一常见链路有两个弊端。第一个是引入了 KV 存储，如 Hbase，任务链路的复杂度就会提高。第二个是这里假定流的速度慢于维表更新的速度，否则就会导致数据关联不上。
为了解决这些问题，我们在 Flink SQL 中将流表关联任务和 Flink CDC 任务在同一个任务里进行接入，采用的是 Regular Join 的方式。这里可能就会有同学会有疑问，用 Flink SQL 需要设置一个统一的状态过期时间，那么维表状态数据会被清理掉，这样不就没办法进行关联了吗？
这里我们拓展了 Flink SQL 的能力，能够在 SQL 层面控制底层状态细化的生存周期。比如可以将维表的状态设置为不过期，从而实现数据关联，之后再经过指标计算，提供给后端帖子排序服务做前端展示。
第三个应用场景是近实时数仓。主要有两个方面：
第一个方面是离线入仓近实时化改造。
以前数据离线入仓往往是通过小时级 ETL 任务进行的，每个小时数据入仓后，下游的调度任务才能够依次启动。对于较大的日志数据，更是可能会耗费 10-20 分钟不等，占据每个小时的 20%~30% 的时间。
经过日志入仓近实时化的改造，通过实时任务来写入 Iceberg 表，同时对采集、加工、写入的延迟加以监控，通过日志文件的元信息和实时计算的元信息进行比对来保证数据质量。最后，针对 Iceberg 表建立 Iceberg Manager 管理中心，主要是小文件合并优化、快照清理等。
从离线日志近实时数仓改造能得到两个明显的收益。一是离线存储的 IO 从之前的每个小时波动性较大到现在较为平稳，二是数据入仓的时效从以前的每小时到分钟级。
第二个方面是数据库数据一键入湖。
相较日志，数据库的数据 Schema 相对具有结构化，我们可以自动探测 Schema 一键生成入湖的任务。依托平台的自动调优以及扩缩容的能力，自动提交任务运行。
针对数据库的数据同步，主要会分为两条链路。第一个是通过 Flink CDC 进行全量同步写入 Iceberg V2 表，同步时关闭 upsert 功能，保证写入不会产生太多 delete file。第二个是采用 Flink CDC 做增量同步，通过 Flink SQL 再写入同一个 Iceberg V2 表。过程中我们发现，有时候很多任务可能会对同一个数据源进行消费，这一过程会对上游业务库有一定的压力。所以我们做了一定的优化，将 Flink CDC 采集的数据先写入 Kafka。后面如果再有新的任务对同一个数据源消费，会被自动感知，切换到已经同步过数据的 Kafka 上，避免对业务库产生压力。
数据库数据一键入湖的收益：一方面是从原来需要经过 Flink SQL 到现在基于配置式任务开发，在开发效率上有较大的提高，另一方面从以前离线的批量拉取，过渡到现在对 Binlog 的实时消费，避免了数据库的压力。
下面分享一个近实时数仓的应用案例。如下图所示，这是我们提供的玩家战绩查询，主要是通过 Flink SQL 任务将实时数据写入 Iceberg 表，然后通过实时任务进行排序、计算等操作，写入中间 Iceberg 表，最后通过同步任务将数据同步给战绩服务，给玩家提供查询。
第四个应用场景是实时风控。在米哈游，风控团队和实时计算团队联系密切，我们一起拓展了在风控领域的作用。良好的风控服务无疑也是彰显 Flink 在风控领域较为强大的作用，我们基于风控引擎构建了一套相对自动化的任务管理方式，让实时计算平台服务化。
首先根据指标规则，自动拆解任务，自动化做任务创建以及任务调优运行。依靠底层的弹性能力能够比较方便的保证任务的正常运行。同时，我们会对计算完成的指标数据以及原始数据实时入湖。经过每个小时做全量指标校验以及线上规则全面监控来保证实时数据的准确性。拓展的应用场景比如登陆校验、游戏反作弊、人机校验等。
三、未来展望
第一、Flink 奠定了实时计算领域的基础，我们将着重加强平台能力的建设，主要有如下四个方面：
- 加强 Flink SQL 及本身能力的建设，包括流处理、批处理的能力。
- 增强资源调优，包括静态资源调优，动态资源调优。目的是让业务开发人员更多的关注业务本身，而无需关心其他技术性问题。
- 做好自动化运维的工作，降低用户的运维成本。
- 拓展弹性能力。我们现在是基于 Yarn On K8s 的模式，未来我们将推进 Flink Native K8s，借助 K8s 本身优秀的资源管理能力，来实现弹性和更好的应用体验。
第二、探索更多的使用场景，有如下三个方面：
- 基于 Flink SQL 实现延迟消息的服务结合 Kafka，就能相对简单的提供给消息队列团队，帮助其更好的发展。
- 基于 Flink CDC 的 Binlog 服务提供给运维团队，助力业务发展。
- 加强应用级别指标能力建设，帮助业务开发团队更好的发展业务。
最后，数据湖和 Table Store 的不断实践，主要有如下方面：
首先，数据湖正处于高速发展，Table Store 也崭露头角。随着新版本的发布，让我们基于流批一体的生产实践有了基础，我们也在不断探索流批一体的生产实践。
其次，在进一步探索近实时数仓的建设。过去离线数仓、实时数仓相对割裂，在建设近实时数仓时，如何基于数据的确定性和数据的无界性，在近实时数仓中得以平衡。比如，我们是否可以基于近数据源产生类似 WaterMark 的一种机制来在流数据上保证一定的确定性，或者是文件的 FileMark 来实现等同于离线批处理的确定性含义呢？另外，离线数仓往往有完善的任务调度和依赖，方便用户进行补数、重跑等操作。那么在建设近实时数仓管理中心的时候，我们是否也需要相应的功能呢？这些都是值得我们探索和思考的地方。