Flink調優法則
一. 性能定位
口訣分析
1. 看背壓
通常最后一個背壓高的subTask的下游就是job的明顯瓶頸之一
2. 看checkoint時長
checkpoint的時長在一定程度上可以影響job的整體吞吐
3. 查看關鍵指標
通過延遲與吞吐指標可以對任務的性能進行精准的判斷
4. 資源利用率
我們進行優化的最終目的是提供資源的利用率。
常見的性能問題如下
1. JSON序列化與反序列化
常出現在source和sink任務上，在指標上沒有體現，容易被忽略
2. Map和set的Hash沖突
由於HashMap，HashSet等隨着負載因子增高，引起的插入和查詢性能下降。
3. 數據傾斜
數據傾斜會導致其中一個或者多個subtask處理的數據量遠大於其他節點，造成局部數據延遲。
4. 和低速系統的交互
在實時系統進行高速數據處理時，當涉及到與外部低俗的系統（如Mysql,Hbase等）進行數據交互時。
5. 頻繁的GC
因內存或者內存比例分配不合理導致頻繁GC, 甚至是TaskManager失聯
6. 大窗口
窗口size大，數據量大，或者是滑動窗口size和step的比值比較大，如size=10minmatch， step=1。
二. 經典調優場景
數據去重場景
基於用戶的瀏覽數據流統計近90天的活躍用戶數，並每隔10分鍾輸出一次當前結果，用戶構建實時數據報表。
在上面這個經典場景中，存在如下幾個特點：
1. 數據量大
日活量在6000萬+， 平均每隔用戶每天瀏覽次數為20次。
2. 增長速度快
每天新增用戶1000萬+，帶來新增瀏覽量數億。
3. 更新換代快
每年全量用戶更新換代一次。
可以有如下方案：
方案一：通過Set，map等去重結構並結合flink的state來實現
方案二：精確去重：通過bitMap/raaring bitMap
方案三：近似去重：布隆過濾器
三. 內存調優
內存調優
Flink的內存主要分為三部分，對於network buffer和manager pool都是由Flink管理的，manager pool也已經走向堆外內存，因此flink 的內存調優主要分為兩部分：
a. 非堆內存 network buffer 和 manager poll的調優
b. flink 系統中的heap內存的調優
非堆內存調優
對於非堆內存調優比較簡單，主要是調整:network buffer 和manager pool buffer 的比例
1. Networkbuffer:
-
taskmanager.network.memory.fraction (默認是0.1)
-
taskmanager.network.memory.min
( 默認是64M)
-
taskmanager.network.memory.max
(默認是1G）
原則：默認是0.1或是小於0.1，可以根據使用情況進行調整。
2. ManagerBuffer:
-
taskmanager.memory.off-heap:true
( 默認是false）
-
taskmanager.memory.fraction
(默認是0.7)
原則：在流計算中如果用戶建議調整成小於0.3
堆內存調優
Flink是運行在jvm上的，故flink應用的堆內存調優和傳統jvm調優無差別。
默認Flink使用的Parallel Scavenge的垃圾回收器可以改用G1 垃圾回收期。
啟動參數如下：
env.java.opts=-server -XX:+UseG1GC -XX:MaxGCPauseMillis=300 --XX:+PrintGCDetails