flink优化

1. 大状态调优

我们在做UV独立访客数的时候，将用户的访问时间保存到了状态中，由于访客比较多，大概有1000万，所以会造成大状态，解决办法：因为我们是统计的一天的独立访客数，所以我们设置状态的TTL为一天，这样就解决了大状态问题。

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

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

还有就是做回流用户的时候，需要把用户的末次登录日期保存到状态中，也会造成大状态，解决办法：换成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 进行结果统计，然后输出。