Flink的常見問題診斷思路是什么

Flink的常見問題診斷思路是什么，針對這個問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

創(chuàng)新互聯(lián)建站從2013年開始，先為云霄等服務(wù)建站，云霄等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為云霄企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

1.1 作業(yè)運(yùn)行環(huán)境

文中介紹的作業(yè)運(yùn)行環(huán)境主要是在阿里巴巴集團(tuán)內(nèi)，構(gòu)建在 Hadoop 生態(tài)之上的 Flink 集群，包含 Yarn、HDFS、ZK 等組件；作業(yè)提交模式采用 yarn per-job Detached 模式。

• 第1步，作業(yè)提交是通過 Flink Yarn Client，將用戶所寫的作業(yè)代碼以及編譯好的 jar 包上傳到 HDFS 上；

• 第2步 Flink Client 與 Yarn ResourceManager 進(jìn)行通信，申請所需要的的 Container 資源；

• 第3步，ResourceManager 收到請求后會在集群中的 NodeManager 分配啟動 AppMaster 的 Container 進(jìn)程，AppMaster 中包含 Flink JobManager 模塊和 Yarn 通信的 ResourceManager 模塊；

• 第4步，在 JobManager 中根據(jù)作業(yè)的 JobGraph 生成 Execution Graph，ResourceManager 模塊向 Yarn 的 ResourceManager 通信，申請 TaskManager 需要的 container 資源，這些 container 由 Yarn 的 NodeManger 負(fù)責(zé)拉起。每個 NodeManager 從 HDFS 上下載資源，啟動 Container(TaskManager)，并向 JobManager 注冊；JobManger 會部署不同的 task 任務(wù)到各個 TaskManager 中執(zhí)行。

■ 資源申請方式

1. 指定資源大小
   提交時，指定每個 TaskManager、JobManager 使用多少內(nèi)存，CPU 資源。

2. 細(xì)粒度資源控制
   阿里巴巴集團(tuán)內(nèi)主要采用 ResourceSpec 方式指定每個 Operator 所需的資源大小，依據(jù) task 的并發(fā)聚合成 container 資源向 Yarn 申請。

■  環(huán)境高可用

1. JM 高可用，AppMaster(JobManager) 異常后，可以通過 Yarn 的 APP attempt 與 ZooKeeper 機(jī)制來保證高可用；

2. 數(shù)據(jù)高可用，作業(yè)做 checkpoint 時，TaskManager 優(yōu)先寫本地磁盤，同時異步寫到 HDFS；當(dāng)作業(yè)再次啟動時可以從 HDFS 上恢復(fù)到上次 checkpoint 的點(diǎn)位繼續(xù)作業(yè)流程。

1.2 為什么我的作業(yè)延時了？

■ 時間類型

• Processing time
  Processing time 是指 task 處理數(shù)據(jù)時所在機(jī)器的系統(tǒng)時間

• Event time
  Event time 是指數(shù)據(jù)當(dāng)中某一數(shù)據(jù)列的時間

• Ingestion time
  Ingestion time 是指在 flink source 節(jié)點(diǎn)收到這條數(shù)據(jù)時的系統(tǒng)系統(tǒng)時間

■ 延時定義

自定義 Source 源解析中加入 Gauge 類型指標(biāo)埋點(diǎn)，匯報如下指標(biāo)：

1. 記錄最新的一條數(shù)據(jù)中的 event time，在匯報指標(biāo)時使用當(dāng)前系統(tǒng)時間 - event time。

2. 記錄讀取到數(shù)據(jù)的系統(tǒng)時間-數(shù)據(jù)中的 event time，直接匯報差值。

delay = 當(dāng)前系統(tǒng)時間 – 數(shù)據(jù)事件時間(event time) 

說明：反應(yīng)處理數(shù)據(jù)的進(jìn)度情況。

fetch_delay = 讀取到數(shù)據(jù)的系統(tǒng)時間- 數(shù)據(jù)事件時間(event time)

