关于flink:Apache-Flink-在快手的过去现在和未来

本文由快手大数据架构团队负责人赵健博分享，次要介绍 Apache Flink 在快手的过来、当初和将来。内容包含：

1. 为什么选 Flink
2. Flink 在快手的倒退
3. 业务数据流
4. 技术创新
5. 将来打算

一、为什么选 Flink

大家好，我是赵健博，来自快手，目前负责快手大数据架构团队。明天很快乐能够和大家分享咱们在 Flink 我的项目上的利用、改良与倒退历程。

先来看一下咱们抉择 Flink 引擎的次要起因：

• 首先，Flink 能做到亚秒级解决提早。目前大部分的业务需要对实时处理提早要求越来越高，这是个最根本需要。
• 其次，Flink 有丰盛的窗口计算模式，且自带状态存储引擎以及精准一次的语义，这个能力极大简化了数据的解决复杂度，显著晋升了研发的速度。
• 最初，批流一体能力以及研发模式的改革，也将进一步提效研发，为业务赋能。

本次会议也看到了很多公司都在分享批流一体落地实际，置信流批一体全场景落地的大过程也将不可企及。

二、Flink 在快手的倒退

Flink 在快手的倒退历程，总的来说能够分为四个阶段：

1. 咱们是从 17 年开始应用 Flink 的，17 年咱们次要是初步试用，过后接入的业务是直播与短视频的品质监控业务。
2. 进入到 2018 年之后，在能力上，咱们开始对 Flink 进行成周边体系的建设，例如，构建引擎外部 metric 的采集，监控与报警流程、作业托管平台上线等。与此同时，咱们也在一直的加深对 Flink 的了解，修炼内功；在业务上，开始接入直播 CDN 流量调度，日志实时拆分、投放剖析、客户端 Crash 剖析等场景。
3. 进入到 2019 年后，随着对 Flink 引擎掌控力的增强，咱们开始进行一些稳定性与性能相干的改良，次要包含防雪崩，流控、分级保障、参数热更新、自研状态存储引擎 Slimbase、实时多维建模等。在业务上，开始撑持春节流动大屏、实时多维分析、曝光 / 点击流实时 Join 等场景。
4. 到 2020 年后，咱们除了继续关注稳定性性能之外，也在推动效率改良，例如调研并开始试用 Flink SQL，以及流批一体能力。在业务上，采纳 Flink SQL 撑持流动大屏、开始通过 Flink 以及流批一体能力建设 AI 数据流、实时报表、直播精彩时刻等业务场景。

截止到目前，快手 Flink 从业务规模上看有若干集群，集群有数千机器，目前还是部署在 YARN 上，后续也会思考迁徙到 K8s 上。总的作业 2000 左右，这些作业每天解决 20 多万亿条的记录，其中峰值达到每秒 6 亿条的规模。

三、业务数据流

1. 数据流的总体架构图

接下来，让咱们看下快手 Flink 目前利用的一些业务场景与业务数据流的案例。

上面这张图是一个数据流的总体架构图，从这张图中，大家能看到数据的源头有三类数据，一个是数据库中的数据，一个是服务端的日志，最初是客户端的日志，这些日志上报给 Kafka 的服务。

在快手，所有日志或者音讯都是通过 Kafka 服务流转的。数据进入到 Kafka 之后别离流转到实时数据链路，以及离线数据链路上（实时同步到 Hive）。在实时链路上，目前 Flink 撑持了很多业务场景，如：实时 ETL、数据集成、实时报表计算、实时监控、实时实时特色等等。这些数据通过 Flink 实时计算解决之后，将流入到各种类型的数据库中，例如多维数据库（Druid/Clickhouse），MySQL、Redis、HBase 等等。之后各类的数据产品、数据利用、业务利用从这些数据库中获取最新的聚合或者后果数据，进行业务的解决。

2. 实时 ETL 场景

接下来，咱们开展介绍下上述各个场景下的业务数据流图。在实时 ETL 场景下，目前咱们次要在推广应用 Flink SQL 进行数据的实时 ETL。下图左侧展现了实时 ETL 的流程，其中 Kafka 中的 topic 的 schema 都被元数据服务治理起来了。Flink 引擎首先拜访元数据中心获取 Topic 的 schema，而后将 Topic 转成实时表，并通过 SQL 实现 ETL 的解决落地。右侧的 SQL 是咱们进行数据拆分的案例。

