Flink------优化

1、Flink 内存优化

1.1Flink 的内存管理

开源的大数据框架基本上大多数都是基于 JVM 运行的，如 Hadoop、Spark、 Storm，但是基于 JVM 的内存管理机制往往存在着类似于内存溢出等问题，主要 是因为创建的对象过多而超过 JVM 的最大堆内存限制，却没有被有效的回收掉， 仅仅靠 JVM 所提供的各种垃圾回收机制很难解决内存溢出等问题。尤其是几十 甚至上百 G 的内存应用时会生成大量对象，Java GC 可能会被反复触发，其中 Full GC 或 Major GC 的开销是非常大的，GC 会达到秒级甚至分钟级。 OOM 问题影响稳定性。OutOfMemoryError 是分布式计算框架经常会遇到的 问题，当 JVM 中所有对象大小超过分配给 JVM 的内存大小时，就会发生 OutOfMemoryError 错误，导致 JVM 崩溃，分布式框架的健壮性和性能都会受到 影响。所以 Flink 自身也实现了自己的内存管理。

1.2Flink 内存配置

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

2 配置进程参数

Flink on YARN 模式下，有 JobManager 和 TaskManager 两种进程。在任务调 度和运行的过程中，JobManager 和 TaskManager 承担了很大的责任。 因而 JobManager 和 TaskManager 的参数配置对 Flink 应用的执行有着很大的 影响意义。用户可通过如下操作对 Flink 集群性能做优化。

3 操作步骤

（1）配置 JobManager 内存 JobManager 负责任务的调度，以及 TaskManager、RM 之间的消息通信。当 任务数变多，任务平行度增大时，JobManager 内存都需要相应增大。您可以根 据实际任务数量的多少，为 JobManager 设置一个合适的内存。 在使用 yarn-session 命令时，添加“-jm MEM”参数设置内存。 在使用 yarn-cluster 命令时，添加“-yjm MEM”参数设置内存。 （2）配置 TaskManager 个数 每个 TaskManager 每个核同时能跑一个 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、解决数据倾斜

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

解决方式：
1、数据源的消费不均匀：调整并发度。 对于数据源消费不均匀，比如 Kafka 数据源，通常是通过调整数据源算子的 并发度实现的。 通常情况下 Source 的并发度和 Kafka 的分区个数一样或者 Kafka 分区个数是 Source 并发度的正整数倍。 2、数据分布不均匀。 （1）通过添加随机前缀打散它们的分布，使得数据不会集中在几个 Task 中。（2）调用分区方法 rebalance、rescale 操作，使数据分布均匀。 （3）自定义分区器。 （4）聚合统计前，先进行预聚合，例如两阶段聚合（加盐局部聚合+去盐全 局聚合）。

4 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 时间较长的情况时，有可能是因为数据对齐需要耗费的时间比 较长所造成的。
设置最小时间间隔。
val env = StreamExecutionEnvironment.getExecutionEnvironment env.getCheckpointConfig.setMinPauseBetweenCheckpoints(1000)
数据压缩状态。
val config = new ExecutionConfig() config.setUseSnapshotCompression(true) Checkpoint 延时启动。
是通过以下公式计算得出的，如果该时间过长，则表 明算子在进行 Barries 对齐，等待上游的算子将数据写入到当前的算子中，说明 数据正在处于一个反压的状态。 checkpoint_start_delay = end_to_end_duration - synchronous_duration - asychronous_duration

5、Flink 作业的问题定位

“一压二查三指标，延迟吞吐是核心。时刻关注资源量 , 排查首先看 GC。” 一压是指背压，遇到问题先看背压的情况，二查就是指 checkpoint ，对齐 数据的时间是否很长，state 是否很大，这些都是和系统吞吐密切相关的，三指 标就是指 Flink UI 那块的一些展示，我们的主要关注点其实就是延迟和吞吐，系 统资源，还有就是 GC logs。
看反压 ：通常最后一个被压高的 subTask 的下游就是 job 的瓶颈之一。 看 Checkpoint 时长 ：Checkpoint 时长能在一定程度影响 job 的整体吞吐。 看核心指标 ：指标是对一个任务性能精准判断的依据，延迟指标和吞吐则 是其中最为关键的指标。 资源的使用率：提高资源的利用率是最终的目的。

6、Flink 代码调优

方案一：
我们可以通过一些数据结构，比如 Set 或者 Map 来结合 Flink state 进行 去重。但是这些去重方案会随着数据量不断增大，从而导致性能的急剧下降，比 如刚刚我们分析过的 hash 冲突带来的写入性能问题，内存过大导致的 GC 问 题，TaskManger 的失联问题。
方案二：
使用布隆过滤器。
布隆过滤器（Bloom Filter）：是采用一种 hash 法进行去重的工具，它将每 一条数据进行 n 次独立的 hash 处理，每次得到一个整数，总共得到 n 个整数， 使用一个很长的数组表示不同的整数，每次插入操作将 n 个整数位置对应的 0 设置为 1（如果已经设置为 1 则不变）。下次查找的时候，经过同样的计算，如 果这几个位置都是 1 则说明已经存在了。
布隆过滤器的优点是使用方便，因为不用将 key 放进内存所以十分节省空 间，多个 hash 算法无关，可以并发执行效率高。缺点是其返回的结果是概率性 的，而不是确切的。我们一般可以通过选择好的 hash 算法和扩大 bitmap 的存储 空间，从而提高准确性。

比如如下代码： 
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);
  	 }
   }