學不會去當產品吧?Flink實戰任務調優

file

背景

在大數據領域我們都知道,開發是最簡單,任務的合理調優、問題排查纔是最重要的。
我們在之前的文章《Flink面試通關手冊》中也講解過,作者結合線上出現的一些問題,總結了一些任務調優需要注意的點。

一些簡單的原則

我們在之前的文章《Flink面試通關手冊》中提到過一個問題,Flink任務延遲高,想解決這個問題,你會如何入手?

當時我們給出的答案是:

在Flink的後臺任務管理中,我們可以看到Flink的哪個算子和task出現了反壓。最主要的手段是資源調優和算子調優。資源調優即是對作業中的Operator的併發數(parallelism)、CPU(core)、堆內存(heap_memory)等參數進行調優。作業參數調優包括:並行度的設置,State的設置,checkpoint的設置。

事實上,延遲最終的結果都是任務的最終失敗,我們在調優線上問題時,有一個最簡單的原則:

先看指標,定位問題?在看資源,是否足夠?三看吞吐,是否反壓?四看JVM,是否OOM?

輪着來,學不會轉產品吧

先看指標,定位問題

Flink 提供的 Metrics 可以在 Flink 內部收集一些指標,通過這些指標讓開發人員更好地理解作業或集羣的狀態。由於集羣運行後很難發現內部的實際狀況,跑得慢或快,是否異常等,開發人員無法實時查看所有的 Task 日誌,比如作業很大或者有很多作業的情況下,該如何處理?此時 Metrics 可以很好的幫助開發人員瞭解作業的當前狀況。

再看資源,是否足夠

我們通過上述的指標定位問題時,基本可以通過延遲與吞吐指標可以對任務的性能進行精準的判斷,精確的找到問題發生的代碼位置。
一般這些位置會出現以下錯誤:

  • Operator的併發數(parallelism)不合理
  • CPU(core)不合理
  • 堆內存(heap_memory)等參數設置不合理
  • 並行度的設置不合理
  • State的設置不合理
  • checkpoint的設置不合理

我們在設置這些參數時要注意:

  • 並行度(parallelism):保證足夠的並行度,並行度也不是越大越好,太多會加重數據在多個solt/task manager之間數據傳輸壓力,包括序列化和反序列化帶來的壓力。
  • CPU:CPU資源是task manager上的solt共享的,注意監控CPU的使用。
  • 內存:內存是分solt隔離使用的,注意存儲大state的時候,內存要足夠。
  • 網絡:大數據處理,flink節點之間數據傳輸會很多,服務器網卡儘量使用萬兆網卡。
三看吞吐,是否反壓

關於 Flink 的反壓問題,我們之前介紹的已經夠多了。參考《Flink網絡傳輸優化》
Flink 內部是基於 producer-consumer 模型來進行消息傳遞的,Flink的反壓設計也是基於這個模型。Flink 使用了高效有界的分佈式阻塞隊列,就像 Java 通用的阻塞隊列(BlockingQueue)一樣。下游消費者消費變慢,上游就會受到阻塞。

在實踐中,很多情況下的反壓是由於數據傾斜造成的,這點我們可以通過 Web UI 各個 SubTask 的 Records Sent 和 Record Received 來確認,另外 Checkpoint detail 裏不同 SubTask 的 State size 也是一個分析數據傾斜的有用指標。

Flink 1.11 版本中對於 Flink 反壓問題本身做了一些優化,例如使用Unaligned Checkpoint + rocksdb生成Checkpoint,使用rocksdb緩存checkpoint, 並且從原來的全量生成改爲增量生成的方式, 速度更快。

另外還需要注意的是,用戶代碼的執行效率問題(頻繁被阻塞或者性能問題)和TaskManager 的內存以及 GC 問題。

四看JVM,是否OOM?

官網給出的參數如下:

file
file
file

這裏面最重要的幾個:

taskmanager.memory.process.size: 512m
taskmanager.memory.framework.heap.size: 64m
taskmanager.memory.framework.off-heap.size: 64m
taskmanager.memory.jvm-metaspace.size: 64m
taskmanager.memory.jvm-overhead.fraction: 0.2
taskmanager.memory.jvm-overhead.min: 16m
taskmanager.memory.jvm-overhead.max: 64m
taskmanager.memory.network.fraction: 0.1
taskmanager.memory.network.min: 1mb
taskmanager.memory.network.max: 256mb

他們各自的意思,需要大家去查詢以下官方文檔。

JVM本身配置的主要參數無非以下這些:

堆設置
-Xms :初始堆大小
-Xmx :最大堆大小
-XX:NewSize=n :設置年輕代大小
-XX:NewRatio=n: 設置年輕代和年老代的比值。如:爲3,表示年輕代與年老代比值爲1:3,年輕代佔整個年輕代年老代和的1/4
-XX:SurvivorRatio=n :年輕代中Eden區與兩個Survivor區的比值。注意Survivor區有兩個。如:3,表示Eden:Survivor=3:2,一個Survivor區佔整個年輕代的1/5
-XX:MaxPermSize=n :設置持久代大小
收集器設置
-XX:+UseSerialGC :設置串行收集器
-XX:+UseParallelGC :設置並行收集器
-XX:+UseParalledlOldGC :設置並行年老代收集器
-XX:+UseConcMarkSweepGC :設置併發收集器
垃圾回收統計信息
-XX:+PrintHeapAtGC GC的heap詳情
-XX:+PrintGCDetails  GC詳情
-XX:+PrintGCTimeStamps  打印GC時間信息
-XX:+PrintTenuringDistribution    打印年齡信息等
-XX:+HandlePromotionFailure   老年代分配擔保(true  or false)
並行收集器設置
-XX:ParallelGCThreads=n :設置並行收集器收集時使用的CPU數。並行收集線程數。
-XX:MaxGCPauseMillis=n :設置並行收集最大暫停時間
-XX:GCTimeRatio=n :設置垃圾回收時間佔程序運行時間的百分比。公式爲1/(1+n)
併發收集器設置
-XX:+CMSIncrementalMode :設置爲增量模式。適用於單CPU情況。
-XX:ParallelGCThreads=n :設置併發收集器年輕代收集方式爲並行收集時,使用的CPU數。並行收集線程數

我們可以利用一些簡單的JVM日誌分析工具看出JVM設置的參數問題出在哪裏。

總結

整體來看,Flink 的調優基本是以上的大原則,具體需要根據實際問題進行調節。另外小編不建議大家使用Scala,問題難排查,維護成本高。不要圖方便。

歡迎關注,《大數據成神之路》系列文章

歡迎關注,《大數據成神之路》系列文章

歡迎關注,《大數據成神之路》系列文章

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章