flink优化

1. 大状态调优

大状态调优:在我们的项目中,在做新老访客修复时,我们将每个mid的访问时间都存到了状态里面,在做回流用户数时,我们将每个用户的登录时间都存到了状态里面,导致了大状态问题,由于hashmap状态后端会将数据存储到内存,所以就会出现内存不够的情况。

 我们的解决办法就是将状态后端改成了rocksdb,并且开启增量检查点和本地恢复去进行调优。

2. 反压

反压:反压其实就是下游数据的计算速度,赶不上上游数据的发送速度。

我们遇到过一次反压,就是我们DWS层的订单表,需要去和hbase的维度表进行关联,在关联的过程中,涉及到很多的网络IO,所以导致算子计算变慢,产生了反压。

那我们怎么定位反压的呢, 我们是通过查看Web UI,发现map算子是黑色,然后我们去查看代码逻辑,发现了这个问题。

我们是通过添加Redis旁路缓存来解决这个问题的,因为Redis读取数据比较快,所以解决了算子计算慢的问题,也就解决了反压的问题。

然后我们考虑到,写Doris的时候也是和外部系统进行交互,可能也会产生反压问题,所以我们通过设置攒批发送,来预防反压问题。

还有如果我们第二天做活动,那么我们会提前增加服务器和内存、CPU资源,来预防大数据量造成的反压问题。

3. 数据倾斜

我们项目中还遇到过数据倾斜的问题,比如我们将MySQL中的数据存到kafka时,是以表名作为key保存到kafka的不同分区当中的,当我们用flink程序去读取kafka的数据时,因为每个表的数据量不同,所以每个并行度处理的数据量是相差很大的,就造成了数据倾斜。

我们的解决办法就是在source算子的后面,加上了rebalance算子,就可以将输入流数据平均分配到下游的并行任务中去,就解决了数据倾斜问题。

还有就是我们在统计各省份GMV的时候,由于每个省份的数据量不同,所以在我们根据省份keyby之后,导致有的分区数据量比别的分区数据量大很多,就导致了数据倾斜问题。

我们在统计计算各省份GMV的时候出现了频繁的反压,所以就考虑说是不是数据倾斜的问题,排查完后发现确实是数据倾斜,kafka根据不同的key存到不同的分区当中,根据表的表明作为key存到不同的分区当中,但是有些表的数据比较多,导致某个分区的量比较多,下游去消费的时候导致某个并行度的数据比较多,就导致了数据倾斜,所以说我们统计各省份GMV的时候,就出现了这种情况,之后我们讨论出了两种解决方案,一种是为了避免热点 key 的设计,把北京、上海等热点城市分成不同的区域,进行单独的处理。还有一种是通过两阶段聚合解决 KeyBy 热点,首先把分组的 key 打散,比如加随机后缀,对打散后的数据进行聚合,把打散的 key 还原为真正的 key,二次 KeyBy 进行结果统计,然后输出。
 

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