Flink实时任务性能调优

这篇具有很好参考价值的文章主要介绍了Flink实时任务性能调优。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

通常我们在开发完Flink任务提交运行后,需要对任务的参数进行一些调整,通常需要调整的情况是任务消费速度跟不上数据写入速度,从而导致实时任务出现反压、内存GC频繁(FullGC)频繁、内存溢出导致TaskManager被Kill。

今天讲一下Flink任务中常见的性能场景及解决思路。

反压

在Flink任务中多个Task之间需要进行数据交换,在流式计算中数据的生产方的生产速度和消费方的消费速度不匹配时,可能会导致计算节点OOM或丢失数据,在Flink中通过反压机制平衡数据生产方和消费方的处理速度,以求系统达到整体的平衡。

实时任务出现反压时,在Blink版本中做了大量的改进,从资源使用、作业调优、日志查询等维度新增了大量功能,使得用户可以更方便的对Flink作业进行运维,Vertex 增加了InQueue,OutQueue等多项指标,可以方便的追踪数据的反压、过滤及倾斜情况通常,我们可以通过在Flink Web UI中观察出现红色的Vertex节点及其上下游,重点需要关注的指标是Out Queue的占用率,当Out Queue占用率高表示该节点的下游节点消费能力不足,需要重点调解该下游节点的计算资源(已贡献社区)。

如果是老的Flink版本,可以先在 Flink web ui 中,定位到具体的算子之后,查看 BackPressure 模块,通过颜色和数值来判断任务的繁忙和反压情况(若颜色为红色,表示当前算子繁忙,有反压的情况;若颜色为绿色,标识当前算子不繁忙,没有反压)。

如果你看到 subtasks 的状态为 OK 表示没有反压。HIGH 表示这个 subtask 被反压。状态用如下定义:

  • OK: 0% <= 反压比例 <= 10%
  • LOW: 10% < 反压比例 <= 50%
  • HIGH: 50% < 反压比例 <= 100%

Flink实时任务性能调优,# Flink,flink,大数据,实时任务,blink,优化,反压,背压

常见场景及解决思路

场景一、任务反压(算子消费瓶颈)

典型场景为,一连串的计算节点都是红色,Out Queue都是100%,此时需要定位到最后一个Out Queue为100%的算子节点的下游节点,该节点的消费能力不达标,导致上游消息堆积。我们可以对该算子的资源进行调整,如 适当调大并发度,对应内存可适当调小,如果是窗口聚合节点则可以调大内存(在开窗场景下,window数据计算节点需要缓存窗口大小时长的数据,并在checkpoint时需要将窗口的中间状态存储,因此需要增加窗口计算节点的堆内存)

场景二、任务无反压,但延迟高(source端瓶颈)

这种情况表现为,整体没有出现明显反压,即所有计算节点的Out Queue都不高。

这种情况的出现,有可能是上游源头节点的并发度不够,如kafka的topic有三个分区,消费的时候,只开了一个并发,通常建议消费并发数和topic的分区一致。

如果增加source的并发度之后,延迟没有下降,则可能是在任务源头节点包含复杂计算,且该算子和源头并发一致,出现了合并任务链(operater chain),此时可以考虑将source算子单独剥离出来,即调整source下游算子的并发度,解除合并任务链。

场景三、任务异常(内存超用)

实时任务异常Failover的情况下,我们需要关注任务是否因为某个TaskManager内存超用被kill的情况,如果发现异常日志中记录了:

"org.apache.flink.runtime.io.network.netty.exception.RemoteTransportException: Connection unexpectedly closed by remote task manager 'null'. This might indicate that the remote task manager was lost"

则普遍情况是因为内存超用,我们需要根据异常信息中提示的任务节点,调整执行计划中对应节点的内存配置,具体可在WebUI中查看Exceptions模块中查看,其中Root Exception里面记录了最新一次发生的异常栈,Exception History中记录的是任务运行过程中所有发生的异常,以及每次异常的计算节点是哪些。

场景四、GroupBy

针对group by场景,可以通过配置minibatch,来提升吞吐,降低状态的访问,减少对下游的输出压力。

在Stram SQL纯流模式下,每进来一条数据都会去操作state,IO消耗较大,设置minibatch后,同一个key的一批数据只访问一次state,且只输出最新的一条数据,即减少了state的访问也减少了向下游的数据更新,minibatch的配置如下:

# 1. 表示整个job允许延迟
blink.miniBatch.allowLatencyMs=5000

# 2. 单个batch的size
blink.miniBatch.size=1000

Flink实时任务性能调优,# Flink,flink,大数据,实时任务,blink,优化,反压,背压

场景五、任务重启,并设置重启时间(初始时间)

这种情况一般出现在任务刚启动时有非常高的延迟,可能是因为在任务启动时或重启时设置了一个比较老的start time,导致任务从很早的时间开始拉取数据,会导致刚开始整个任务的qps非常高,在监控上的表现为一开始有很高的延迟,随后缓慢下降直到正常水平,若没有下降则可以适当增加资源,一般来说这种情况不需要特殊处理,可以根据实际需求来判断是否需要调整start time为当前时间。

场景六、Time Interval Join 代替 双流Join

建议在双流join的时候,使用时间窗口join,而不是双流join。

默认情况下双流join会将两条流的数据都缓存到状态中,默认状态存储时长为1.5天,状态太大会导致join算子性能低下。

而实际上大部分场景,join都是由时效性要求的,比如商品曝光1分钟引导的点击,其业务上隐含了数据的时效性关联条件,当数据失效后,它的状态是可以清理掉释放资源。

Flink实时任务性能调优,# Flink,flink,大数据,实时任务,blink,优化,反压,背压

 

