Flink面试常见问题（实战）

 

一、如何排查生产环境中的反压问题？

1、反压出现的场景

反压经常出现在促销、热门活动等场景。短时间内流量陡增造成数据的堆积或者消费速度变慢。

它们有一个共同的特点：数据的消费速度小于数据的生产速度。

2、反压监控方法

通过Flink Web UI发现反压问题

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

这个比例展示逻辑如下：

OK: 0 <= Ratio <= 0.10，正常；

LOW: 0.10 < Ratio <= 0.5，一般；

HIGH: 0.5 < Ratio <= 1，严重。

3、flink反压的实现方式

Flink任务的组成由基本的“流”和“算子”构成，“流”中的数据在“算子”间进行计算和转换时，会被放入分布式的阻塞队列中。当消费者的阻塞队列满时，则会降低生产者的数据生产速度

3、反压问题定位和处理

Flink会因为数据堆积和处理速度变慢导致checkpoint超时，而checkpoint是Flink保证数据一致性的关键所在，最终会导致数据的不一致发生。

数据倾斜：可以在 Flink 的后台管理页面看到每个 Task 处理数据的大小。当数据倾斜出现时，通常是简单地使用类似 KeyBy 等分组聚合函数导致的，需要用户将热点 Key 进行预处理，降低或者消除热点 Key 的影

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

代码本身：开发者错误地使用 Flink 算子，没有深入了解算子的实现机制导致性能问题。我们可以通过查看运行机器节点的 CPU 和内存情况定位问题

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

1、flink数据倾斜的表现：

任务节点频繁出现反压，增加并行度也不能解决问题

部分节点出现OOM异常，是因为大量的数据集中在某个节点上，导致该节点内存被爆，任务失败重启

2、数据倾斜产生的原因：

业务上有严重的数据热点，比如滴滴打车的订单数据中北京、上海等几个城市的订单量远远超过其他地区；

技术上大量使用了 KeyBy、GroupBy 等操作，错误的使用了分组 Key，人为产生数据热点。

3、解决问题的思路：

业务上要尽量避免热点 key 的设计，例如我们可以把北京、上海等热点城市分成不同的区域，并进行单独处理；

技术上出现热点时，要调整方案打散原来的 key，避免直接聚合；此外 Flink 还提供了大量的功能可以避免数据倾斜。

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

A、两阶段聚合解决 KeyBy 热点：

• 首先把分组的 key 打散，比如加随机后缀；
• 对打散后的数据进行聚合；
• 把打散的 key 还原为真正的 key；
• 二次 KeyBy 进行结果统计，然后输出。

DataStream sourceStream = ...;
resultStream = sourceStream
     .map(record -> {
        Record record = JSON.parseObject(record, Record.class);
        String type = record.getType();
        record.setType(type + "#" + new Random().nextInt(100));
        return record;
      })
      .keyBy(0)
      .window(TumblingEventTimeWindows.of(Time.minutes(1)))
      .aggregate(new CountAggregate())
      .map(count -> {
        String key = count.getKey.substring(0, count.getKey.indexOf("#"));
        return RecordCount(key,count.getCount);
      })
      //二次聚合
      .keyBy(0)
      .process(new CountProcessFunction);
resultStream.sink()...

env.execute()...

B、GroupBy + Aggregation 分组聚合热点问题:

将SQL 拆成了内外两层，第一层通过随机打散 100 份的方式减少数据热点，当然这个打散的方式可以根据业务灵活指定。

select date,
       type,
       sum(pv) as pv
from(
  select
        date,
        type,
        sum(count) as pv
  from table
        group by
        date,
        type,
        floor(rand()*100) --随机打散成100份 
    )
    group by 
    date,
    type;

C、Flink 消费 Kafka 上下游并行度不一致导致的数据倾斜

Flink 消费 Kafka 的数据时，是推荐上下游并行度保持一致，即 Kafka 的分区数等于 Flink Consumer 的并行度。

但是会有一种情况，为了加快数据的处理速度，来设置 Flink 消费者的并行度大于 Kafka 的分区数。如果你不做任何的设置则会导致部分 Flink Consumer 线程永远消费不到数据。需要设置 Flink 的 Redistributing，也就是数据重分配。

dataStream
        .setParallelism(2)
        // 采用REBALANCE分区策略重分区
        .rebalance() //.rescale()
        .print()
        .setParallelism(4);

• Rebalance 分区策略，数据会以 round-robin 的方式对数据进行再次分区，可以全局负载均衡。
• Rescale 分区策略基于上下游的并行度，会将数据以循环的方式输出到下游的每个实例中

三、flink维度表关联

根据我们业务对维表数据关联的时效性要求，有以下几种解决方案：

1、实时查询维表

实时查询维表是指用户在Flink 的Map算子中直接访问外部数据库，比如用 MySQL 来进行关联，这种方式是同步方式，数据保证是最新的。最后，为了保证连接及时关闭和释放，一定要在最后的 close 方式释放连接，否则会将 MySQL 的连接数打满导致任务失败。

一般我们在查询小数据量的维表情况下才使用这种方式，并且要妥善处理连接外部系统的线程，一般还会用到线程池。

2、预加载全量数据

当我们的系统启动时，就将维度表数据全部加载到内存中，然后数据在内存中进行关联，不需要直接访问外部数据库。一旦维表数据发生更新，Flink 任务是无法感知,可以采取定时拉取维表数据
对计算节点的内存消耗很高，所以不能适用于数量很大的维度表

适用于那些实时场景不是很高，维表数据较小的场景

3、LRU 缓存(最近最少使用的数据则被淘汰)

如果维表的数据比较大，无法一次性全部加载到内存中，可以使用LRU策略加载维表数据。

利用 Flink 的 RichAsyncFunction 读取 Hbase 的数据到缓存中，我们在关联维度表时先去查询缓存，如果缓存中不存在这条数据，就利用客户端去查询 Hbase，然后插入到缓存中

4、将维表消息广播出去

//1：初始化数据
DataSet<Integer> toBroadcast = env.fromElements(1, 2, 3)

//2：广播数据
.withBroadcastSet(toBroadcast, "broadcastSetName");

//3：获取数据
Collection<Integer> broadcastSet = getRuntimeContext().getBroadcastVariable("broadcastSetName");

四、flink海量数据高效去重

①基于状态后端
②基于HyperLogLog：不是精准的去重
③基于布隆过滤器（BloomFilter）
快速判断一个key是否存在于某容器，不存在就直接返回。
④基于BitMap
用一个bit位来标记某个元素对应的Value，而Key即是该元素。由于采用了Bit为单位来存储数据，因此可以大大节省存储空间。
⑤基于外部数据库
选择使用Redis或者HBase存储数据，我们只需要设计好存储的Key即可，不需要关心Flink任务重启造成的状态丢失问题

五、Flink 任务出现很高的延迟，你会如何入手解决类似问题？

在 Flink 的后台任务管理中，可以看到 Flink 的哪个算子和 task 出现了反压；

资源调优和算子调优：资源调优即对作业中的 Operator 并发数（Parallelism）、CPU（Core）、堆内存（Heap_memory）等参数进行调优；

作业参数调优：并行度的设置、State 的设置、Checkpoint 的设置。