3. 数据集成场景

在数据集成场景下，如左图所示，通过 Flink 引擎能够很不便地实现 Kafka/HBase/ES/Hive/Redis 等服务的数据交换。相比于其余引擎，Flink 的 source/sink 反对的服务品种更丰盛，且更加不便扩大。除此之外，除了离线数据交换，Flink 是人造撑持实时场景的。

4. 实时报表的场景

在实时报表的场景下，介绍下 Flink 反对快手春节流动的实时数据链路。

如图所示，整个数据流从左到右共分为 4 层，别离是 ODS 层、采样层、指标逻辑计算层、数据服务层。

1. 最开始是原始的 ODS 层数据，通过客户端，服务端，或者是 DB 间接打到 Kafka 的 topic 中造成一个 ODS 层，这一层的数据通过 Flink 的解决，再写回 Kafka，造成一个采样层。
2. 采样层提出来的起因次要是，面向春节流动的流量顶峰，没法精准预知它的峰值有多高，所以咱们须要具备对整个流量进行采样的能力，以便可能在无限的资源下应答洪峰。一旦洪峰来了，能够进行数据采样解决，无效升高计算资源的耗费，同时再通过采样的规定在后续逻辑计算层还原采样之前数据指标的后果。
3. 数据被采样之后再通过 Flink 进行逻辑层的计算，例如留存、新增、PV、UV 等指标，而后将这些指标最终保留到 Redis 或者多维引擎中。在这个计算过程中，过后采纳的是内部存储与服务进行了 UV，以及新增的计算。在将来的流动撑持中，咱们会逐步替换为 Flink 本人的 state 引擎。
4. 最初，各类数据产品与服务，如大屏，看板等，从 Redis 或者多维引擎中获取数据进行展现以及策略的调整。

1. 实时监控场景

在实时监控这个场景下，介绍下快手直播品质监控和 CDN 流量调度链路。

首先数据通过埋点采集，打到 Kafka 之后，在实时链路的解决上，通过 Flink 进行数据的荡涤、转换、聚合，造成 DWD 和 DWS 层的数据，这些数据也会最终写回 Kafka。之后，会把 DWS 层的数据导到前面的 OLAP 这种数据库中。而后下层的 BI 服务通过拜访数据库中的数据进行报表的展现，从而实现监控，以及数据决策。同时，品质计算的调度后果数据存储 Redis，供在线 CDN 调度服务提供决策依据。

在离线链路上，能够思考从实时链路中的每一层进行数据的导出，导到 Hive 表中。这部分数据的保留次要是为了解决 Ad hoc 剖析，以及当实时流数据呈现问题，进行的离线的数据修改。

6. 特色解决场景

最初一个业务场景，介绍一个 AI 数据流案例，特色解决与索引生成流程。在快手，有大量的特色须要解决，特色的解决与管理效率对模型迭代效率有很大影响。采纳 Flink 进行特色与索引的解决，在治理上与研发效率上都有比拟大的劣势。

目前咱们借助 Flink 实现了一部分的特色与索引生产流程，如图所示，行为数据通过 Kafka 流入 Flink 之后，利用 Flink 的窗口计算能力实现各种类型的特色实时计算，之后将特色存储到特色库中，同时也会同步一份数据到 Hive 中，用作做特色离线数据流解决；除此之外，当有索引须要生成的时候，会通过 Kafka 触发生成策略，上游的索引生成的 Flink 作业从各种特色库中获取特色并进行解决后，造成索引，存储到索引库中。最终的索引数据，为在线的举荐服务提供召回源。

四、技术创新

1. 状态引擎

接下来重点介绍一下 Flink 在快手做的一些技术改良和翻新。首先介绍下咱们自研的状态引擎 Slimbase。它在设计上分了三层：

