关于后端:快手-Flink-的稳定性和功能性扩展

摘要：本文整顿自快手技术专家刘建刚，在 Flink Forward Asia 2022 生产实践专场的分享。本篇内容次要分为四个局部：

1. 快手 Flink 平台
2. 稳定性保障和智能运维
3. 简单场景下的性能扩大
4. 批处理的定制优化

点击查看原文视频 & 演讲 PPT

一、快手 Flink 平台

1.1 计算平台架构

如上图所示，Flink 次要运行在 Yarn 和 K8s 上，存储组件应用 HDFS 和快手自研的 kwaistore。在 Runtime 层，同时反对流解决和批处理。在用户结构层，次要包含 Data Stream 和 SQL。最下面一层是快手的作业管理平台，包含前端和后端。

基于 Flink 计算生态，周边组件囊括万千。既有 Kafka、RocketMQ 等中间件，又有 Clickhouse、Druid 等 OLAP 剖析，还有 Hudi、Hive 等存储层。最外层是利用场景，涵盖了音视频、商业化、数据工厂、湖仓一体等利用场景。

1.2 架构演进

架构演进

• 在 2018 年~2019 年，咱们搭建了实时计算平台，在 Data Stream、SQL 计算、大状态存储等方面，为用户提供生产可用的性能。
• 在 2020 年~2021 年，咱们对 SQL 进行了进一步的优化和推广，对 Flink Runtime 进行了深度革新。
• 在 2021 年~2022 年，咱们开始摸索流批一体。与此同时，在稳定性和功能性方面，进行了深度革新。
• 将来，咱们会摸索更加智能的流批交融，进一步丰盛计算生态。

1.3 将来布局

上图是将来布局的大一统架构。从用户的角度来看，不再须要关怀流和批，以及简单的流批配置。对用户裸露的将是简略的资源提早和吞吐配置，底层计算引擎会依据这些配置智能执行。

Flink 将作为对立的计算层，为用户裸露对立的 SQL 和 Data Stream API。对立的调度器，会解决用户的资源调度和算子调度。增量和全量计算对应用户的提早要求。如果用户心愿尽快失去后果，能够应用更短的增量触发。

在批处理方面，咱们心愿能在 Streaming 内核的根底上，达到业界当先。除此之外，Shuffle 对用户的吞吐至关重要。咱们心愿可能在 Pipeline 和 Blocking 之间智能切换，实现最大的吞吐。

在流批的智能切换和无缝交融方面，须要在性能和平滑过渡上多做一些工作，为用户屏蔽具体的细节。在存储层通过对立的治理，为用户展示统一的 Table 表。

二、稳定性保障和智能运维

2.1 主动迁徙

稳定性保障和智能运维 。因为咱们常常会遇到机器下线、队列下线、集群下线的状况。此时，如果让用户本人迁徙作业会十分麻烦，次要有三个方面。

• 机器下线是常态化的事件，会频繁烦扰用户。
• 当波及的用户作业数较多，手动操作十分繁琐。
• 沟通老本较大，会节约大量的工夫。

如上图所示，先来看一下单作业的主动迁徙。对于用户来说，只须要配置 AutoMigrate 参数即可，该参数能够配置三个值。

• Normal 值示意主动驱赶 Container 并复原。
• Exactly-Once 示意 stop-with-savepoint 并复原。
• Manual 示意告诉用户 Dealine 前手动解决，否则主动解决。

当用户配置完参数，Flink 平台会在机器下线时，主动帮忙用户操作。次要分成以下四步。

• 第一步，将下线的机器标记为不再调度。
• 第二步，找到对应的 Flink 作业。
• 第三步，依照用户的配置，进行自动化迁徙。
• 第四步，当所有作业都迁徙完后，机器就能够正式下线。

除了单作业的主动迁徙，咱们还具备集群迁徙的教训。集群迁徙的复杂性次要体现在以下三点。

• Flink 及其上下游的数据一致性很难失去保障。
• 上千个作业，操作简单，稳定性难以保障。
• 用户泛滥，沟通运维老本极高。

为此咱们开发了一套自动化迁徙程序。如上图所示，单个作业会在新集群，主动拷贝一个新作业。而后，通过 stop-with-savepoint 进行老作业，在新集群启动新作业。在启动时，咱们会跨集群读取老作业的 Savepoint。除此之外，咱们会通过各项指标查看作业的衰弱度。一旦呈现问题，立即回滚。