說明：反應(yīng)實(shí)時計算的實(shí)際處理能力。

■ 延時分析

• 從上游源頭，查看每個源頭并發(fā)情況

• 是否上游數(shù)據(jù)稀疏導(dǎo)致

• 作業(yè)性能問題

1.3 為什么我的作業(yè) failover 了？

■ 作業(yè) failover 主要分為兩大類

Flink Failover 主要有兩類，一類是 Job Manager的 Failover，還有一類是 Task Manager的 Failover。

1.4 作業(yè)無法提交、異常停止

■ 無法提交

• Yarn 問題 – 資源限制

• HDFS 問題 - Jar 包過大，HDFS 異常

• JobManager 資源不足，無法響應(yīng) TM 注冊

• TaskManager 啟動過程中異常

■ 異常停止-指標(biāo)監(jiān)控?zé)o法覆蓋

• 重啟策略配置錯誤

• 重啟次數(shù)達(dá)到上限

2.1 延時問題處理方式

• 通過 delay、fetch_delay 判斷是否上游稀疏導(dǎo)致延時或者作業(yè)性能不足導(dǎo)致延時

• 確定延時后，通過反壓分析，找到反壓節(jié)點(diǎn)

• 分析反壓節(jié)點(diǎn)指標(biāo)參數(shù)

• 通過分析 JVM 進(jìn)程或者堆棧信息

• 通過查看 TaskManager 等日志

■ 延時與吞吐

• 觀察延時與 tps 指標(biāo)之間關(guān)聯(lián)，是否由于 tps 的異常增高，導(dǎo)致作業(yè)性能不足延時

■ 反壓

• 找到反壓的源頭。

• 節(jié)點(diǎn)之間的數(shù)據(jù)傳輸方式 shuffle/rebalance/hash。

• 節(jié)點(diǎn)各并發(fā)的吞吐情況，反壓是不是由于數(shù)據(jù)傾斜導(dǎo)致。

• 業(yè)務(wù)邏輯，是否有正則，外部系統(tǒng)訪問等。IO/CPU 瓶頸，導(dǎo)致節(jié)點(diǎn)的性能不足。

■ 指標(biāo)

• GC 耗時多長

• 短時間內(nèi)多次 GC

• state 本地磁盤的 IO 情況

• 外部系統(tǒng)訪問延時等等

■ 堆棧

在 TaskManager 所在節(jié)點(diǎn),查看線程 TID、CPU 使用情況，確定是 CPU，還是 IO 問題。

ps H -p ${javapid} -o user,pid,ppid,tid,time,%cpu,cmd
#轉(zhuǎn)換為16進(jìn)制后查看tid具體堆棧jstack ${javapid} > jstack.log

■ 常見處理方式

1. 增加反壓節(jié)點(diǎn)的并發(fā)數(shù)。

2. 調(diào)整節(jié)點(diǎn)資源，增加 CPU，內(nèi)存。

3. 拆分節(jié)點(diǎn)，將 chain 起來的消耗資源較多的 operator 拆分。

4. 作業(yè)或集群優(yōu)化，通過主鍵打散，數(shù)據(jù)去重，數(shù)據(jù)傾斜，GC 參數(shù)，Jobmanager 參數(shù)等方式調(diào)優(yōu)。

2.2 作業(yè) failover 分析

• 查看作業(yè) failover 時打印的一些日志信息

• 查看 failover 的 Subtask 找到所在 Taskmanager 節(jié)點(diǎn)

• 結(jié)合 Job/Taskmanager 等日志信息

• 結(jié)合 Yarn 和 OS 等相關(guān)日志

3.1 作業(yè)狀態(tài)變化-JobStatus

上圖中可以看到作業(yè)的整個狀態(tài)轉(zhuǎn)換。從作業(yè)創(chuàng)建、到運(yùn)行、失敗，重啟，成功等整個生命周期。