• 接口层，在接口层次要兼容目前状态存储的几类接口，value、list、map 状态等。
• 中间层，咱们构建了一个 KV 的 cache 层，次要是做数据的读和写的减速。在这层外部，又分为高速 KV 层和 Chunk 层，高速 KV 层（HashMap）有十分快的存取速度，然而空间利用率比拟低。为了节俭空间，咱们又在整个高速 KV 层上面建了一个 Chunk 层，一个 Chunk 是多个 KV 序列化组成的。通过这种序列化的组织之后，在某些场景下相比于 KV 层可能节俭约 60% 的空间。然而在存取速度上会有肯定水平的升高。理论应用的时候，能够依据理论状况灵便管制高速 KV 层与 Chunk 层的容量配比。
• 分布式文件系统层，缓存层被淘汰的数据将会写入到文件系统层，最终造成一个个文件。为了进步文件系统层面的读取性能，多个文件会通过 compaction 进行合并。此外，文件系统层有文件块级别的缓存，具备缓存热点数据能力。

以上就是 Slimbase 整体架构。上面咱们看看 Flink Benchmark 跑进去后果（和 RocksDB 比照）。本次测试采纳了雷同大小的缓存，数据集采纳了 50w、1500w、5000w 三种规模。

指标是测试三种场景下的后果：

• 仅笼罩高速 KV 缓存；
• 笼罩高速 KV 缓存 +Chunk 缓存；
• 笼罩 KV 高速缓存 +Chunk 缓存 + 文件系统；

这是 50 万的数据集，这些数据集全副是在高速的 KV 层中的。从测试后果上看，相比 RocksDB，Slimbase 读写有 3~9 倍的性能晋升。

1

在 1500w 数据规模下，数据会散布在高速的 KV 层加 Chunk 层，相比 RocksDB，读写有 2~6 倍的性能晋升。

在 5000w 数据规模下，数据命中的档次变得更多，把文件系统也笼罩到了。相比前两个场景，咱们发现性能有比拟大的降落。相比 RocksDB，读性能 0.5~0.7；写性能 0.90~4 倍。所以咱们接下来会在整个文件系统层的存取性能上，会做专项的优化，晋升整个文件系统的性能，最终能够超过 RocksDB 性能。

2. 稳定性

在介绍稳定性的改良前，咱们先来看一下影响 Flink 稳定性的因素有哪些。我这里总结了三点：

• 硬件故障，例如机器故障，机柜故障，Tor 故障，机房故障等。
• Flink 依赖的服务异样，例如 Kafka 集群异样，HDFS 服务异样等。
• Flink 流量过载，例如硬件满载，以及因为数据源生产速度差别导致的满载。

在硬件故障场景下，这外面取了一个单点的场景。看下这个 Flink 作业，由两个 source，一个 window 组成。右侧是 Flink 作业的物理部署的状况。最大的框代表一台机器，大框外面的多个小框代表多个 TaskManager。

如果呈现了一个节点故障，比方 node3 产生故障了。Flink 引擎会从新从 YARN 申请资源，实现 TaskManager 初始化，并重新部署作业。