波及集群操作时，咱们会进行批量的灰度操作。如右图所示，咱们通过批量的灰度，操作这些作业。一旦呈现问题，会立即回滚，并且告知用户尽快染指。

为了保障上下游 Kafka 数据的一致性，Flink 针对 Kafka 进行了深度革新和适配。在生产端，Kafka 会 Mirror 最近一段数据到新集群，确保 Offset 和数据都一样，Flink 主动切换到新集群生产。

在产出端，Kafka 也会主动 Mirror 数据到新集群，当 Flink 主动切换后，新数据会写到新集群，确保 Offset 和数据统一。

2.2 故障归因

故障归因次要探讨不确定性的硬件故障，次要有以下三点。

• 磁盘故障，比方磁盘坏道、内核故障等引起的读写卡顿问题。
• 内存故障，比方局部数据脏写、gc 频繁等。
• 网络故障，比方网卡异样导致无奈连贯等问题。

这些问题的共性是，导致作业卡顿或者体现异样，但又不是彻底的失败，定位十分艰难，甚至无奈查出问题所在。当规模比拟大时，这种问题会频繁呈现。

接下来，介绍一下应答计划。咱们的应答计划次要包含以下四点。

• 主动拉黑。既包含在作业粒度，将机器拉黑。也包含在平台纬度，将一个机器彻底拉黑。
• 智能归因。咱们会监控 Flink 算子的异样 Task，比方某个 Task 的提早、吞吐、快照等有显著异样。咱们会把它迅速拉黑。
• 人工疾速辨认。当咱们狐疑一批机器有问题时，会疾速计算独特的机器，并进行指标剖析。一旦确定异样，立即拉黑。
• 建设施行故障指标库。尽管离线计算可能容忍很多机器问题，但实时计算不能容忍。咱们须要辨认这些 Case，并且疾速的解决，避免作业呈现问题后处理。

故障归因 。故障归因的目标是，将人工运维的教训，积淀到自动化程序里，进一步解放开发人员、运维人员和应用人员。次要分为作业失败和作业性能两个诊断。

在作业失败方面，查问单个用户作业失败的起因时，首先去 ES 获取作业失败的起因。如果是用户的问题，间接返回给用户。如果是心跳超时，去 Yarn 查问 Host 和 Container 的存活性，而后再去 metric 零碎查问是否 gc 等信息。

如果是其余问题，先看一下是否在系统诊断库里，如果是就可用间接返回。如果不是，间接给用户返回异样。与此同时，人工会排查起因，并把它退出诊断库。

作业性能问题的排查 。首先，进行宽泛查看。比方资源是否打满，数据是否歪斜。而后，找到第一个有问题的 Task。如果这个作业有快照，咱们就会找到第一个快照失败的 Task。

如果没有快照，咱们会递归查问反压，并依据 Task 的 Input Queue 来判断它是不是第一个呈现问题的 Task。

如果确定了第一个呈现问题的 Task，会为用户返回资源、线程等相干信息，辅助用户确定根本原因。

2.3 分级保障

分级保障 。分级保障是指给予不同优先级作业，不同的保障级别，其背景如下。

• 在资源缓和的状况下，咱们会优先保障高优的作业。
• 咱们会为高优的作业提供平台化的保障措施，比方热备、冷备等计划。
• 咱们会依据优先级统筹规划，进步整个集群的利用率。

如上图所示，咱们为作业划分了四个等级，其中 P0 为双 AZ 容灾（热备）、P1 为双 AZ 容灾（冷备）、P2 示意单集群惯例作业、P3 示意不重要的作业资源，随时可能被抢占。

上面重点介绍一下冷备计划和抢占计划。Flink 的冷备计划既反对 Flink 冷备，也反对 Kafka AZ 容灾，次要指生产两个同名的 Topic 和写出两个同名的 Topic。同名 Topic 在不同的 AZ 下，两个同名的 Topic 独特组成一份残缺的数据。

这时如果上游的一个 Kafka 集群挂掉，Flink 会主动容灾，并推动 watermark 的后退，整个作业不受影响。Flink 在惯例状况下，通过轮转写的形式，将数据写到上游的两个 Topic。如果一个 Topic 挂掉，数据会全副导到另一个 Topic。

