大数据培训flink8 个高频面试实战题分享

温馨提示:这篇文章已超过738天没有更新,请注意相关的内容是否还可用!

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

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

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

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

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

大数据培训flink8 个高频面试实战题分享 第1张

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 在一起:

大数据培训flink8 个高频面试实战题分享 第2张

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

大数据培训flink8 个高频面试实战题分享 第3张

第二种方式:在 Flink 1.13 中,提供了火焰图,可以通过火焰图定位问题。火焰图需要配置 rest.flamegraph.enabled: true 打开

大数据培训flink8 个高频面试实战题分享 第4张

02反压有哪些危害?

  1. 任务处理性能出现瓶颈:以消费 Kafka 为例,大概率会出现消费 Kafka Lag。
  2. Checkpoint 时间长或者失败:因为某些反压会导致 barrier 需要花很长时间才能对齐,任务稳定性差。
  3. 整个任务完全卡住。比如在 TUMBLE 窗口算子的任务中,反压后可能会导致下游算子的 input pool 和上游算子的 output pool 满了,这时候如果下游窗口的 watermark 一直对不齐,窗口触发不了计算的话,【关注尚硅谷,轻松学IT】下游算子就永远无法触发窗口计算了。整个任务卡住。

03经常碰到哪些问题会任务反压?

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

  1. 数据倾斜:当前算子的每个 sub-task 只能处理 1w qps 的数据,而由于数据倾斜,这个算子的其中一些 sub-task 平均算下来 1s 需要处理 2w 条数据,但是实际只能处理 1w 条,从而反压。比如有时候 keyby 的 key 设置的不合理。
  2. 算子性能问题:下游整个整个算子 sub-task 的处理性能差,输入是 1w qps,当前算子的 sub-task 算下来平均只能处理 1k qps,因此就有反压的情况。比如算子需要访问外部接口,访问外部接口耗时长。

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

  1. 事前:解决上述介绍到的 数据倾斜、算子性能 问题。
  2. 事中:在出现反压时:
  • 限制数据源的消费数据速度。比如在事件时间窗口的应用中,可以自己设置在数据源处加一些限流措施,让每个数据源都能够够匀速消费数据,避免出现有的 Source 快,有的 Source 慢,导致窗口 input pool 打满,watermark 对不齐导致任务卡住。
  • 关闭 Checkpoint。关闭 Checkpoint 可以将 barrier 对齐这一步省略掉,促使任务能够快速回溯数据。我们可以在数据回溯完成之后,再将 Checkpoint 打开。

05实时数据延迟是怎么监控的?报警策略又是怎么制定的?

几乎我问到的所有的小伙伴都能回到到 Flink 消费 Source 的 Lag 监控,我们可以把这个监控项升级一下,即 Kafka 到 Flink 延迟。原因如下:

以 Flink 消费 Kafka 为例,几乎所有的任务性能问题都最终能反映到 Kafka 消费 Flink 延迟,所以几乎 100% 的任务性能问题都能由 Kafka 到 Flink 延迟 这个监控发现。

06通过什么样的监控及保障手段来保障实时指标的质量?

当我提出这个问题的时候。群里的小伙伴给出了建设性意见:

那就是:等着用户工单投诉

但是在博主的正确引导之下,小伙伴萌走上了正轨

这里总结群里小伙伴的一些意见,得出了一个大多数企业都可以 快速构建 实时数据质量保障体系,从 事前、事中、事后 x 任务层面、指标层面 进行监控、保障:

1.事前:

  • 任务层面:根据峰值流量进行压力测试,并且留一定 buffer,用于事前保障任务在资源层面没有瓶颈
  • 指标层面:根据业务要求,上线实时指标前进行相同口径的实时、离线指标的验数,在实时指标的误差不超过业务阈值时,才达到上线要求

2.事中:

  • 任务层面:贴源层监控 Kafka 堆积延迟等报警检测手段,用于事中及时发现问题。比如的普罗米修斯监控 Lag 时长
  • 指标层面:根据指标特点实时离线指标结果对比监控。检测到波动过大就报警。比如最简单的方式是可以通过将实时结果导入到离线,然后定时和离线指标对比

3.事后:

  • 任务层面:对于可能发生的故障类型,构建用于故障修复、数据回溯的实时任务备用链路
  • 指标层面:构建指标修复预案,根据不同的故障类型,判断是否可以使用实时任务进行修复。如果实时无法修复,构建离线恢复链路,以便使用离线数据进行覆写修复

07operator-state 和 keyed-state 两者的区别?

详细描述一下上面的问题:

operator-state 和 keyed-state 两者的区别?最大并行度又和它们有什么关系?举个生产环境中经常出现的案例,当用户停止任务、更新代码逻辑并且改变任务并发度时,两种 state 都是怎样进行恢复的?

  1. 总结如下:

大数据培训flink8 个高频面试实战题分享 第5张

2.operator-state:

大数据培训flink8 个高频面试实战题分享 第6张

  • 状态适用算子:所有算子都可以使用 operator-state,没有限制
  • 状态的创建方式:如果需要使用 operator-state,需要实现 CheckpointedFunction(建议) 或 ListCheckpointed 接口
  • DataStream API 中,operator-state 提供了 ListState、BroadcastState、UnionListState 3 种用户接口
  • 状态的存储粒度:以单算子单并行度粒度访问、更新状态
  • 并行度变化时:
  • a. ListState:均匀划分到算子的每个 sub-task 上,比如 Flink Kafka Source 中就使用了 ListState 存储消费 Kafka 的 offset,其 rescale 如下图

