Flink 反压问题

一、反压有哪些危害?

  1. 任务处理性能出现瓶颈:以消费 Kafka 为例,大概率会出现消费 Kafka Lag。

  2. Checkpoint 时间长或者失败:因为某些反压会导致 barrier 需要花很长时间才能对齐,任务稳定性差。

  3. 整个任务完全卡住。比如在 TUMBLE 窗口算子的任务中,反压后可能会导致下游算子的 input pool 和上游算子的 output pool 满了,这时候如果下游窗口的 watermark 一直对不齐,窗口触发不了计算的话,下游算子就永远无法触发窗口计算了。整个任务卡住。

二、经常碰到哪些问题会导致任务反压?

总结就是:算子的 sub-task 需要处理的数据量 > 能够处理的数据量。一般会实际中会有以下两种问题会导致反压。

  1. 数据倾斜:当前算子的每个 sub-task 只能处理 1w qps 的数据,而由于数据倾斜,这个算子的其中一些 sub-task 平均算下来 1s 需要处理 2w 条数据,但是实际只能处理 1w 条,从而反压。比如有时候 keyby 的 key 设置的不合理。

  2. 算子性能问题:下游整个整个算子 sub-task 的处理性能差,输入是 1w qps,当前算子的 sub-task 算下来平均只能处理 1k qps,因此就有反压的情况。比如算子需要访问外部接口,访问外部接口耗时长。

三、如何快速判断哪个算子存在反压

生产环境中,如何快速判断哪个算子存在反压呢?或者说哪个算子出现了性能问题呢?

将这个问题拆解成多步来分析:

  1. 如何知道算子是否有反压?

在 Flink web ui 中,定位到一个具体的算子之后,查看 BackPressure 模块,通过颜色和数值来判断任务的繁忙和反压情况。

若颜色为红色,表示当前算子繁忙,有反压的情况若颜色为绿色,标识当前算子不繁忙,没有反压。

 

     2.举个实际 Flink 任务案例,这个 Flink 任务中有 Source、FlatMap、Sink 算子,如果 Source 算子有反压,那到底是哪个算子有性能问题呢?

上游算子在 web ui 显示有反压时,一般为下游算子存在性能问题。可以继续往下游排查,如果 FlatMap 也显示有反压,大概率是 Sink 算子存在性能问题;如果 FlatMap 没有显示有反压,大概率是 FlatMap 算子存在性能问题。

    3. 大多数时候,Flink 会自动将算子 chain 在一起,那怎么判断具体是哪一个算子有问题?

        第一种方式:Flink 提供了断开算子链的能力

  • DataStream API 中:可以使用 disableChaining() 将 chain 在一起的算子链断开。或者配置 pipeline.operator-chaining: false

.process(xxx)
.uid("process")
.disableChaining() // 将算子链进行断开
.addSink(xxx)
.uid("sink");
  • SQL API 中:配置 pipeline.operator-chaining: false

CREATE TABLE source_table (
    order_number BIGINT,
    price        DECIMAL(32,2)
) WITH (
  'connector' = 'datagen',
  'rows-per-second' = '10',
  'fields.order_number.min' = '10',
  'fields.order_number.max' = '11'
);

CREATE TABLE sink_table (
    order_number BIGINT,
    price        DECIMAL(32,2)
) WITH (
  'connector' = 'print'
);

insert into sink_table
select * from source_table
where order_number = 10;

我们来看看一个 SQL 任务在配置 pipeline.operator-chaining: false 前后的差异。

在配置 pipeline.operator-chaining: false 前,可以看到所有算子都 chain 在一起

 在配置 pipeline.operator-chaining: false 后,可以看到所有算子都没有 chain 在一起

 第二种方式:在 Flink 1.13 中,提供了火焰图,可以通过火焰图定位问题。

火焰图需要配置 rest.flamegraph.enabled: true 打开

 四、怎么缓解、解决任务反压的情况?

  1.  事前:解决上述介绍到的 数据倾斜算子性能 问题。

  2. 事中:在出现反压时:

  • 限制数据源的消费数据速度。比如在事件时间窗口的应用中,可以自己设置在数据源处加一些限流措施,让每个数据源都能够够匀速消费数据,避免出现有的 Source 快,有的 Source 慢,导致窗口 input pool 打满,watermark 对不齐导致任务卡住。

  • 关闭 Checkpoint。关闭 Checkpoint 可以将 barrier 对齐这一步省略掉,促使任务能够快速回溯数据。我们可以在数据回溯完成之后,再将 Checkpoint 打开。

Flink中,反压(Backpressure)是指当数据生产速度超过数据消费速度时,消费端不能及时处理全部数据,导致未处理的数据在系统中积压,从而影响系统的性能和稳定性。如果Flink应用程序中存在反压问题,可以通过以下几个步骤来进行排查和解决: 1. 监控Flink任务的运行状态。可以通过Flink的Web界面或者JMX监控工具来查看任务的运行状态、吞吐量、延迟等指标,从而了解是否存在反压问题。 2. 调整Flink任务的并行度。如果任务的并行度过低,可能会导致某些算子的处理速度过慢,从而引起反压问题。可以通过增加算子的并行度或者调整任务的并行度来缓解反压问题。 3. 调整算子的处理逻辑。如果算子的处理逻辑过于复杂或者存在性能瓶颈,可能会导致算子处理速度过慢,从而引起反压问题。可以通过优化算子的处理逻辑、使用异步IO等方式来提高算子的处理速度。 4. 使用Flink反压机制。Flink提供了反压机制来解决反压问题,可以通过设置ExecutionConfig.setAutoWatermarkInterval()方法来开启反压机制。反压机制会根据算子的处理速度来自动调整生产数据的速度,从而避免数据积压和反压问题。 5. 使用Flink的流控机制。Flink还提供了流控机制来限制数据的生产和消费速度,从而避免反压问题。可以通过设置ExecutionConfig.setLatencyTrackingInterval()方法来开启流控机制。流控机制会根据数据的延迟来调整生产和消费数据的速度,从而保证系统的稳定性和性能。 通过以上几个步骤可以排查和解决Flink应用程序中的反压问题。需要注意的是,反压问题是一个非常常见的问题,需要在设计和编写Flink应用程序时充分考虑并发和性能问题,从而避免反压问题的出现。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值