sunny123456

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
大数据技术 Flink 优化之数据倾斜

大数据技术 Flink 优化之数据倾斜

本博客总结为B站尚硅谷大数据Flink2.0调优，Flink性能优化视频的笔记总结。

尚硅谷https://so.csdn.net/so/search?q=%E5%B0%9A%E7%A1%85%E8%B0%B7&spm=1001.2101.3001.7020

大数据Flink2.0调优，Flink性能优化https://www.bilibili.com/video/BV1Q5411f76P

1、 判断是否存在数据倾斜

相同 Task 的多个 Subtask 中，个别 Subtask 接收到的数据量明显大于其他Subtask 接收到的数据量，通过 Flink Web UI 可以精确地看到每个 Subtask 处理了多少数据，即可判断出 Flink 任务是否存在数据倾斜。通常，数据倾斜也会引起反压。

另外，有时 Checkpoint detail 里不同 SubTask 的 State size 也是一个分析数据倾斜的有用指标。

2、 数据倾斜的解决

2.1 keyBy 后的聚合操作存在数据倾斜

提交案例：

  1. bin/flink run \
  2. ​
  3. -t yarn-per-job \
  4. ​
  5. -d \
  6. ​
  7. -p 5 \
  8. ​
  9. -Drest.flamegraph.enabled=true \
  10. ​
  11. -Dyarn.application.queue=test \
  12. ​
  13. -Djobmanager.memory.process.size=1024mb \
  14. ​
  15. -Dtaskmanager.memory.process.size=2048mb \
  16. ​
  17. -Dtaskmanager.numberOfTaskSlots=2 \
  18. ​
  19. -c com.atguigu.flink.tuning.SkewDemo1 \
  20. ​
  21. /opt/module/flink-1.13.1/myjar/flink-tuning-1.0-SNAPSHOT.jar \
  22. ​
  23. --local-keyby false

查看 webui：

1）为什么不能直接用二次聚合来处理

Flink 是实时流处理，如果 keyby 之后的聚合操作存在数据倾斜，且没有开窗口（没攒批）的情况下，简单的认为使用两阶段聚合，是不能解决问题的。因为这个时候 Flink 是来一条处理一条，且向下游发送一条结果，对于原来 keyby 的维度（第二阶段聚合）来讲，数据量并没有减少，且结果重复计算（非 FlinkSQL，未使用回撤流），如下图所示：

2）使用 LocalKeyBy 的思想

在 keyBy 上游算子数据发送之前，首先在上游算子的本地对数据进行聚合后，再发送到下游，使下游接收到的数据量大大减少，从而使得 keyBy 之后的聚合操作不再是任务的瓶颈。类似 MapReduce 中 Combiner 的思想，但是这要求聚合操作必须是多条数据或者一批数据才能聚合，单条数据没有办法通过聚合来减少数据量。从 Flink LocalKeyBy 实现原理来讲，必然会存在一个积攒批次的过程，在上游算子中必须攒够一定的数据量，对这些数据聚合后再发送到下游。

实现方式：

➢ DataStreamAPI 需要自己写代码实现

➢ SQL 可以指定参数，开启 miniBatch 和 LocalGlobal 功能（推荐，后续介绍）

3）DataStream API 自定义实现的案例

