實時計算 Flink性能調優

摘要： 實時計算 Flink新增自動調優功能autoconf。可以在流做業以及上下游性能達到穩定的前提下，根據您做業的歷史運行情況，從新分配各算子資源和併發數，達到優化做業的目的。更多詳細說明請您參閱自動配置調優。

自動配置調優

實時計算 Flink新增自動調優功能autoconf。可以在流做業以及上下游性能達到穩定的前提下，根據您做業的歷史運行情況，從新分配各算子資源和併發數，達到優化做業的目的。更多詳細說明請您參閱自動配置調優。

首次智能調優

1. 建立一個做業。如何建立做業請參看快速入門。

2. 上線做業。選擇智能推薦配置，指定使用CU數爲系統默認，不填便可。點擊下一步。
   

3. 數據檢查，預估消耗CU數。
   

4. 在運維界面啓動做業，根據實際業務須要指定讀取數據時間。
   

   說明:實時計算做業啓動時候須要您指定啓動時間。實際上就是從源頭數據存儲的指定時間點開始讀取數據。指定讀取數據時間須要在做業啓動以前。例如，設置啓動時間爲1小時以前。

5. 待做業穩定運行10分鐘後，且如下狀態符合要求，便可開始下一次性能調優。

   • 運行信息拓撲圖中IN_Q不爲100%。
     
   • 數據輸入RPS符合預期。
     

非首次性能調優

1. 中止>下線做業。
   

2. 從新上線做業。選擇智能推薦配置，指定使用CU數爲系統默認，不填便可。點擊下一步。
   

3. 數據檢查，再次預估消耗CU數。
   

4. 在運維界面啓動做業，待做業穩定運行十分鐘後，便可再一次性能調優。
   

說明：

• 自動配置調優通常須要3到5次才能達到理想的調優效果。請完成首次性能調優後，重複非首次性能調優過程屢次。
• 每次調優前，請確保足夠的做業運行時長，建議10分鐘以上。
• 指定CU數（參考值） = 實際消耗CU數*目標RPS/當前RPS。
  • 實際消耗CU數：上一次做業運行時實際消耗CU
  • 目標RPS：輸入流數據的實際RPS（或QPS）
  • 當前RPS：上一次做業運行時實際的輸入RPS

手動配置調優

手動配置調優能夠分如下三個類型。

• 資源調優
• 做業參數調優
• 上下游參數調優

資源調優

資源調優便是對做業中的Operator的併發數（parallelism）、CPU（core）、堆內存（heap_memory）等參數進行調優。

分析定位資源調優節點

定位性能瓶頸節點

性能瓶頸節點爲Vertex拓撲圖最下游中參數IN_Q值爲100%的一個或者多個節點。以下圖，7號節點爲性能瓶頸節點。

分析性能瓶頸因素

性能瓶頸的可分爲三類。

• 併發（parallelism）不足
• CPU（core）不足
• MEM（heap_memory）不足

以下圖，7號節點的性能瓶頸是資源（CPU和/或MEM）配置不足所致使。

說明：判斷性能瓶頸因素方法

• 瓶頸節點的資源健康分爲100，則認爲資源已經合理分配，性能瓶頸是併發數不足所致使。
• 瓶頸節點的資源健康分低於100，則認爲性能瓶頸是單個併發的資源（CPU和/或MEM）配置不足所致使。
• 無持續反壓，但資源健康分低於100，僅代表單個併發的資源使用率較高，但暫不影響做業性能，可暫不作調優。

經過做業運維頁面中Metrics Graph功能，進一步判斷性能瓶頸是CPU不足仍是MEM不足。步驟以下。

1. 運維界面中，點擊TaskExecutor，找到性能瓶頸節點ID，點擊查看詳情。
   

2. 選擇Metrics Graph，根據曲線圖判斷CPU或者MEM是否配置不足（不少狀況下二者同時不足）。
   

調整資源配置

完成了性能瓶頸因素判斷後，點擊開發>基本屬性>跳轉到新窗口配置，開始調整資源配置。

