Flink优化

 

一、Flink内存优化

1.1 Flink 内存配置

        Flink JVM 进程的进程总内存（Total Process Memory）包含了由 Flink 应用使用的内存（Flink 总内存）以及由运行 Flink 的 JVM 使用的内存。 Flink 总内存（Total Flink Memory）包括 JVM 堆内存（Heap Memory）和堆外内存（Off-Heap Memory）。 其中堆外内存包括直接内存（Direct Memory）和本地内存（Native Memory）。

TaskManager的内存划分

 

JobManager 的内存划分

 二、配置进程参数

2.1 场景

        Flink on Yarn 模式下，有 JobManager 和 TaskManager 两种进程。在任务调度和运行的过程中，JobManager 和 TaskManager 承担了很大的责任。

        因此，JobManager 和 TaskManager 的参数配置对 Flink 应用的执行有着很大的影响意义。用户可以通过如下操作对 Flink 集群性能做优化。

2.2 操作步骤

1. 配置 JobManager 内存

        JobManager 负责任务的调度，以及 TaskManager、RM之间的消息通信。当任务数变多，任务平行度增大时，JobManager 内存都需要相应增大。可以根据实际任务数，为 JobManager 设置一个合理的内存大小。

• 在使用 yarn-session 命令时，添加“-jm MEM”参数设置内存  
• 在使用 yarn-cluster 命令时，添加“-yjm MEM”参数设置内存      

2. 配置 TaskManager个数

        每个 TaskManager 每个核同时能跑1个 task，所以增加了 TaskManager 的个数相当于增大课任务的并发度。在资源充足的情况下，可以相应的增加 TaskManager 的个数，以提高运行效率。

• 在使用 yarn-session 命令时，添加“-n NUM”参数设置 TaskManager 个数
• 在使用 yarn-cluster 命令时，添加“-yn NUM”参数设置 TaskManager 个数

3. 配置 TaskManager Slot 个数

        每个 TaskManager 多个核同时能跑多个 task，相当于增大了任务的并发度。但是由于所有核共用 TaskManager 的内存，所以要在内存和核数之间做好平衡。

• 在使用 yarn-session 命令时，添加“-s NUM”参数设置 SLOT 数
• 在使用 yarn-cluster 命令时，添加“-ys NUM”参数设置 SLOT 数

4. 配置 TaskManager 内存

        TaskManager 的内存主要用于任务执行、通信等。当一个任务很大的时候， 可能需要较多资源，因而内存也可以做相应的增加。

• 将在使用 yarn-sesion 命令时，添加“-tm MEM”参数设置内存
• 将在使用 yarn-cluster 命令时，添加“-ytm MEM”参数设置内存

三、解决数据倾斜

3.1 场景描述

数据倾斜：由于数据分布不均匀，数据集中在某些 SubTask 上，导致部分 SubTask 处理数据量特别大，执行时间过长，影响了整个应用程序的执行效率。 过多的数据集中在某些 JVM（TaskManager），使得 JVM 的内存资源短缺，导 致频繁 GC。严重情况下，过长的 GC 导致 TaskManager 失联，系统崩溃。

 3.2 解决方式

3.2.1. 数据源的消费不均匀：调整并发度

        对于数据源消费不均匀，比如 Kafka 数据源，通常是通过调整数据源算子的 并发度实现的。 通常情况下 Source 的并发度和 Kafka 的分区个数一样或者 Kafka 分区个数是 Source 并发度的正整数倍。

3.2.2. 数据分布不均匀

• 通过添加随机前缀打散它们的分布，使得数据不会集中在几个 Task 中
• 调用分区方法 rebalance、rescale 操作，使数据分布均匀
• 自定义分区器
• 聚合统计前，先进行预聚合，例如两阶段聚合（加盐局部聚合+去盐全 局聚合）

四、Checkpoint 优化

        每一个 Flink 作业都会有一个 JobManager ，JobManager 里面又会有一个 CheckpointCoordinator 来管理整个 checkpoint 的过程，我们可以设置一个时间间隔让 CheckpointCoordinator 将一个 Checkpoint 的事件发送给每一个 Container 中的 Source Task，也就是第一个任务。

         当某个 Source 算子收到一个 Barrier 时，它会暂停自身的数据处理，然后 将自己的当前 State 制作成 Snapshot（快照），并保存到指定的持久化存储中， 最后向 CheckpointCoordinator 异步发送一个 ack（Acknowledge character --- 确 认字符），同时向自身所有下游算子广播该 Barrier 后恢复自身的数据处理。

        每个算子按照上面不断制作 Snapshot 并向下游广播，直到最后 Barrier 传 递到 Sink 算子，此时快照便制作完成。这时候需要注意的是，上游算子可能是 多个数据源，对应多个 Barrier 需要全部到齐才一次性触发 Checkpoint，所以在 遇到 Checkpoint 时间较长的情况时，有可能是因为数据对齐需要耗费的时间比 较长所造成的。

• 设置最小时间间隔

1.  
   val env = StreamExecutionEnvironment.getExecutionEnvironment
2.  
   env.getCheckpointConfig.setMinPauseBetweenCheckpoints(1000)

• 数据压缩状态

1.  
   val config = new ExecutionConfig()
