1、刘建刚/技术专家Flink引擎在快手的深度优化与生产实践快手Flink的历史及现状#1容错能力提升#2Flink引擎控制与实践#3快手批处理实践#4未来规划#5目录#1快手Flink的历史及现状发展历程平台化建设典型业务实时化易用性、稳定性、可维护性流批一体、完善生态Flinkstream&batchKafkaRocketMQClickhouseRedisHbaseMySQLHiveHudi电商视频商业化风控湖仓一体机器学习多维分析CDC应用规模2000+作业数50wCPU核6亿/秒峰值处理31.7万亿日处理条数#2容错能力提升容错能力综述#1 单点恢复黑名单，涵盖多种场景的拉黑策略。支持任意

2、多个task fail原地恢复，确保long-running作业永不断流。双集群冷备、热备以及kafka双集群集成，极端情况下数据不丢失。#2 跨集群容灾#3 黑名单单点恢复背景背景Flink为了做到exactly-once，一旦task出现故障必须全局重启。针对at-least-once和at-most-once的场景，这种重启策略带来的停顿时长有时是不可接受的，比如：推荐等实时场景，对服务的可用性要求特别高。模型训练等初始化很慢的应用，重启时间比较长。针对以上场景，全局重启代价比较大，用户更希望能够做到单点恢复，即只恢复失败的task而不影响整个作业。单点恢复基本原理基本原理单点恢复多多T

3、ask恢复恢复跨集群容灾背景背景集群故障会给集群上的服务、数据带来致命性的打击，即便是分钟级别的故障也会给公司带来巨大的损失，为此必须做到跨集群容灾。快手Flink具备以下三种集群跨集群应对方案：冷备。作业在主集群启动，一旦出现故障立刻切换到备集群启动。热备。作业在主备集群同时启动双跑。Kafka双集群集成。单集群Flink可以读写多集群的同名kafka topic并做到自动容灾。跨集群容灾冷备冷备跨集群容灾热备热备跨集群容灾 某个集群挂掉抽象成逻辑Topic的缩容，但是需要保存挂掉partition的state。Kafka单集群切双集群抽象成逻辑Topic的扩容。Kafka topic迁移抽

4、象成逻辑Topic的缩容和扩容。注：由于KwaiFlinkManager是高可用的，所以当前Flink集群挂掉，可以随时从另外一个Flink集群重新启动作业（比如startFromLatest），适用于无需数据保障的低优作业。Kafka双集群集成双集群集成黑名单阈值拉黑作业多次因为某一机器部署或者运行失败，超过配置阈值后，拉黑节点。主动驱逐建立异常分类机制，针对特殊异常，比如网络卡、磁盘故障，直接驱逐容器。外部系统拉黑暴露拉黑接口，联动外部系统，比如运维、yarn等，实现实时拉黑或重启。问题问题 反复调度到故障机器上，导致作业频繁失败。机器因为硬件或者网络等原因，导致Flink个别节点卡住但未

5、失败。策略策略快速容错总览Task失败 单点恢复 Local recovery 流程耗时优化容器挂掉机器挂掉集群挂掉 资源预申请 冗余资源 黑名单 快速发现与摘除 冗余资源 冷备 热备 Kafka双集群集成#3Flink引擎控制与实践引擎能力综述#1 实时控制包含task均衡调度和cpu均衡调度。在不停止作业的情况下调整作业行为。数据源的控制能力，从根源上解决问题。#2 源端控制#3 均衡调度Flink实时控制背景Flink作业都是long-running的实时计算，线上的作业调整时有发生，包括：用户需要调整参数来改变作业逻辑，比如过滤条件；系统需要降级、修改作业日志级别等运维手段。任何的变更