咱们对一个业务作业做了一个剖析，发现宕机故障后到作业复原，共须要 90s 的工夫。宕机检测 (60 秒)，从新申请资源容器 (5 秒)，容器初始化 (20 秒)，作业重新部署执行 (5 秒）。这对于某些在线业务场景来说是不能承受的。从具体的过程拆解来看，发现宕机检测和初始化的耗费是大头。要如何改良呢？

从解决思路上来说，蕴含两个方面。首先 60 秒的宕机检测，工夫太长了。对此，要做到疾速发现宕机。此外，还要预留资源，当宕机呈现时，能够省去申请资源，以及初始化的工夫。

在宕机疾速发现方面，咱们研发了 Hawk Service，它是一个多数派的连通性检测服务，具体的检测流程是 Hawk 集群中多个工作节点会周期性地检测集群中每台机器的连通性，因为它是多数派的，所以可信度是有保障的。最终，Hawk 服务能够做到在 10 秒钟之内发现一个宕机事件。

此外，在预留资源方面，咱们扩大了 Flink 作业的资源申请模型，在 Flink 提交时能够设定一个资源冗余参数，当冗余参数被激活后，会主动保障冗余资源量会高于单点故障导致的资源缺失量，且在资源排布上防止冗余资源的汇集性。如图所示：

有了这两点能力之后，如果同样是第三台机器挂掉了，咱们能在 10 秒内发现。并且因为资源曾经调配好了，间接部署一遍作业就能够了。所以整体的复原工夫从 4 个步骤间接缩短为 2 个步骤，工夫上从 90s 能够缩短到 15s 左右。

接下来，咱们看看如果 Flink 引擎依赖的服务异样了要怎么办呢？这里举了一个 Kafka 服务异样的例子。还是同样的 Flink 的作业，依赖两个 topic，Flink 作业在 B 机房，读取的 Kafka 也在 B 机房，写入的 Kafka 在 A 机房。如果呈现读取或者写入的 Kafka 集群异样了，Flink 作业须要具备 Failover Kafka 集群的能力，当然如果是切读，Kafka 的上游也须要联动切流。

在过载场景下，我举了两个例子：

• 不同数据源快慢生产导致满载

在这个 case 中，生产 topicA 的 source 速度慢，生产 topicB 的数据源快，因为后边存在 window 操作，会导致 window 的状态继续变大，最终疏导作业不稳固。这个问题要如何解决呢？

咱们采纳的方法是同步所有相干数据源生产的进度，引入一个 source 的协调者（SourceCoordinator），周期性收集 source 源 waterwark 的停顿，并依据全局的现状，预测进去各个 source 源接下来容许读到的最大地位 target Watermark，之后下发给所有的 source，source 依据失去的 target Watermark 以及以后本人 watermark，确定读取速度。最终全局 source 达到同步读的后果，最小 source 和最大 source 的差距在一个可管制的范畴内。

• 硬件资源满载

如果硬件呈现了满载要怎么解决呢？例如，其中一个 TM 所在的机器呈现 CPU 满载了，或者大范畴呈现机器满载。

解决方案跟下面的是相似的，控制数据源的生产速度。如图所示，引入 HealthyCoordinator，周期性查看 TM 上的资源耗费状况，并依据负载限度 source 的生产速度。动静调节所有数据源的生产速度，从而保障 Flink 作业的稳固。

3. 均衡性

第三个方面，我想跟大家分享一下咱们在均衡性上遇到的一个问题。在咱们线上集群的多个机器之间，咱们发现最小和最大的机器的 CPU 负载相差至多在 20% 以上。集群层面的负载不平衡，从稳固上看，可能会触发作业稳定性降落，从老本上，也会造成资源的节约。

在解决均衡性问题前，先来看下引发不平衡的因素都有哪些？梳理了下，可能的起因包含：

• Yarn 层面资源调度不平衡
• 作业资源申请不合理，申请过大
• 作业的并发设置不合理或者 Task 调度不平衡，导致 TaskManager 之间算子 Task 不均
• 数据自身存在不平衡
• 集群扩容，缩容导致不平衡

要解决这些问题，咱们提了一些改良的计划。

• 改良 Task 调度策略，保障 TaskManager 之间算子的 task 尽可能平衡
• Flink 作业采集理论耗费，从新依照理论耗费向 Yarn 申请资源
• Yarn 保障资源分配在机器间平衡
• 在有机器扩容或者缩容时，生产资源耗费平衡的作业调整计划，进行异步的作业调整

通过以上的策略最终保障 Flink 集群整体上的均衡性。

五、将来打算

最初看一下快手在 Flink 上的将来打算。将来，咱们将次要着手于四个方面建设。

• 第一，批流一体模式在更大范畴的推广应用。例如离线数仓 ETL 的实时化、以及经营流动实时与离线数据的生成。
• 第二，咱们会着力推动 Flink 在 AI 数据流上的利用，心愿通过 Flink 撑持特色、索引、样本的实时、离线解决，提效模型迭代的速度。
• 第三，目前有一些在线数据处理链路曾经应用 Flink 做撑持了，对于 Flink 的稳固的要求也随之回升，咱们还须要在稳定性上做继续改良，例如做单点故障的疾速 failover 等。
• 最初，因为 Flink 也在撑持在线场景，Flink 须要具备作业内主动且平滑地扩容资源，缩容资源能力。所以弹性伸缩也是咱们关注的方向。