以计算每个 mid 出现的次数为例，keyby 之前，使用 flatMap 实现 LocalKeyby 功能

  1. import org.apache.flink.api.common.functions.RichFlatMapFunction;
  2. ​
  3. import org.apache.flink.api.common.state.ListState;
  4. ​
  5. import org.apache.flink.api.common.state.ListStateDescriptor;
  6. ​
  7. import org.apache.flink.api.common.typeinfo.Types;
  8. ​
  9. import org.apache.flink.api.java.tuple.Tuple2;
  10. ​
  11. import org.apache.flink.runtime.state.FunctionInitializationContext;
  12. ​
  13. import org.apache.flink.runtime.state.FunctionSnapshotContext;
  14. ​
  15. import org.apache.flink.streaming.api.checkpoint.CheckpointedFunction; 
  16. ​
  17. import org.apache.flink.util.Collector;
  18. ​
  19. import java.util.HashMap;
  20. ​
  21. import java.util.Map;
  22. ​
  23. import java.util.concurrent.atomic.AtomicInteger;
  24. ​
  25. public class LocalKeyByFlatMapFunc extends RichFlatMapFunction<Tuple2<String, 
  26. ​
  27. Long>, Tuple2<String, Long>> implements CheckpointedFunction {
  28. ​
  29.  //Checkpoint 时为了保证 Exactly Once，将 buffer 中的数据保存到该 ListState 中
  30. ​
  31.  private ListState<Tuple2<String, Long>> listState;
  32. ​
  33.  //本地 buffer，存放 local 端缓存的 mid 的 count 信息
  34. ​
  35.  private HashMap<String, Long> localBuffer;
  36. ​
  37.  //缓存的数据量大小，即：缓存多少数据再向下游发送
  38. ​
  39.  private int batchSize;
  40. ​
  41.  //计数器，获取当前批次接收的数据量
  42. ​
  43.  private AtomicInteger currentSize;
  44. ​
  45.  //构造器，批次大小传参
  46. ​
  47.  public LocalKeyByFlatMapFunc(int batchSize) {
  48. ​
  49.  this.batchSize = batchSize;
  50. ​
  51.  }
  52. ​
  53.  @Override
  54. ​
  55.  public void flatMap(Tuple2<String, Long> value, Collector<Tuple2<String, Long>> 
  56. ​
  57. out) throws Exception {
  58. ​
  59.  // 1、将新来的数据添加到 buffer 中
  60. ​
  61.  Long count = localBuffer.getOrDefault(value, 0L);
  62. ​
  63.  localBuffer.put(value.f0, count + 1);
  64. ​
  65.  // 2、如果到达设定的批次，则将 buffer 中的数据发送到下游
  66. ​
  67.  if (currentSize.incrementAndGet() >= batchSize) {
  68. ​
  69.  // 2.1 遍历 Buffer 中数据，发送到下游
  70. ​
  71.  for (Map.Entry<String, Long> midAndCount : localBuffer.entrySet()) {
  72. ​
  73.  out.collect(Tuple2.of(midAndCount.getKey(), 
  74. ​
  75. midAndCount.getValue())); 
  76. ​
  77.  }
  78. ​
  79.  // 2.2 Buffer 清空，计数器清零
  80. ​
  81.  localBuffer.clear();
  82. ​
  83.  currentSize.set(0);
  84. ​
  85.  }
  86. ​
  87.  }
  88. ​
  89.  @Override
  90. ​
  91.  public void snapshotState(FunctionSnapshotContext context) throws Exception {
  92. ​
  93.  // 将 buffer 中的数据保存到状态中，来保证 Exactly Once
  94. ​
  95.  listState.clear();
  96. ​
  97.  for (Map.Entry<String, Long> midAndCount : localBuffer.entrySet()) {
  98. ​
  99.  listState.add(Tuple2.of(midAndCount.getKey(), midAndCount.getValue()));
  100. ​
  101.  }
  102. ​
  103.  }
  104. ​
  105.  @Override
  106. ​
  107.  public void initializeState(FunctionInitializationContext context) throws Exception {
  108. ​
  109.  // 从状态中恢复 buffer 中的数据
  110. ​
  111.  listState = context.getOperatorStateStore().getListState(
  112. ​
  113.  new ListStateDescriptor<Tuple2<String, Long>>(
  114. ​
  115.  "localBufferState",
  116. ​
  117.  Types.TUPLE(Types.STRING, Types.LONG)
  118. ​
  119.  )
  120. ​
  121.  );
  122. ​
  123.  localBuffer = new HashMap();
  124. ​
  125.  if (context.isRestored()) {
  126. ​
  127.  // 从状态中恢复数据到 buffer 中
  128. ​
  129.  for (Tuple2<String, Long> midAndCount : listState.get()) {
  130. ​
  131.  // 如果出现 pv != 0,说明改变了并行度，ListState 中的数据会被均匀分发到
  132. ​
  133. 新的 subtask 中
  134. ​
  135.  // 单个 subtask 恢复的状态中可能包含多个相同的 mid 的 count 数据
  136. ​
  137.  // 所以每次先取一下 buffer 的值，累加再 put
  138. ​
  139.  long count = localBuffer.getOrDefault(midAndCount.f0, 0L);
  140. ​
  141.  localBuffer.put(midAndCount.f0, count + midAndCount.f1);
  142. ​
  143.  }
  144. ​
  145.  // 从状态恢复时，默认认为 buffer 中数据量达到了 batchSize，需要向下游发
  146. ​
  147.  currentSize = new AtomicInteger(batchSize); 
  148. ​
  149.  } else {
  150. ​
  151.  currentSize = new AtomicInteger(0);
  152. ​
  153.  }
  154. ​
  155.  }
  156. ​
  157. }