2.  
   config.setUseSnapshotCompression(true)

• Checkpoint 延时启动

        是通过以下公式计算得出的，如果该时间过长，则表 明算子在进行 Barries 对齐，等待上游的算子将数据写入到当前的算子中，说明 数据正在处于一个反压的状态。

checkpoint_start_delay = end_to_end_duration - synchronous_duration - asychronous_duration

五、Flink 作业的问题定位

“一压二查三指标，延迟吞吐是核心。时刻关注资源量 , 排查首先看 GC。”

        一压是指背压，遇到问题先看背压的情况，二查就是指 checkpoint ，对齐数据的时间是否很长，state 是否很大，这些都是和系统吞吐密切相关的，三指 标就是指 Flink UI 那块的一些展示，我们的主要关注点其实就是延迟和吞吐，系 统资源，还有就是 GC logs。

• 看反压 ：通常最后一个被压高的 subTask 的下游就是 job 的瓶颈之一
• 看 Checkpoint 时长 ：Checkpoint 时长能在一定程度影响 job 的整体吞吐
• 看核心指标 ：指标是对一个任务性能精准判断的依据，延迟指标和吞吐则 是其中最为关键的指标
• 资源的使用率：提高资源的利用率是最终的目的

六、Flink常见性能问题

• 在关注背压的时候大家往往忽略了数据的序列化和反序列化，过程所 造成的性能问题。
• 一些数据结构 ，比如 HashMap 和 HashSet 这种 key 需要经过 hash 计算的数据结构，在数据量大的时候使用 keyBy 进行操作， 造成的性能影响是 非常大的。
• 数据倾斜问题，由于数据分布不均匀，数据集中在某些 SubTask 上，导致部分 SubTask 处理数据量特别大，执行时间过长，影响了整个应用程序的执行效率。。
• 如果我们的下游是 MySQL，HBase 这种，我们都会进行一个批处理的 操作，就是让数据存储到一个 Buffer 里面，在达到某些条件的时候再进行发送， 这样做的目的就是减少和外部系统的交互，降低 网络开销 的成本。
• 频繁 GC ，无论是 CMS 也好，G1 也好，在进行 GC 的时候，都会停 止整个作业的运行，GC 时间较长还会导致 JobManager 和 TaskManager 没有办 法准时发送心跳，此时 JobManager 就会认为此 TaskManager 失联，它就会另 外开启一个新的 TaskManager。 
• 窗口是一种可以把无限数据切割为有限数据块的手段。比如我们知道， 使用滑动窗口的时候数据的重叠问题，size = 5min 虽然不属于大窗口的范畴，可 是 step = 1s 代表 1 秒就要进行一次数据的处理，这样就会造成数据的重叠很高，数据量很大的问题。

七、Flink 代码调优

7.1 数据去重

 方案一：

我们可以通过一些数据结构，比如 Set 或者 Map 来结合 Flink state 进行 去重。但是这些去重方案会随着数据量不断增大，从而导致性能的急剧下降，比 如刚刚我们分析过的 hash 冲突带来的写入性能问题，内存过大导致的 GC 问 题，TaskManger 的失联问题。

方案二：

使用布隆过滤器。

        布隆过滤器（Bloom Filter）：是采用一种 hash 法进行去重的工具，它将每 一条数据进行 n 次独立的 hash 处理，每次得到一个整数，总共得到 n 个整数， 使用一个很长的数组表示不同的整数，每次插入操作将 n 个整数位置对应的 0 设置为 1（如果已经设置为 1 则不变）。下次查找的时候，经过同样的计算，如 果这几个位置都是 1 则说明已经存在了。

        布隆过滤器的优点是使用方便，因为不用将 key 放进内存所以十分节省空 间，多个 hash 算法无关，可以并发执行效率高。缺点是其返回的结果是概率性的，而不是确切的。我们一般可以通过选择好的 hash 算法和扩大 bitmap 的存储 空间，从而提高准确性。

7.2 代码中复用对象

stream

.apply(new WindowFunction<WikipediaEditEvent, Tuple2<String, Long>, String, TimeWi

ndow>() {

@Override

public void apply(String userName, TimeWindow timeWindow, Iterable<WikipediaEdi

tEvent> iterable, Collector<Tuple2<String, Long>> collector) throws Exception {

long changesCount = ...

// A new Tuple instance is created on every execution

collector.collect(new Tuple2<>(userName, changesCount));

}

}

 

从上面的代码可以看出，apply 函数每执行一次，都会新建一个 Tuple2 类的实例，因此增 加了对垃圾收集器的压力。解决这个问题的一种方法是反复使用相同的实例：

stream

.apply(new WindowFunction<WikipediaEditEvent, Tuple2<String, Long>, String, TimeWindow>() {

// Create an instance that we will reuse on every call

private Tuple2<String, Long> result = new Tuple<>();

@Override

public void apply(String userName, TimeWindow timeWindow, Iterable<WikipediaEditEvent> iterable, Collector<Tuple2<String, Long>> collector) throws

Exception {

long changesCount = ...

// Set fields on an existing object instead of creating a new one

result.f0 = userName;

// Auto-boxing!! A new Long value may be created

result.f1 = changesCount;

// Reuse the same Tuple2 object

collector.collect(result);

}

}