总结

  1. 判断是否出现反压,在反压节点定位算子,增加并发或调整cpu资源;
  2. 若无明显反压,则可能是source端瓶颈,可以提升并发度,尽量和source源的分区数量一致,另外可以查看是否是因为source数据处理的算子逻辑太复杂,且和读算子并行一致出现合并任务链(operater chain)的情况,此时可以调整该计算算子的并行度,将source算子剥离出链。
  3. 参数优化,配置minibatch(针对GroupBy),可提升吞吐,降低状态的访问次数,减少对下游的输出压力。
  4. 双流join场景中使用Time Interval Join,而不是双流Join,双流Join会把状态保持1.5天,非常消耗资源。
  5. 重置任务时,根据实际需求出发,若默认很久以前的数据可放弃,则可以调整start time为较近的时间。
  6. 提升batchSize增加读写IO。

希望本文对你有帮助,请点个赞鼓励一下作者吧~ 谢谢!文章来源地址https://www.toymoban.com/news/detail-560254.html

到了这里,关于Flink实时任务性能调优的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 实时Flink的数据库与Kafka集成优化案例

    在现代数据处理系统中,实时数据处理和分析是至关重要的。Apache Flink是一个流处理框架,可以用于实时数据处理和分析。在许多场景下,Flink需要与数据库和Kafka等消息系统进行集成,以实现更高效的数据处理。本文将讨论Flink与数据库和Kafka集成的优化案例,并提供实际示

    2024年02月20日
    浏览(41)
  • 【Flink精讲】Flink性能调优:CPU核数与并行度

    提交任务命令: bin/flink run -t yarn-per-job -d -p 5 指定并行度 -Dyarn.application.queue=test 指定 yarn 队列 -Djobmanager.memory.process.size=2048mb JM2~4G 足够 -Dtaskmanager.memory.process.size=4096mb 单个 TM2~8G 足够 -Dtaskmanager.numberOfTaskSlots=2 与容器核数 1core: 1slot 或 2core: 1slot -c com.atguigu.flin

    2024年04月11日
    浏览(42)
  • flink任务内存调优,TaskManager、JobManager内存配置

            Flink是基于java的JVM运行,拥有高效的数据处理能力,但是考虑到用户在 Flink 上运行的应用的多样性,尽管flink框架已经为所有配置项提供合理的默认值,仍无法满足所有情况下的需求。 为了给用户生产提供最大化的价值, Flink 允许用户在整体上以及细粒度上对集

    2024年02月06日
    浏览(47)
  • Flink 优化(六) --------- FlinkSQL 调优

    FlinkSQL 官网配置参数: https://ci.apache.org/projects/flink/flink-docs-release-1.13/dev/table/config.html Flink SQL 新手有可能犯的错误,其中之一就是忘记设置空闲状态保留时间导致状态爆炸。列举两个场景: ➢ FlinkSQL 的 regular join(inner、left、right),左右表的数据都会一直保存在状态里,不

    2024年02月14日
    浏览(40)
  • Flink:处理大规模复杂数据集的最佳实践深入探究Flink的数据处理和性能优化技术

    作者:禅与计算机程序设计艺术 随着互联网、移动互联网、物联网等新型网络技术的不断发展,企业对海量数据的处理日益依赖,而大数据分析、决策支持、风险控制等领域都需要海量的数据处理能力。如何高效、快速地处理海量数据、提升处理效率、降低成本,是当下处理

    2024年02月13日
    浏览(53)
  • Flink任务实战优化

    前言: 一个好产品,功能应该尽量包装在服务内部;对于Flink而言,无疑是做到了这一点。但是用户在使用Flink的时候,依然可以从版本的选择、代码逻辑、资源参数、业务的数据情况等方面做任务级的定制化优化;用最合理的资源使用,保障实时性、稳定性和最佳Tps的处理

    2024年02月03日
    浏览(41)
  • Flink实时计算资源如何优化

    flink实时计算任务可以从以下四个方面进行优化 内存优化:Flink任务需要大量的内存来存储数据和状态信息。因此,我们需要尽可能地减少内存的使用量。可以通过以下几种方式来实现: 使用更小的窗口大小:窗口大小越大,需要使用的内存就越多。因此,我们可以使用更小

    2024年02月10日
    浏览(38)
  • Flink性能优化小结

    jvm内存优化 内存优化 netty优化 akka优化 并行度优化 对象重用 checkpoint优化 网络内存调优 状态优化 flink数据倾斜优化 flink背压 jvm内存参数调优 Flink是依赖内存计算,计算过程中内存不够对Flink的执行效率影响很大。可以通过监控GC(Garbage Collection),评估内存使用及剩余情况

    2024年02月01日
    浏览(52)
  • 性能提升3-4倍!贝壳基于Flink + OceanBase的实时维表服务

    作者介绍: 肖赞,贝壳找房(北京)科技有限公司 OLAP 平台负责人,基础研发线大数据平台部架构师。 贝壳找房是中国最大的居住服务平台。作为居住产业数字化服务平台,贝壳致力于推进居住服务的产业数字化、智能化进程,通过聚合、助力优质服务者,为中国家庭提供

    2024年02月10日
    浏览(34)
  • Flink+Paimon多流拼接性能优化实战

    目录 (零)本文简介 意外收获: (一)背景 (二)探索梳理过程 (三)源码改造 (四)修改效果 1、JOB状态 2、Level5的dataFile总大小 3、数据延迟 4、关联率 (五)未来展望:异步Compact Paimon多流拼接/合并性能优化;         为解决 离线T+1多流拼接数据时效性 、 Flink实时

    2024年02月09日
    浏览(42)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包