关于node.js:快手基于-Flink-的持续优化与实践

4次阅读

共计 3744 个字符，预计需要花费 10 分钟才能阅读完成。

简介：快手基于 Flink 的继续优化与实际的介绍。

第一局部是 Flink 稳定性的继续优化。该局部包含两个方面，第一个方面，次要介绍快手在 Flink Kafka Connector 方面做的一些高可用，是基于外部的双机房读或双机房写和一些容错的策略。第二局部对于 Flink 工作的故障复原。咱们在减速故障复原方面做了一些优化工作。

首先，介绍 Source 方面的高可用。在公司外部比拟重要的数据写 Kafka 时，Kafka 层面为保障高可用个别都会创立双集群的 topic。双集群的 topic 独特承当全副流量，如果单集群产生故障，上游主动分流。Kafka 层面通过这种形式做到双集群的高可用。然而 Flink 工作在生产双集群 topic 时，自身是不能做到高可用的。Flink 工作通过两个 Source union 形式生产，Source 别离感知上游 topic 故障，单集群故障需手动将故障 Source 摘除。这种形式的毛病是故障时须要人工的干涉，必须手动去批改代码的逻辑，程序外部自身是不能做到高可用的。这是做双机房读的背景。

为了解决上述问题，咱们封装了一个 Kafka 的 Cluster Source，它在 API 上反对读取双集群的 topic。同时做到，能够容忍单集群故障，集群故障复原时也能够主动将故障集群重新加入。

接下来是对于 Sink 方面的高可用。Flink 写双集群 Kafka topic，会定义不同集群 Sink，逻辑内管制拆流。这种形式灵活性差，且不能容忍单机房故障。如果单集群产生故障，仍须要手动摘除对应的 Sink。

同样，针对 sink 咱们也定制了一个 Cluster Sink，它 API 上反对写双集群 topic。具体写的策略，能够反对轮询和主从写的形式。如果单集群产生故障，逻辑内会主动将流量切到失常集群 topic。如果单集群故障复原之后，也能感知到集群的复原，能够主动的再把相应集群复原回来。

另外，基于 Kafka 的 connector，咱们也做了一些容错的策略，这里提到三点。

第一点就是 Kafka Sink 容忍失落。该问题的背景是，如果 Kafka 服务异样引发工作失败，并且业务能够容忍大量数据失落，然而不冀望工作挂掉的状况。针对该问题，咱们的优化是，设置 Kafka Sink 容忍 M 工夫内 X% 失落。具体实现上，Sink 单 task 统计失败频率，失败频率超过阈值工作才失败。
第二点是 Kafka Source 一键丢 lag。该问题背景是, 一旦工作 lag 较长时间，未及时发现，或者工作 debug 环节，须要丢掉历史验证。之前只能靠重启工作来抛弃 lag，工作重启代码比拟好，耗时长。咱们优化后，能够热更新、无需重启工作即能够抛弃 lag。实现逻辑是动静发操作命令给 source，source 收到命令后 seek 到最新地位。
第三点是 Kafka broker 列表动静获取。该问题背景是，生产环境中 Kafka broker 机器可能会故障下线，一旦申请到下线机器，会产生获取 metadata 超时，工作频繁失败。咱们优化后，Source task 启动，能够获取集群信息，动静从新获取 Kafka brokerlist，防止频繁重启。

第二局部是 Flink 工作的故障复原优化，分为两个过程。一个是故障发现，另外一个是故障复原。理论的生产环境中，一些不稳固的因素会导致故障复原的工夫特地的长，用户的感知会比拟差。同时，外部也有一些比拟高优的工作，它对稳定性的要求比拟高。咱们心愿做一些事件，把整个故障复原的工夫尽可能缩短。咱们定了一个优化指标，20 秒内做到一个主动的复原。

在故障发现阶段的优化包含三点：

第一，外部自研 Hawk 零碎，5s 发现宕机。
第二，Yarn 整合 Hawk，疾速感知宕机。
第三，Flink 感知宕机 container release。

在故障复原阶段的优化包含：

第一，容许冗余局部 Container。
第二，适当调整 cancel task timeout 工夫。
第三，针对适宜工作开启 Region Failover。