批量修改Operator

1. 點擊GROUP框，進入批量修改Operator數據窗口。
   

   說明：

   1. GROUP內全部的operator具備相同的併發數。
   2. GROUP的core爲全部operator的最大值。
   3. GROUP的_memory爲全部operator之和。
   4. 建議單個Job維度的CPU:MEM=1:4，即1個核對應4G內存。

2. 配置修改完成後點擊應用當前配置並關閉窗口。
   

單個修改Operator

1. 點擊Operator框，進入修改Operator數據窗口。
   

2. 配置修改完成後點擊應用當前配置並關閉窗口。
   

參數調整說明

您只需調整parallelism、core和heap_memory三個參數，即能知足大部分的資源調優需求。

• Parallelism
  • source節點
    資源根據上游Partition數來。例如source的個數是16，那麼source的併發能夠配置爲1六、八、4等。不能超過16。
  • 中間節點
    根據預估的QPS計算。對於數據量較小的任務，設置和source相同的併發度。QPS高的任務，能夠配置更大的併發數，例如6四、12八、或者256。
  • sink節點
    併發度和下游存儲的Partition數相關，通常是下游Partition個數的2~3倍。若是配置太大會致使數據寫入超時或失敗。例如，下游sink的個數是16，那麼sink的併發最大能夠配置48。
• Core
  即CPU，根據實際CPU使用比例配置，建議配置值爲0.25，可大於1。
• Heap_memory
  堆內存。根據實際內存使用情況進行配置。
• 其餘參數
  • state_size：默認爲0，group by、join、over、window等operator需設置爲1。
  • direct_memory：JVM堆外內存，默認值爲0, 建議不要修改。
  • native_memory：JVM堆外內存，默認值爲0，建議修改成10MB。
  • chainingStrategy：chain策略，根據實際須要修改。

做業參數調優

1. 在開發頁面的右側選擇做業參數。
   

2. 輸入調優語句。

優化	解決問題	調優語句
MiniBatch	提高吞吐，下降對下游壓力僅對Group by有效。	blink.miniBatch.allowLatencyMs=5000 blink.miniBatch.size=1000
LocalGlobal	優化數據傾斜問題	blink.localAgg.enable=true
TTL	設置State狀態時間	1.x：state.backend.rocksdb.ttl.ms=129600000 2.x：state.backend.niagara.ttl.ms=129600000 其中，1.x 表示需顯式開啓，2.x 表示默認開啓。

注意：添加或刪除MiniBatch或LocalGlobal參數，job狀態會丟失，修改值大小狀態不會丟失。

上下游參數調優

實時計算 Flink能夠在with參數內設置相應的參數，達到調優上下游存儲性能的目的。

調優步驟：

1. 進入做業的開發界面。
2. 肯定須要調優的上下游引用表的語句。
3. 在with參數中配置相應的調優參數。以下圖。
   

batchsize參數調優

實時計算 Flink的每條數據均會觸發上下游存儲的讀寫，會對上下游存儲造成性能壓力。能夠經過設置batchsize，批量的讀寫上下游存儲數據來下降對上下游存儲的壓力。

名字	參數	詳情	設置參數值
Datahub源表	batchReadSize	單次讀取條數	可選，默認爲10
Datahub結果表	batchSize	單次寫入條數	可選，默認爲300
日誌服務源表	batchGetSize	單次讀取logGroup條數	可選，默認爲10
ADB結果表	batchSize	每次寫入的批次大小	可選，默認爲1000
RDS結果表	batchSize	每次寫入的批次大小	可選，默認爲50

注意： 添加、修改或者刪除以上參數後，做業必須中止-啓動後，調優才能生效。

cache參數調優

名字	參數	詳情	設置參數值
RDS維表	Cache	緩存策略	默認值爲None,可選LRU、ALL。
RDS維表	cacheSize	緩存大小	默認值爲None,可選LRU、ALL。
RDS維表	cacheTTLMs	緩存超時時間	默認值爲None,可選LRU、ALL。
OTS維表	Cache	緩存策略	默認值爲None, 可選LRU,不支持ALL。
OTS維表	cacheSize	緩存大小	默認值爲None, 可選LRU,不支持ALL。
OTS維表	cacheTTLMs	緩存超時時間	默認值爲None, 可選LRU,不支持ALL。