大数据培训flink8 个高频面试实战题分享 第7张

  • b. BroadcastState:每个 sub-task 的广播状态都一样 c. UnionListState:将原来【关注尚硅谷,轻松学IT】所有元素合并,合并后的数据每个算子都有一份全量状态数据

3.keyed-state:

大数据培训flink8 个高频面试实战题分享 第8张

  • 状态适用算子:keyed-stream 后的算子使用。注意这里很多同学会犯一个错误,就是大家会认为 keyby 后面跟的所有算子都使用的是 keyed-state,但这是错误的 ,比如有 keyby.process.flatmap,其中 flatmap 中使用状态的话是 operator-state
  • 状态的创建方式:从 context 接口获取具体的 keyed-state
  • DataStream API 中,keyed-state 提供了 ValueState、MapState、ListState 等用户接口,其中最常用 ValueState、MapState
  • 状态的存储粒度:以单 key 粒度访问、更新状态。举例,当我们使用 keyby.process,在 process 中处理逻辑时,其实每一次 process 的处理 context 都会对应到一个 key,所以在 process 中的处理都是以 key 为粒度的。这里很多同学会犯一个错 ,比如想在 open 方法中访问、更新 state,这是不行的,因为 open 方法在执行时,还没有到正式的数据处理环节,上下文中是没有 key 的
  • 并行度变化时:keyed-state 的重新划分是随着 key-group 进行的。其中 key-group 的个数就是最大并发度的个数。其中一个 key-group 处理一段区间 key 的数据,不同 key-group 处理的 key 是完全不同的。当任务并行度变化时,会将 key-group 重新划分到算子不同的 sub-task 上,任务启动后,任务数据在做 keyby 进行数据 shuffle 时,依然能够按照当前数据的 key 发到下游能够处理这个 key 的 key-group 中进行处理,如下图所示。注意:最大并行度和 key-group 的个数绑定,所以如果想恢复任务 state,最大并行度是不能修改的。大家需要提前预估最大并行度个数。

大数据培训flink8 个高频面试实战题分享 第9张

08你认为以后 Flink SQL 的发展趋势是 unbounded 类 SQL 为主还是窗口类 SQL 为主?原因?

博主认为是 unbounded 类 SQL。博主的观点如下:

  1. 先来看看为什么最开始发明了窗口类的算子:窗口(可以叫做 bounded)和 unbounded 的差异就在于,unbounded 类产出的结果不是一个固定结果,因为有 retract 机制(即 retract 流);窗口类的算子出现的最原始的目的就是解决 unbounded 类产出不固定结果的问题,是想要创造一个可以产出固定结果的算子(即 append 流,不考虑 allow_lateness),所以窗口算子类算子可以说是解决 unbounded 的存在的一个问题而诞生的,个人理解是流式任务在 SQL 上能力拓展。
  2. 计算引擎(Flink)的流批一体:目前批中是没有时间窗口之类的概念的,www.atguigu.com所以如果想做到流批一体在计算引擎用户接口层的统一的话,unbounded SQL 可以做到这一点
  3. 流式 SQL 的普及度,用户上手难易程度:目前大多数数据开发都还是离线数据开发,离线数据开发切换到实时数据开发使用 unbounded 类 SQL 的切换难度是会小,不用去学习窗口类的接口

但是在目前全链路 changelog 计算不是非常成熟的场景下,是没法完全摒弃窗口类应用的。目前业界做的好的就是阿里,阿里目前几乎不用窗口类应用,他们有一套成熟的 changelog 链路。

文章来源于数仓宝贝库

推荐阅读:

大数据培训面试Flink八股文分享

大数据开发之Flink + TiDB

大数据开发之Flink sql 的基础用法

九七分享吧所有文章来源于网络收集整理,如有侵权请联系QQ2387153712删除,如果这篇文章对你有帮助或者还不错的请给小编点个小赞(◠‿◠),小编每天整理文章不容易(ಥ_ಥ)!!!

文章版权声明:除非注明,否则均为九七分享吧原创文章,转载或复制请以超链接形式并注明出处。

相关阅读

苹果 iOS/iPadOS 15.4.1 正式版发布

哎呦,被盗哦!周杰伦无聊猿NFT疑被钓鱼,价值超300万

“蔚小理”一季度成绩单:小鹏理想均跨过三万辆门槛,蔚来垫底

最完整的人类基因组序列,今天凌晨公布了!

手机行业不景气了?国产厂商大砍单:1.7亿订单取消

快手或将受益于互联网监管

我国实现首例V频段低轨卫星测控

北京外卖封签上线首日调查:1个封签约2分钱,已大面积推广

iPhone更换微信图标教程,安卓:不就是换个主题?

豆瓣关闭私密小组,壮士断腕为时未晚

台积电将5nm产量提高到15万片/月

京东增持京东物流 为了挽救股价还是应对激烈竞争?

发表评论

表情:
评论列表 (暂无评论,305人围观)

还没有评论,来说两句吧...

取消
微信二维码
微信二维码
支付宝二维码