6、升级都需要重启作业，耗时从几分钟到几十分钟不等，这在活动、排查问题等关键时间点是无法接受的，如何做到实时控制至关重要。Flink实时控制将service和compute融合的一种轻量级的热更新模型，提供了交互式的控制模式，在不停止作业的情况下通过restful接口实时控制作业，应对各种极端情况及变更操作。Flink实时控制 用户自定义动态参数，使用方法如下:继承某一RichFunction；通过getRuntimeContext().getDynamicConf()获取动态参数，并实现相应逻辑。系统提供了丰富的实时控制能力：数据源限速 数据源采样 重置kafka offset 开关快照 更改日

7、志级别 拉黑节点源端控制能力背景Flink在处理历史任务或者出现性能问题时，无法实时的处理消息事件，会引发以下问题：各个Task处理进度不一致，会加重数据乱序、丢数据、对齐慢等问题。快照持续变大，严重影响作业正常的数据处理。流量和资源不可控。Flink会尽最大努力去消费数据，会引发cpu打满、oom加重等稳定性问题。由于Flink是一种pipeline的实时计算，有效的数据源控制可以从根本上解决问题。源端控制能力历史数据精准回放功能特性 基于kafka时间戳等进行历史数据回放 统一历史消费和实时消费 解决了复杂大任务的稳定性问题基本原理基本原理=源端控制能力核心特性：基于令牌桶的分布式平稳限速

8、 简单易用，自动适配partition增减 动态配置、实时控制QPS限速源端控制能力数据源对齐1.source的subtask定期汇报自己的watermarkstatus（watermark、watermarkSpeed）2.中心节点计算并返回下一周期的target（所有source预期watermark的最小值）3.source确保下一周期watermark不超过target计算公式=+作业均衡调度背景生产环境中，经常会出现资源使用不均衡的现象，如下所示：作业task分布不均衡导致TaskManager资源使用不一致，作业性能瓶颈受限于最繁忙的节点。作业task cpu使用不均衡，导致有些机

9、器打满、有些机器很闲。针对以上场景，我们开发了作业均衡调度和cpu均衡调度的功能。作业均衡调度Task均衡调度作业均衡调度CPU均衡关键点：作业资源精准画像，根据映射关系分配资源（如图）。资源调度支持cpu均衡，同时限制高cpu的机器分配。按照优先级等条件为作业配置不同的cgroup。task_id+subtask_index-ESSG-containerId-cpu#4快手批处理实践批处理综述#1 应用介绍#2 优化及改进应用介绍应用介绍流批一体探索应用场景：指标计算 数据回溯 数仓加速收益：降低开发和运维成本 保持口径一致 节约资源优化及改进现状：上游失败，下游全部重算，消耗大量资源改善：

10、已经完成的下游不需要重新计算（默认开启）优化及改进优化项做法预期收益Remote shuffle service集成快手内部的shuffle service。1、TaskManager挂掉不会导致partition lost，避免了数据丢失带来的重算。2、利用shuffle service的文件聚合等功能，可以在磁盘IO、网络开销等方面带来显著收益。动态资源调度通过输入数据量来动态地决定Task的并发度。合理利用资源，减少不必要的资源浪费和网络开销。慢节点规避1、自动识别并替代慢Task。2、自动识别卡顿节点并规避。避免长尾效应，减少总执行时间。Hive UDF适配解决部分Hive udf不兼容等问题。Flink批处理和Hive的无缝对接。部分SQL语法不支持针对常规语法，Flink SQL进行补齐Flink批处理和Hive的无缝对接。优化Hive表partition split增加缓存、多线程生成等方式减少分片等待时间支持更多压缩方式及配置支持gzip、zstd等压缩配置有效缓解不同场景下批处理大吞吐量下的压力注：这里为优化项总括，部分已完成，部分正在做。#5未来规划未来规划#1 实时计算在离线混部、弹性伸缩等。继续增强Flink streaming的性能、稳定性、易用性。统一快手的数据同步、转换和在离线计算。#2 统一计算#3 弹性可伸缩2022-01-08THANKS