Flink任务实战优化

i7杨

已于 2024-06-04 14:34:04 修改

阅读量4.1k Flink 文章标签： flink 大数据

于 2024-01-05 14:31:39 首次发布

本文链接：https://blog.csdn.net/weixin_42049123/article/details/135408159

Flink 专栏收录该内容

6 篇文章 5 订阅

不涉及状态、窗口、时间的操作，可以用SQL表达（数据分析和数据管道）；细粒度的操作就需要底层核心API做数据处理了，比如调用外部接口，中间数据层操作等；提供多种方式，按照需求选择，正常表达业务逻辑就行。

2.1.2 其他代码层优化操作

CheckPoint的配置选择：在Flink中，CheckPoint、State与Backend存储方式，共同保障实时任务运行时的容错（离线没有）；CheckPoint有多种配置，能从运行模式、检查间隔、State快照大小和数量等方面做配置调优，StateBackend可以选择多种方式，保障CheakPoint生成状态的存储。

可以根据业务量大小、业务实时效果、业务的重要程度，调节Checkpoint和StateBackend的如下参数，观测各种任务指标的各种情况优化：

CheckPoint与StateBackend代码配置如下：

注：Checkpoint配置类属性，可检测CheckpointConfig配置类，里面有所有的配置项，我就不在这里截图了。

除此之外：

Flink在sink得时候，包装的是中间件得客户端，如Kafka、ES、Redis、Mysql等；

每个中间件客户端都有自己的优化配置:

比如Kafka客户端优化：单条size(默认1M)、bufferSize大小写、条数写、连接超时、连接数等；

比如ES客户端优化：批次写设置、间隔写设置、连接超时设置等；

比如Redis客户端优化:连接数，连接时常等设置；

比如Mysql客户端优化:客户端连接数等配置；

2.2 Flink资源参数配置优化

Flink在资源参数调优方面：可以对slots并发数、TaskManager内存大小、JobManager内存大小做Flink进程级调参优化；

在TaskManager内部，有多个内存概念，分别用来存储不同阶段、不同状态的数据，比如：托管内存、网络内存等；

除此之外，当使用Java开发Flink任务时，还可以对Java的Gc做选择,比如：-Denv.java.opts="-Dfile.encoding=UTF-8"；

yarn启动方式样例参考：

TaskManager局部组件内存级参数配置如下：

TaskManager进程，内存架构图：

2.3 数据负载优化

如何观察数据负载现象：在Flink的运行的时候，taskManagers的task会记录数据情况；

如下图：是一个生产任务，并发任务之间就有五倍的负载差距；

出现负载了要如何做呢？

这里就和前面算子计算reBalance有关；

比如实时计算时：source是kafka：就和kafka的分区数据负载有关，可以从Kafka的数据生产者配置分区轮询；

如果是算子间，对于大负载的task,对读出数据的算子做key均匀打散，初次计算完后，再还原key做二次聚合；

离线计算时：对于分组计算，task负载操作类似；

Flink本身的运行机制，保证数据计算会快速释放资源，所以这个优化只是让资源释放更快，加大业务的单点TPS。

2.4 Shuffle优化

Flink社区多个版本整体上存在三种shuffle：Pipelined Shuffle、Blocking Shuffle、Hybrid Shuffle

这三者有什么区别呢？

Pipelined Shuffle方式可以全在内存中实时计算task，通过网络内存（netWork）做缓冲，且没有阶段计算等待限制; Blocking Shuffle方式每个阶段都要全部task计算完,落地到磁盘，下一个阶段再从磁盘读取开始计算；Hybrid Shuffle结合 Pipelined Shuffle实时快速计算的特性和Blocking Shuffle写磁盘稳定性特性，让离线计算不用每个阶段task算完和必须落地到磁盘的操作，当内存资源足够的时候基本可以不落地到磁盘；利用了Flink实时流快速计算的特性，写磁盘做为安全保障，保障离线计算的处理能力。

Flink没有ShuffleManager管理进程，它使用对内存资源队列感知和背压的方式，巧妙地解决了shuffle过程的定制化管理；可以说对于Flink的shuffle阶段，Flink基本在逻辑内部就自动实现了，没有spark那样需要专门做shuffleManager做内存管理。

三、总结

Flink任务分离线和实时两种计算场景：

从版本性能上：对于实时处理，各版本的设计架构基本一致；Flink1.15和Flink1.16对离线处理，任务管理架构，做了比较大的调整，相比Spark的计算管理架构和Flink之前的Blocking Shuffle方式，有了较大的性能提升；

从代码逻辑上：Flink实时处理通过对Checkpoint的配置、状态后端存储方式选择，离线对每个批处理的数量配置等，做特殊配置优化处理；以及开发SDK模块的选择，做到尽量只关心开发逻辑的的优化；

从资源参数配置上:离线和实时均可以从>的并发数量，JobManager、taskManager进程资源大小，以及taskManager内部,托管内存，网络内存等局部内存上优化运行任务。

从数据负载上：实时任务由于其快速的资源使用与释放，数据负载影响不大，但是对实时数据负载的优化，可以提升最大TPS的数据处理能力（数百万TPS）；离线任务在早期的版本架构中，因为Blocking Shuffle阶段结果数据要整体落到磁盘，数据负载会直接导致局部资源等待，所以数据负载对离线处理的性能影响很大，1.15版本后，优化离线处理方式之后，数据负载的影响在服务内部技术架构上优化掉了。