乐趣区

关于flink:Flink-在米哈游的应用实践

jiezi

摘要：本文整顿自米哈游大数据实时计算团队负责人张剑，在 FFA 的分享，本篇内容次要分为三个局部：

  1. 倒退历程和平台建设
  2. 场景利用实际
  3. 将来瞻望

点击查看直播回放 & 演讲 PPT

一、倒退历程和平台建设

米哈游成立于 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。平台的次要工作次要分为如下四个方面：

  1. 增强多云跨区域工作治理能力的建设。
  2. 加强 Flink SQL 能力以及丰盛上下游连接器。
  3. 构建指标和日志体系。
  4. 欠缺元数据以及工作血统的治理。

基于一站式开发平台较大的进步了大家的开发效率。截止目前，Flink SQL 占比总任务数达 90% 以上。

随着业务的倒退，大家提出了新的冀望。总结起来有如下几点：

  1. 越来越多的同学退出，对工作的调优和调参方面心愿可能降低成本。
  2. 局部业务的流量波动性较大，心愿能有工作的主动扩缩容管理机制。
  3. 局部常见的 ETL 工作，用 Flink SQL 开发也有较大的老本，心愿可能基于配置生成 Flink 工作。
  4. 对数据的时效性有了新的冀望，心愿数据入仓可能分钟可查，或者基于近实时数仓开发。

基于此，3.0 阶段次要是一站式平台开发性能深入和场景笼罩。咱们思考的方向次要有如下四个方面：

  1. 动态和动静资源调优。
  2. 主动扩缩容。
  3. 资源弹性能力。
  4. 增强近实时数仓的建设。

动态资源调优指用户开发完一个工作，根据其根本的业务逻辑及探测以后时刻的工作流量，联合自身工作的设置来给定初始资源，同时优化一些不合理的选项，防止用户重复调试。动静调优指一个工作曾经上线运行。依据作业收集的指标信息，一直调整工作的资源，来满足工作的失常运行，防止反压及流量稳定所带来的影响。从中能够看出，动静调优须要平台具备主动扩缩容的管理机制。而主动扩缩容的管理机制又对底层资源的弹性具备肯定的要求。

平台的整体架构，次要分三个局部：

  1. 用户权限及鉴权。
  2. 性能和服务。次要蕴含：概览大盘、作业开发、版本治理、作业运维、作业日志、元数据及血统、监控告警、资源调优、主动扩缩容、弹性资源管理、平安管控。
  3. 资源和环境。次要蕴含：多元环境执行端、资源管理器、跨云跨区域的环境治理。

二、场景利用实际

第一个重要的利用场景是寰球游戏日志标准化采集加工。家喻户晓，日志解决是大数据处理的重要方面，有些日志的重要性不亚于数据库里的数据。Flink 承当着公司寰球游戏业务每天近百亿的日志解决，峰值流量过千万。根据采集形式的不同将数据起源分为两大类。

  1. 通过 Filebeat 的采集。
  2. 通过日志上报服务接管之后传输到 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 奠定了实时计算畛域的根底，咱们将着重增强平台能力的建设，次要有如下四个方面：

  1. 增强 Flink SQL 及自身能力的建设，包含流解决、批处理的能力。
  2. 加强资源调优，包含动态资源调优，动静资源调优。目标是让业务开发人员更多的关注业务自身，而无需关怀其余技术性问题。
  3. 做好自动化运维的工作，升高用户的运维老本。
  4. 拓展弹性能力。咱们当初是基于 Yarn On K8s 的模式，将来咱们将推动 Flink Native K8s，借助 K8s 自身优良的资源管理能力，来实现弹性和更好的利用体验。

第二、摸索更多的应用场景，有如下三个方面：

  1. 基于 Flink SQL 实现提早音讯的服务联合 Kafka，就能绝对简略的提供给音讯队列团队，帮忙其更好的倒退。
  2. 基于 Flink CDC 的 Binlog 服务提供给运维团队，助力业务倒退。
  3. 增强利用级别指标能力建设，帮忙业务开发团队更好的倒退业务。

最初，数据湖和 Table Store 的一直实际，次要有如下方面：

首先，数据湖正处于高速倒退，Table Store 也锋芒毕露。随着新版本的公布，让咱们基于流批一体的生产实践有了根底，咱们也在一直摸索流批一体的生产实践。

其次，在进一步摸索近实时数仓的建设。过来离线数仓、实时数仓绝对割裂，在建设近实时数仓时，如何基于数据的确定性和数据的无界性，在近实时数仓中得以均衡。比方，咱们是否能够基于近数据源产生相似 WaterMark 的一种机制来在流数据上保障肯定的确定性，或者是文件的 FileMark 来实现等同于离线批处理的确定性含意呢？另外，离线数仓往往有欠缺的任务调度和依赖，不便用户进行补数、重跑等操作。那么在建设近实时数仓管理中心的时候，咱们是否也须要相应的性能呢？这些都是值得咱们摸索和思考的中央。

点击查看直播回放 & 演讲 PPT

更多内容

Flink Forward Asia 2022

本届 Flink Forward Asia 更多精彩内容，可点击浏览原文或扫描图片二维码观看全副议题的视频回放及获取 FFA 2022 峰会材料！

PC 端观看：https://flink-forward.org.cn/「 倡议返回 FFA 2022 大会官网观看全副议题的视频回放 」

流动举荐

阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/produc…

退出移动版