提交 localkeyby 案例：

  1. bin/flink run \
  2. ​
  3. -t yarn-per-job \
  4. ​
  5. -d \
  6. ​
  7. -p 5 \
  8. ​
  9. -Drest.flamegraph.enabled=true \
  10. ​
  11. -Dyarn.application.queue=test \
  12. ​
  13. -Djobmanager.memory.process.size=1024mb \
  14. ​
  15. -Dtaskmanager.memory.process.size=2048mb \
  16. ​
  17. -Dtaskmanager.numberOfTaskSlots=2 \
  18. ​
  19. -c com.atguigu.flink.tuning.SkewDemo1 \
  20. ​
  21. /opt/module/flink-1.13.1/myjar/flink-tuning-1.0-SNAPSHOT.jar \
  22. ​
  23. --local-keyby true

查看 webui：

可以看到每个 subtask 处理的数据量基本均衡，另外处理的数据量相比原先少了很多。

2.2 keyBy 之前发生数据倾斜

如果 keyBy 之前就存在数据倾斜，上游算子的某些实例可能处理的数据较多，某些实例可能处理的数据较少，产生该情况可能是因为数据源的数据本身就不均匀，例如由于某些原因 Kafka 的 topic 中某些 partition 的数据量较大，某些 partition 的数据量较少。对于不存在 keyBy 的 Flink 任务也会出现该情况。

这种情况，需要让 Flink 任务强制进行 shuffle。使用 shuffle、rebalance 或 rescale算子即可将数据均匀分配，从而解决数据倾斜的问题。

2.3 keyBy 后的窗口聚合操作存在数据倾斜

因为使用了窗口，变成了有界数据（攒批）的处理，窗口默认是触发时才会输出一条结果发往下游，所以可以使用两阶段聚合的方式：

1）实现思路：

➢ 第一阶段聚合：key 拼接随机数前缀或后缀，进行 keyby、开窗、聚合

注意：聚合完不再是 WindowedStream，要获取 WindowEnd 作为窗口标记作为第二阶段分组依据，避免不同窗口的结果聚合到一起）

➢ 第二阶段聚合：按照原来的 key 及 windowEnd 作 keyby、聚合

2）提交原始案例

  1. bin/flink run \
  2. ​
  3. -t yarn-per-job \
  4. ​
  5. -d \
  6. ​
  7. -p 5 \
  8. ​
  9. -Drest.flamegraph.enabled=true \
  10. ​
  11. -Dyarn.application.queue=test \
  12. ​
  13. -Djobmanager.memory.process.size=1024mb \
  14. ​
  15. -Dtaskmanager.memory.process.size=2048mb \
  16. ​
  17. -Dtaskmanager.numberOfTaskSlots=2 \
  18. ​
  19. -c com.atguigu.flink.tuning.SkewDemo2 \
  20. ​
  21. /opt/module/flink-1.13.1/myjar/flink-tuning-1.0-SNAPSHOT.jar \
  22. ​
  23. --two-phase false

查看 WebUI：

3）提交两阶段聚合的案例

  1. bin/flink run \
  2. ​
  3. -t yarn-per-job \
  4. ​
  5. -d \
  6. ​
  7. -p 5 \
  8. ​
  9. -Drest.flamegraph.enabled=true \
  10. ​
  11. -Dyarn.application.queue=test \
  12. ​
  13. -Djobmanager.memory.process.size=1024mb \
  14. ​
  15. -Dtaskmanager.memory.process.size=2048mb \
  16. ​
  17. -Dtaskmanager.numberOfTaskSlots=2 \
  18. ​
  19. -c com.atguigu.flink.tuning.SkewDemo2 \
  20. ​
  21. /opt/module/flink-1.13.1/myjar/flink-tuning-1.0-SNAPSHOT.jar \
  22. ​
  23. --two-phase true \
  24. ​
  25. --random-num 16

查看 WebUI：可以看到第一次打散的窗口聚合，比较均匀

第二次聚合，也比较均匀：

随机数范围，需要自己去测，因为 keyby 的分区器是（两次 hash*下游并行度/最大并行度）

SQL 写法参考：https://zhuanlan.zhihu.com/p/197299746

原文链接:https://blog.csdn.net/m0_57376564/article/details/147871621
posted on 2025-05-21 11:15  sunny123456  阅读(54)  评论(0)    收藏  举报