注意： 添加、修改或者刪除以上參數後，做業必須中止-啓動後，調優才能生效。

手動配置調優流程

1. 資源調優、做業參數調優、上下游參數調優
2. 開發上線做業
3. 資源配置方式：使用上次資源配置
4. 數據檢查
5. 上線

說明：完成資源、做業參數、上下游參數調優後，手動配置調優後續的步驟與自動配置調優基本一致。區別在於資源配置環節須要選擇使用上次資源配置。

FAQ

Q：性能調優後做業爲何運行不起來？

A:可能性1：首次自動配置時指定了CU數，但指定的CU數過小（好比小於自動配置默認算法的建議值，多見於做業比較複雜的狀況），建議首次自動配置時不指定CU數。
可能性2：默認算法建議的CU數或指定的CU數超過了項目當前可用的CU數，建議擴容。

Q：Vertex拓撲中看不到持續反壓，但延遲卻很是大，爲何？

A：可能性1：若延時直線上升，需考慮是否上游source中部分partition中沒有新的數據，由於目前delay統計的是全部partition的延時最大值。
可能性2：Vertex拓撲中看不到持續反壓，那麼性能瓶頸點可能出如今source節點。由於source節點沒有輸入緩存隊列，即便有性能問題，IN_Q也永遠爲0（一樣，sink節點的OUT_Q也永遠爲0）。
解決方案：經過手動配置調優，將source節點（GROUP）中的operator中chainingStrategy修改成HEAD，將其從GROUP中拆解出來。而後上線運行後再看具體是哪一個節點是性能瓶頸節點，若依然看不到性能瓶頸節點，則多是由於上游source吞吐不夠，需考慮增長source的batchsize或增長上游source的shard數。

Q:如何判斷持續反壓，反壓時如何判斷性能瓶頸點？

A:Vertex拓撲中某些節點的IN_Q持續爲100%則存在持續反壓狀況，最後一個(或多個)IN_Q爲100%的節點爲性能瓶頸點。以下示例：

上圖存在反壓,瓶頸在6號節點。

上圖存在反壓，瓶頸在2號節點。

上圖存在反壓，瓶頸在8號節點。

上圖可能存在節點，瓶頸在0號節點。

Q: 如何判斷數據傾斜？

A：(1)表象上看，某些節點不論增長多大的併發仍存在性能瓶頸，則可能存在數據傾斜。
(2)在Vertex拓撲中點擊疑似存在數據傾斜的節點（通常爲性能瓶頸節點），進入SubTask List界面，重點觀察RecvCnt和InQueue，若各ID對應的RecvCnt值差別較大（通常超過1個數量級）則認爲存在數據傾斜，若個別ID的InQueue長期爲100%，則認爲可能存在數據傾斜。
解決方案：請您參看GROUP BY 數據出現熱點、數據傾斜。

Q: 上線時指定15CU，可是上線後實際消耗僅爲10CU，什麼緣由？

A：這種問題通常發生在Vertex只有一個節點的狀況，此時因爲source上游的物理表的shard數爲1，Flink要求source的併發不能超過上游shard數，致使沒法增長併發，所以亦沒法增長到指定的CU數。
解決方案：

1. 增長上游物理表的shard數。
2. 將ID0的節點中的operator拆開，將source節點（GROUP）中的operator chainingStrategy修改成HEAD，將其從GROUP中拆解出來，而後手動配置調優。

Q: 上線時出現如左上圖的告警，或出現諸如「Cannot set chaining strategy on Union Transformation」錯誤，如何處理？

A：這是因爲做業的SQL有改動，致使DAG改變。
解決方案：經過從新獲取配置解決，開發-基本屬性-跳轉到新窗口配置-從新獲取配置信息。

原文連接