当前位置:   article > 正文

100%会被问到的两道Flink面试题,你会了么?_flink反压和背压 面试

flink反压和背压 面试

目录

一 . 你在开发Flink任务时,有没有遇到过背压问题,你是如何排查的?

二. 如何处理生产环境中的数据倾斜问题?

往期精选▼

转载是一种动力 分享是一种美德, 欢迎关注 大数据与数据仓库公众号, 回复 spark 领取资料


一 . 你在开发Flink任务时,有没有遇到过背压问题,你是如何排查的?

1. 背压产生的原因

背压常常出现在大促或者一些热门活动等场景中, 在上面这类场景中, 短时间内流量陡增导致数据的堆积,系统整体的吞吐量无法提升。

2. 监控背压方法

可以通过 Flink Web UI 发现背压问题

Flink 的 TaskManager 会每隔 50 ms 触发一次反压状态监测,共监测 100 次,并将计算结果反馈给 JobManager,最后由 JobManager 进行计算反压的比例,然后进行展示。

这个比例的计算逻辑如下:

背压程度指标范围备注
HIGH0.5 < Ratio <= 1严重
LOW0.10 < Ratio <= 0.5一般
OK0 <= Ratio <= 0.10正常

3. 反压问题的定位与处理

Flink出现背压一般可以从下面三个方面进行问题定位

a. 数据倾斜

可以在 Flink 的后台管理页面看到每个 Task 处理数据的大小。当出现数据倾斜时,可以从页面上明显的看到一个或者多个节点处理的数据量远大于其他节点。这种情况一般是在使用KeyBy等分组聚合算子时,没有考虑到可能出现的热点Key。这种情况需要用户对导致倾斜的热点Key做预处理。

b. 垃圾回收机制(GC)

不合理的设置 TaskManager 的垃圾回收参数会导致严重的 GC 问题,可以通过 -XX:+PrintGCDetails 指令查看 GC 的日志。

c. 代码本身

用户因为未深入了解算子的实现机制而错误地使用了 Flink 算子,导致性能问题。我们可以通过查看运行机器节点的 CPU 和内存情况定位问题

二. 如何处理生产环境中的数据倾斜问题?

1. 产生数据倾斜的原因主要有 2 个方面

业务上有严重的数据热点,比如一个房产网站的浏览数据中北京上海等几个一线城市二手房浏览量远远超过其他地区。 技术上如果大量使用了 KeyBy、GroupBy 等操作,且没有对分组的Key做特殊的处理,会产生数据热点问题。

2. 解决问题的思路

业务上要尽量避免热点 key 的设计,例如我们可以把上海、北京等热点城市与非热点城市划分成不同的区域,并进行单独处理; 技术上出现热点时,要调整方案打散原来的 key,避免直接聚合;此外还可以利用Flink提供的功能来避免数据倾斜。

3. Flink 任务数据倾斜场景和解决方案

(1) 两阶段聚合解决 KeyBy 热点

a. 将需要分组的 key 打散,例如添加随机的后缀

b. 对打散后的数据进行聚合

c. 将被打散的 key 还原为原始的 key

d. 二次 KeyBy 来统计最终结果并输出给下游

具体代码如下所示:

  1. DataStream sourceStream = ...;
  2. resultStream = sourceStream
  3. .map(record -> {
  4. Record record = JSON.parseObject(record, Record.class);
  5. String type = record.getType();
  6. record.setType(type + "_" + new Random().nextInt(100));
  7. return record;
  8. })
  9. // 首次聚合
  10. .keyBy(0)
  11. .window(TumblingEventTimeWindows.of(Time.minutes(5)))
  12. .aggregate(new CountAggregate())
  13. .map(count -> {
  14. String key = count.getKey.substring(0, count.getKey.indexOf("_"));
  15. return RecordCount(key,count.getCount);
  16. })
  17. //进行二次聚合
  18. .keyBy(0)
  19. .process(new CountProcessFunction);
  20. resultStream.sink(...)
  21. env.execute(...)

(2)GroupBy + Aggregation 分组聚合热点问题

如果是采用FlinkSQL的方式,则可以将FlinkSQL 嵌套成两层,里层通过随机打散 若干份(如100)的方式降低数据热点,(这个打散的方式可以根据业务灵活指定)。

  1. select date,
  2. city_id,
  3. sum(pv) as pv
  4. from(
  5. select
  6. date,
  7. city_id,
  8. floor(rand() * 100),
  9. sum(count) as pv
  10. from kafka_table
  11. group by
  12. date,
  13. city_id,
  14. floor(rand() * 100) --随机打散为100
  15. )
  16. group by
  17. date,
  18. city_id;

(3)Flink 消费 Kafka 使用并行度与Kafka分区数不一致导致的数据倾斜

Flink 消费 Kafka 的数据时,是推荐消费并行度为Kafka分区数的1倍或者整数倍的 ,即 Flink Consumer 的并行度 = Kafka 的分区数 * n (n = 1, 2 ,3 ...)。

 

往期精选▼

Spark性能调优之在实际项目中广播大变量

Spark Shuffle调优之调节map端内存缓冲与reduce端内存占比

Spark Shuffle调优之合并map端输出文件

Flink调优法则

5个Hadoop优化技巧

4个角度轻松理解 Flink中的Watermark

Flink中Checkpoint和Savepoint 的 3 个不同点

Flink实现固定时长或消息条数的触发器

Flink方案设计中的4大误区

使用 Broadcast State 的 4 个注意事项

3种Flink State Backend | 你该用哪个?

一文搞定 Flink 异步 I/O

Flink State 使用的4点建议

Flink在开发中的7点建议

 

转载是一种动力 分享是一种美德, 欢迎关注 大数据与数据仓库公众号, 回复 spark 领取资料

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/喵喵爱编程/article/detail/811469
推荐阅读
相关标签
  

闽ICP备14008679号