實時計算Flink效能調優

自動配置調優

實時計算 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的併發可以配置為16、8、4等。不能超過16。
  • 中間節點
    
    根據預估的QPS計算。對於資料量較小的任務，設定和source相同的併發度。QPS高的任務，可以配置更大的併發數，例如64、128、或者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改變。

解決方案：通過重新獲取配置解決，開發-基本屬性-跳轉到新視窗配置-重新獲取配置資訊。