這里需要注意的是 reconciling 的狀態(tài)，這個狀態(tài)表示 yarn 中 AppMaster 重新啟動，恢復(fù)其中的 JobManager 模塊，這個作業(yè)會從 created 進(jìn)入到 reconciling 的狀態(tài)，等待其他 Taskmanager 匯報，恢復(fù) JobManager 的 failover，然后從 reconciling 再到正常 running。

3.2 Task 狀態(tài)變化 -ExecutionState

上圖是作業(yè)的 Task 狀態(tài)轉(zhuǎn)換，需要注意的是，作業(yè)狀態(tài)處于 running 狀態(tài)時，并不意味著作業(yè)一定在運(yùn)行消費(fèi)信息。在流式計算中只有等所有的 task 都在 running 時，作業(yè)才算真正運(yùn)行。

通過記錄作業(yè)各個階段的狀態(tài)變化，形成生命周期，我們能很清楚地展示作業(yè)是什么時候開始運(yùn)行、什么時候失敗，以及 taskmanager failover 等關(guān)鍵事件，進(jìn)一步能分析出集群中有多少個作業(yè)正在運(yùn)行，形成 SLA 標(biāo)準(zhǔn)。

4.1 指標(biāo)

如何去衡量一個作業(yè)是否正常？

• 延時與吞吐
  對于 Flink 作業(yè)來說，最關(guān)鍵的指標(biāo)就是延時和吞吐。在多少 TPS 水位的情況下，作業(yè)才會開始延時.

• 外部系統(tǒng)調(diào)用
  從指標(biāo)上還可以建立對外部系統(tǒng)調(diào)用的耗時統(tǒng)計，比如說維表 join，sink 寫入到外部系統(tǒng)需要消耗多少時間，有助于我們排除外部的一些系統(tǒng)異常的一些因素。

• 基線管理
  建立指標(biāo)基線管理。比如說 state 訪問耗時，平時沒有延時的時候，state 訪問耗時是多少？每個 checkpoint 的數(shù)據(jù)量大概是多少？在異常情況下，這些都有助于我們對 Flink 的作業(yè)的問題進(jìn)行排查。

4.2 日志

• 錯誤日志
  JobManager 或者 TaskManager 的關(guān)鍵字及錯誤日志報警。

• 事件日志
  JobManager 或者 TaskManager 的狀態(tài)變化形成關(guān)鍵事件記錄。

• 歷史日志收集
  當(dāng)作業(yè)結(jié)束后，想要分析問題，需要從 Yarn 的 History Server 或已經(jīng)采集的日志系統(tǒng)中找歷史信息。

• 日志分析
  有了 JobManager，TaskManager 的日志之后，可以對常見的 failover 類型進(jìn)行聚類，標(biāo)注出一些常見的 failover，比如說 OOM 或者一些常見的上下游訪問的錯誤等等。

4.3 關(guān)聯(lián)分析

1. 作業(yè)指標(biāo)/事件 - Taskmanager，JobManager

2. Yarn 事件 - 資源搶占，NodeManager Decommission

3. 機(jī)器異常 - 宕機(jī)、替換

4. Failover 日志聚類

在做了這些指標(biāo)和日志的處理之后，可以對各組件的事件進(jìn)行關(guān)聯(lián)，比如說當(dāng) TaskManager failover 時，有可能是因?yàn)闄C(jī)器的異常。也可以通過 Flink 作業(yè)解析 Yarn 的事件，關(guān)聯(lián)作業(yè)與 Container 資源搶占，NodeManager 下線的事件等。

關(guān)于Flink的常見問題診斷思路是什么問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。

本文題目：Flink的常見問題診斷思路是什么
鏈接分享：http://muchs.cn/article2/pihjic.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、移動網(wǎng)站建設(shè)、全網(wǎng)營銷推廣、域名注冊、建站公司、網(wǎng)站導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)