Flink任务实战优化

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

一、Flink任务优化分析

1.1 参考Spark的优化方式

对于任何的技术发展,后来的的技术架构都可以参考之前优秀竞品的设计思想或缺陷,然后加以改进和优化。大数据分布式计算领域,Flink在设计自己的功能时,都做了哪些努力,让其在实现自己特性的同时,依旧保障了高性能。参考Spark的性能优化:Saprk可以从开发调优(RDD使用、算子区别、序列化方式、对象等)、资源参数调优(Driver、Executor数量和大小等)、数据负载调优(数据倾斜处理)、shuffle调优(shuffle方式和局部内存配置),四个方面做优化。

1.2 任务开发分析

Flink在开发阶段:Flink有四个模块的SDK提供数据操作API:DateStream、DataSet、FlinkTbale、FlinkSQL;

其他有Checkpoint配置、RocksDB选择存储,如同RDD类似;所以在开发层面,设置Checkpoint配置、判断是否选择RocksDB作为状态存储,基本可以把精力聚焦在逻辑层面;当然在sink阶段,可以对写入中间件的客户端做组件级的优化,减轻写入背压。

1.3 资源参数分析

资源参数分析:Flink任务可以动态调节并发数(slot),分配CPU资源;内存主要有JobManager和TaskManager两个进程,TaskManager中有多个内存级线程任务;所以可以从slot数、两个进程资源的大小、以及TaskManager进程内部的多个局部内存的使用情况,精细化调节、优化任务;

1.4 数据负载分析

Flink数据负载分析:Flink也是并发处理,所以存在数据在某个阶段的单个任务高负载运行,这种时候要排查出高聚合数据,然后做特殊处理;实时处理不存在阶段影响、理想存在阶段计算结果落磁盘,数据负载在离线场景上比实时场景上,对任务性能影响更大。

1.5 Shuffle分析

spark的计算架构是阶段式计算,每处理完上一个阶段的计算,会把内存溢出的结果写入磁盘,下个阶段从内存和磁盘读取上阶段结果再做计算;spark的主要性能就消耗在每个阶段之间的shuffle上;Spark用单独的进程管理shuffle阶段的操作,有多种不同的shuffle模式选择(如:HashShuffle、SortShuffle等),涉及多个shuffleManager进程的内存配置优化;

Flink1.16版本之前,实时计算和离线计算使用不同的shuffle模式;实时计算使用Pipelined Shuffle计算Task任务,离线计算使用 Blocking Shuffle计算任务,Flink1.16之后,新加入了Hybrid Shuffle处理方式计算。

二、Flink任务优化操作

总结第一节四个方面的内容:Flink可以从代码开发、资源参数配置、数据负载三个方面做任何版本的任务级优化;可以通过对FLink版本的选择,做到离线计算shuffle级的优化。

2.1 Flink开发调优
2.1.1 开发SDK选择

对于没有边界数据流的实时处理和有边界数据流的离线处理,可以选择不同的SDK开发,

关系如下:

Flink任务实战优化_第1张图片

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

2.1.2 其他代码层优化操作

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

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

CheckPoint与StateBackend代码配置如下:

Flink任务实战优化_第2张图片

注: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启动方式样例参考:

Flink任务实战优化_第3张图片

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

Flink任务实战优化_第4张图片

TaskManager进程,内存架构图:

Flink任务实战优化_第5张图片

2.3 数据负载优化

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

如下图:是一个生产任务,并发任务之间就有五倍的负载差距;

Flink任务实战优化_第6张图片

出现负载了要如何做呢?

这里就和前面算子计算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版本后,优化离线处理方式之后,数据负载的影响在服务内部技术架构上优化掉了。

你可能感兴趣的:(Flink,flink,大数据)