第二局部是工作启动优化，Flink 工作启动的时候，个别会波及到比拟多的角色，还有多个实例。如下图所示，它的启动在客户端包含，初始化 Client，构建 jobGraph，上传 Flink lib、job jar，申请 AM。在 Job Master，AM 启动后、初始化，构建 ExectutionGraph，申请、启动 Container，Job Task 调度。在 Task Manager 端，容器申请到之后，启动下载 jar 包资源，再去初始化 Task Manager 服务，而后收到 task 后才会去做部署。咱们发现，线上启动一个工作的时候，基本上在分钟级别，耗时比拟长。如果有一些工作须要降级，比如说，改了一些简略的逻辑，须要将原来的工作停掉，而后再去重新启动一个新的工作，这种场景可能就会更慢。因而，我在工作启动的时候做一些优化，尽可能缩短工作启动的工夫，业务的断流工夫也进一步缩短。

在 Flink 新工作启动优化方面，咱们发现 IO 交互会比拟耗时。在客户端的 IO 包含，Flink 引擎 lib 包上传 HDFS，用户上传 jar 包上传 HDFS。在 JobMaster 包含，Container 下载启动资源，TaskManager conf 上传 HDFS。在 TaskManager 包含，Container 下载启动资源，Conf 文件下载。

因而，想尽量的缩小这样的一些 lO 的操作。针对 Flink 引擎 lib 包，设置 Public 权限，App 之间共享。对于用户 jar 包，提供工具，提前预公布到集群机器。对于 Conf 文件，通过环境变量传递。针对 JobMaster 启动 TM 频繁文件判断，减少 cache 缓存。

以上是针对一个新工作启动场景，上面介绍工作降级的场景。以前是同步降级，比如说，工作 A 在运行着，而后我要把工作 A 停掉，再去启动新的工作 B。如下图所示，不可用工夫包含停工作 A 和启动新工作 B。是否能够不必等工作 A 齐全停掉之后，再启动工作 B。针对这个想法咱们做了一个异步降级的策略。新工作提前启动，初始化到 JobMaster 阶段。旧工作停掉后，实现新工作后续启动工作，这样新旧工作无缝切换。通过外部提交平台将该步骤串联起来，指标是异步降级在 20s 以内实现。

第三局部会介绍一下咱们在应用 Flink SQL 的一些实际和优化。首先介绍一下 Flink SQL 在快手的现状。目前，咱们外部 Flink SQL 的工作占比在 30% 左右。Flink SQL 的工作个数是 360 多个。而后它的峰值解决的条目数还是比拟高的，大概是 4 亿每秒。在咱们外部的一些重要流动的实时大屏的场景下，目前 Flink SQL 也作为一条链路，参加了相干指标的计算。

接下来介绍一下咱们在应用 Flink SQL 的时候遇到的一些问题，以及咱们做的一些优化。首先，对于 Flink SQL 的歪斜问题，在 UnBounded Agg 场景下的歪斜问题，曾经有比拟全面的思路去解决，总结为三点。

第一，MiniBatch Aggregation，思路是内存缓存 batch 数据再进行聚合，缩小状态拜访次数。
第二，Local Global Aggregation，思路是聚合操作拆分为两阶段，Local 阶段预聚合缩小数据条数，Global 解决全局聚合。
第三，Split Distinct Aggregation，思路是针对 count distinct 场景，对分组 key 先分桶预聚合，再对分桶后果全局聚合。

所以咱们解决的第一个问题就是 Bounded Agg 的歪斜问题。如下图所示，拿右边的 SQL 作为例子，group by 一个 user，假设一天的窗口，而后去 select 每一个用户总的交易额。左边的图，假设有一些用户的交易特地多，就会造成某一些 Window Agg 的数据量特地大。

解决思路分为两点。

第一，两阶段聚合，分为 Local window Agg 和 Global window Agg。Local window Agg：预聚合 window 大小与 global 阶段保持一致，checkpoint 时将后果写出，不保留状态。Global window Agg：全量聚合。
第二，减少 mini-batch，益处是 local 阶段 mini-batch 防止数据量缓存过多，Global 阶段 mini-batch 缩小状态拜访次数。

咱们解决的第二个问题是 Flink SQL 下的 UDF 函数复用的问题。如下图所示，以右边的 SQL 为例，能够看到有两个 UDF 的函数，这两个函数在 SQL 外面都反复呈现了屡次。