针对 Flink 作业，咱们会定期将快照写到备集群。一旦作业管理平台监测到 Flink 所在的 AZ 挂掉，会主动在备集群拉起一个一样的 Flink 作业。

将来，咱们将实现 HDFS、Kafka 的双 AZ 部署，到时它们会主动 AZ 容灾并为 Flink 出现逻辑视图。

资源有余时的抢占计划 。抢占策略次要有三点。

• 高优作业抢占低优作业资源。
• 优先抢占不衰弱的作业，比方 lag 重大的作业。
• 实时作业会优先抢占同一个作业的资源。

右图展现了咱们的抢占成果。作业通过革新，在资源有余时，也能启动。

常见的保障措施 ，次要包含以下四点：

• 资源隔离。高优作业能够独自划定队列，实现物理隔离，同时不与离线作业混部。
• 资源抢占。在资源缓和状况下，高优作业可主动抢占低优作业的资源。
• AZ 容灾。高优作业可实现 AZ 容灾，包含冷备和热备。
• 智能监控报警。高优作业配套的报警更加欠缺，一旦呈现预期之外的问题可疾速人工染指。

三、简单场景下的性能扩大

3.1 弹性伸缩

在简单场景下的功能性扩大。这里次要讲三个局部，即弹性伸缩、Remote Shuffle Service、云盘存储。接下来，来看下弹性伸缩的背景。

• 第一，Flink 作业以后的动态资源分配个别都是依照最高峰申请的，导致了其余时间段的资源，大量节约。
• 第二，PerJob 模式调整并发度慢，须要进行作业、批改并发度、启动作业等繁琐流程。
• 第三，用户不晓得该配置多少资源，有的提早重大、有的资源节约重大，带来了各种运维问题。

基于以上背景，咱们开发了更轻量级的弹性伸缩计划，用户或者平台决定好并发度后，间接发给 Flink 作业，Flink 作业在不进行作业的状况下疾速实现调整。

先来看一下整体的架构实现，用户能够间接触发扩缩容或者配置扩缩容的条件。比方当 CPU 或 IO 超过多少之后，进行调整。AutoController 作为自动控制的组件，会依据用户的配置，主动实现作业的弹性伸缩，比方依据 metric 主动触发调整。

在 Flink 外部，咱们实现了疾速 rescale 的接口。伸缩原理如下，如果是扩容，会提前申请资源，而后将并发度长久化到 ZK 里，来避免 Master Failover，而后从新生成执行图。在进行时，默认应用 stop-with-savepoint。

弹性伸缩的成果 。扩缩容工夫，惯例聚合作业从分钟级别升高到 10s 左右，惯例 ETL 作业 3s 内可实现调整。通过平台调整，作业资源占有量显著降落，能够无效整顿集群的资源利用率。将用户从作业资源调整的繁琐运维中解放出来，极大地缩小了人工运维工作。

3.2 Remote Shuffle Service

Remote Shuffle Service。Flink 由 TaskManager 来治理 Shuffle 数据，计算和存储耦合，存在以下问题：

• 一旦 TaskManager 挂掉就会造成 Shuffle 数据失落，存在重跑整个工作的危险。
• 闲暇 TaskManager 因为 Shuffle 数据的存在而无奈退出，导致资源节约。
• Shuffle 代价大，无论是网络连接、还是磁盘读取，开销都比拟大。

快手外部自研的 Shuffle Service 次要采纳 Master slave 架构。接下来，介绍一下 Flink 和 Shuffle Service。Flink 的 StreamShuffleMaster 负责跟 Shuffle Service 的 ShuffleManager 交互。

Task 的 Reader 和 Writer 通过心跳从 StreamShuffleMaster 处获取读写地址，将数据读写到 Shuffle Service。Shuffle 数据会长久化到 HDFS，避免数据失落。

数据交互流程 。针对上下游的交互，两头数据以 ReducePartition 的模式存在。Shuffle Service 负责将上游 Task 的数据聚合到一块，上游 Task 到时候只须要一对一的程序读取即可。Shuffle Service 在网络和磁盘方面做了很多的优化，确保了整个 Stage 的疾速数据传递。

