任務運維和資料指標相關知多少？

一、實時開發常見問題

1、一個實時計算任務該分配多少資源？

建議：一些簡單ETL任務，並且源資料流量在一定範圍內， tm個數1、全域性並行度1、記憶體1G。

分析：

    全域性並行度為1，對於簡單ETL任務會有operator chain，在一個task(執行緒)中執行、減少執行緒切換、減少訊息序列化/反序列化等，該類問題的瓶頸一般在下游寫入端。
    寫入端是瓶頸：一般建議開啟批次寫入(需要控制批次大小，防止記憶體溢位)、開啟多並行度寫入。
    如果是單臺資料庫的瓶頸：開啟多個並行度就沒法提升效能、一般建議按照一定路由規則寫入多臺資料庫、建議使用分散式資料庫(如Hbase：提前建立分割槽、避免資料熱點寫入等)。

 

2、為什麼寫入Kafka結果中有些分割槽沒有資料？

建議：如果現有topic已經存在，並且是多個分割槽，結果表並行度設定partition數一樣。
分析：

    由於Flink寫Kafka預設採用的是FixedPartitioner。如果並行度比partition大，則資料都會傳送到partition中，但是如果並行度比partition小，則有部分分割槽是沒有資料的。
    source端，如果並行度小於partition，會取模的方式分給並行度，都會消費到資料。如果並行度大於partition，則會有部分task消費不到資料。

 

3、為什麼和維表關聯後任務處理資料的能力變慢？

建議：小資料量不常更新的維表使用ALL模式。大資料量的維表使用使用LRU模式，並且根據資料庫不同做相應的處理(比如關係型資料庫則建立索引等)。

分析：1.ALL模式啟動時候直接將資料全量載入到記憶體中，每次關聯資料不需要查庫，沒有其他開銷。2.非同步(async)查詢模式

    LRU非同步查詢資料庫，可以併發地處理多個請求。
    根據SQL中的關聯欄位順序建立複合索引。
    防止關聯欄位索引失效(關聯順序不對、關聯列做計算等)。
    如果維表欄位個數少，考慮將將多餘欄位都加入到索引中，減少回表(帶來的問題是索引變大)。

 

4、為什麼某些任務提高並行度能提升效能，某些不能？

建議：檢視是否資料傾斜，如果是將資料打散。

分析：

    源頭是否資料傾斜。
    SQL中是否存在導致傾斜的語句。
    登陸到Flink web頁面檢視。
    透過修改SQL解決或者打散groupby欄位。

 

二、實時任務運維

1、配置反壓告警

場景：反壓導致cp失敗，資料出現延遲或者不產出。

排查方法：
1）藉助Flink web-ui 提供的的反壓功能查詢具體的operatorChain。
2）查詢Flink metric 'inPoolUsage、outPoolUsage' 來確定具體的反壓運算元。

 

2、配置cp失敗告警

場景：cp失敗導致資料無法真正落地，任務恢復間隔太長。

排查方法:

1）是否存在反壓。
2）檢查叢集負載、IO、CPU、MEM 是否處於高負荷狀態。

 

3、拆分實時任務日誌

場景: Flink實時任務執行時間長之後導致日誌佔用磁碟大，另外一個大的日誌檔案不利於排查問題。

解決方法：

配置log4j.log的滾動引數，設定日誌按日期或者大小滾動生產，並且限制保留的大小。

 

4、監控任務執行中tm日誌

場景: 任務執行中產生的執行日誌沒有監控，比如網路抖動導致的連結失敗等等。

解決方法:

修改Flink自帶的log4j jar包中的程式碼，將異常日誌重定向一份到Kafka或ES中，進行後續分析，找到程式中可能存在的隱藏bug。

 

5、髒資料管理

場景：由於資料來源都是從Kafka過來的資料，可能存在資料型別錯誤、欄位名稱錯誤、欄位閾值在Flink中超範圍等。落庫過程中，由於欄位型別不匹配、閾值超範圍等等情況。

解決方法：

在資料解析和資料落庫等程式碼中，對catch中的資料進行收集。當異常資料達到一定的量時，告警通知。線下離線修正結果資料。

 

三、透過Metrics定位問題

1.常用內建Metrics介紹

端到端的延時(最大、平均、百分位)：

flink_taskmanager_job_latency_source_id_operator_id_operator_subtask_index_latency

輸入資料量：

flink_taskmanager_job_task_operator_numRecordsIn

flink_taskmanager_job_task_numBytesIn

輸出資料量：

flink_taskmanager_job_task_operator_numRecordsOut

flink_taskmanager_job_task_numBytesOut

反壓值：

flink_taskmanager_job_task_isBackPressured

任務buffer：

inPoolUsage、outPoolUsage等其他

 

2、flinkStreamSql中常用metrics

業務延遲：

flink_taskmanager_job_task_operator_dtEventDelay（單位s）

資料本身的時間和進入flink的當前時間的差值。

各個輸入源的髒資料：

flink_taskmanager_job_task_operator_dtDirtyData

從Kafka獲取的資料解析失敗視為髒資料。

各Source的資料輸入TPS：

flink_taskmanager_job_task_operator_dtNumRecordsInRate

Kafka接受的記錄數(未解析前)/s。

各Source的資料輸入RPS：

flink_taskmanager_job_task_operator_dtNumRecordsInResolveRate

Kafka接受的記錄數(未解析前)/s。

各Source的資料輸入BPS：

flink_taskmanager_job_task_operator_dtNumBytestInRate

Kafka接受的位元組數/s。

Kafka作為輸入源的各個分割槽的延遲數：

flink_taskmanager_job_task_operator_topic_partition_dtTopicPartitionLag

當前Kafka10、Kafka11有采集該指標。

各個輸入源RPS：

fink_taskmanager_job_task_operator_dtNumRecordsOutRate

寫入的外部記錄數/s。

 

四、FlinkStreamSQL v1.11.1介紹

1.DDL建表語句和FlinkStreamSql v1.10之前版本保持一致。

2.DML語句有兩種不同的模式：

dtstack模式：和之前的版本是一致的。

Flink模式：和Flink原生的語法保持一致。

3.主要區別點：和維表join方式不同。

4.如何使用：在提交任務的時候加上 -planner dtstack/flink即可。

本文作者：劉星（花名：吹雪），袋鼠雲大資料開發工程師。