实时计算 Flink性能调优
為什么80%的碼農都做不了架構師？>>> ??
摘要： 實時計算 Flink新增自動調優功能autoconf。能夠在流作業以及上下游性能達到穩定的前提下，根據您作業的歷史運行狀況，重新分配各算子資源和并發數，達到優化作業的目的。更多詳細說明請您參閱自動配置調優。
自動配置調優
實時計算 Flink新增自動調優功能autoconf。能夠在流作業以及上下游性能達到穩定的前提下，根據您作業的歷史運行狀況，重新分配各算子資源和并發數，達到優化作業的目的。更多詳細說明請您參閱自動配置調優。
首次智能調優
上線作業。選擇智能推薦配置，指定使用CU數為系統默認，不填即可。點擊下一步。
數據檢查，預估消耗CU數。
在運維界面啟動作業，根據實際業務需要指定讀取數據時間。
說明:實時計算作業啟動時候需要您指定啟動時間。實際上就是從源頭數據存儲的指定時間點開始讀取數據。指定讀取數據時間需要在作業啟動之前。例如，設置啟動時間為1小時之前。
待作業穩定運行10分鐘后，且以下狀態符合要求，即可開始下一次性能調優。
- 運行信息拓撲圖中IN_Q不為100%。
- 數據輸入RPS符合預期。
非首次性能調優
停止>下線作業。
重新上線作業。選擇智能推薦配置，指定使用CU數為系統默認，不填即可。點擊下一步。
數據檢查，再次預估消耗CU數。
在運維界面啟動作業，待作業穩定運行十分鐘后，即可再一次性能調優。
說明：
- 自動配置調優一般需要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不足。步驟如下。
運維界面中，點擊TaskExecutor，找到性能瓶頸節點ID，點擊查看詳情。
選擇Metrics Graph，根據曲線圖判斷CPU或者MEM是否配置不足（很多情況下兩者同時不足）。
調整資源配置
完成了性能瓶頸因素判斷后，點擊開發>基本屬性>跳轉到新窗口配置，開始調整資源配置。
批量修改Operator
點擊GROUP框，進入批量修改Operator數據窗口。
說明：
配置修改完成后點擊應用當前配置并關閉窗口。
單個修改Operator
點擊Operator框，進入修改Operator數據窗口。
配置修改完成后點擊應用當前配置并關閉窗口。
參數調整說明
您只需調整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。
- source節點
- 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策略，根據實際需要修改。
作業參數調優
在開發頁面的右側選擇作業參數。
輸入調優語句。
| 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參數內設置相應的參數，達到調優上下游存儲性能的目的。
調優步驟：
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。 |
注意：?添加、修改或者刪除以上參數后，作業必須停止-啟動后，調優才能生效。
手動配置調優流程
說明：完成資源、作業參數、上下游參數調優后，手動配置調優后續的步驟與自動配置調優基本一致。區別在于資源配置環節需要選擇使用上次資源配置。
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數。
解決方案：
Q: 上線時出現如左上圖的告警，或出現諸如“Cannot set chaining strategy on Union Transformation”錯誤，如何處理？
A：這是由于作業的SQL有改動，導致DAG改變。
解決方案：通過重新獲取配置解決，開發-基本屬性-跳轉到新窗口配置-重新獲取配置信息。
雙十一廣告：阿里云雙十一1折拼團活動:已滿6人,都是最低折扣了
【滿6人】1核2G云服務器99.5元一年298.5元三年 2核4G云服務器545元一年 1227元三年
【滿6人】1核1G MySQL數據庫 119.5元一年
【滿6人】3000條國內短信包 60元每6月
參團地址：http://click.aliyun.com/m/1000020293/
作者： 付帥
原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。
轉載于:https://my.oschina.net/yunqi/blog/2870326
總結
以上是生活随笔為你收集整理的实时计算 Flink性能调优的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 兄弟连区块链教程Fabric1.0源代码
- 下一篇： f5会话保持