咱们的 Shuffle Service 反对多种传输模式，包含 AII to all、Point-wise、Broadcast。

其中，All to all，指的是上游每个 Task 将数据轮询发送到上游。Point-wise，指的是上下游依照倍数关系来映射，这样会缩小连贯的个数。Broadcast 指的是上游的一个 Task，将全量数据别离发送到每个上游的 Task。

3.3 云盘存储

云盘 。快手自研的零碎反对 Flink 的状态存储到近程的共享云盘。如上图所示，相干背景次要有三点。

• 存储和计算资源的不对等或者不匹配，决定了存算拆散这一大趋势，二者能够独立开发和保护。
• Flink 作业常常受磁盘故障的影响，单盘故障不可避免。
• 快手将来的机器会逐步下掉本地盘，全副采纳近程存储的形式。

云盘存储的实现，对于用户来应用很简略，只须要配置是否应用云盘即可。如果用户应用云盘，咱们将 Flink 作业调度到反对云盘的机器上，Flink 会像应用本地盘一样应用云盘，操作非常简单。因为云盘的数据是长久化的，所以咱们能够间接应用云盘的数据，不须要将快照写到 HDFS 等中央。

四、批处理的定制优化

4.1 准确性

快手批处理的定制优化，从准确性、稳定性、应用性三个方面解开开展介绍。在准确性方面，次要通过双跑来验证。首先，选取一批无内部拜访、无随机性的线上 SQL。

而后，针对单个线上 Hive 作业，主动调度一个 Flink 镜像作业并读取数据源并写到测试表。最初，基于 Hash 算法验证数据的一致性。这种办法还会被用来跑回归测试，确保新增性能不影响数据的正确性。

4.2 稳定性

在稳定性方面，快手首先提出并解决了所有批处理都会遇到的三个关键性问题。

• Remote Shuffle Service。咱们通过存算拆散，防止 Container 挂掉后，从头复原的问题。
• 揣测执行。次要通过通过镜像 Task 解决离线简单环境下的长尾问题。
• Adaptive scheduler。咱们能够依据数据量主动决定算子的并发度，防止人工重复调整。

针对离线作业，后面专门开发了主动 Failover 机制。相干背景如上图所示，咱们的离线环境十分的简单，次要体现在以下三点。

• 高优作业抢占低优作业重大。
• 磁盘压力大，文件呈现问题的概率也大。
• 网络吞吐大，网卡被打满的景象时有发生。

主动 Failover 机制会自动识别异样。如果是平台引起的，会帮忙用户主动容灾。如果是用户的谬误，会依照失常配置的 Failover 策略走。除此之外，咱们的 Failover 机制是可插拔的，目前涵盖了抢占磁盘故障、网络故障等常见的平台问题，这些故障会主动帮忙用户复原作业。

Client 和 Job 的存活一致性。在利用场景里，客户端承载着更新作业进度、获取后果、查看作业存活等重要工作。所以咱们必须确保客户端和 Flink 作业的存活一致性。

当 Job 挂掉时，Client 疾速感知失败并退出。当 Client 挂掉时，Job 能疾速退出，避免成为孤儿作业。

为此咱们在 Client 和 job 之间建设了心跳机制，来确保二者的存活一致性，确保了任何极其状况下都能互相感知。这种机制能够应答各种极其 Case，比方 Kill -9。

4.3 易用性

易用性的革新。首先，反对近程文件加载。比方通过 -C 加载近程的 classpath。其次，通过 SQL 加载近程的 Udf，应用办法是通过 Add jar remoteUdf 加载近程文件，极大的扩大了 Flink 的应用范畴，为大一统的 Flink 计算，打下了松软的根底。

接下来，介绍下 Web 智能路由和日志查看。尽管咱们的离线环境十分多，但咱们通过智能路由，帮忙用户屏蔽了这些细节。用户能够间接由客户端，主动跳转到对应的集群和作业。

除此之外，日志查看对用户的 Debug 十分管用。用户通过平台，能够疾速跳转查看各种各样的日志。最初，当日志完结作业，咱们也反对一键跳转到 History Server。

点击查看原文视频 & 演讲 PPT

更多内容

流动举荐

阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
0 元试用 实时计算 Flink 版（5000CU* 小时，3 个月内）
理解流动详情：https://click.aliyun.com/m/1000372333/