背景:?
最近flink發(fā)布新版本1.11, 除了優(yōu)化舊版本已有的缺陷, 還增加了一些新功能,? 其中我發(fā)現(xiàn)有一些改變適合用于現(xiàn)在負(fù)責(zé)的flink項(xiàng)目?
我們當(dāng)前的flink項(xiàng)目的問題是生成checkpoint失敗較多,造成checkpoint失敗的原因是某幾個(gè)subtask的快照超時(shí)導(dǎo)致整體的checkpoint生成失敗,隨著每天的處理的任務(wù)越多, 這個(gè)問題越發(fā)突顯出來, 而后果是:
引用的答案:
目前的 Checkpoint 算法在大多數(shù)情況下運(yùn)行良好，然而當(dāng)作業(yè)出現(xiàn)反壓時(shí)，阻塞式的 Barrier 對(duì)齊反而會(huì)加劇作業(yè)的反壓，甚至導(dǎo)致作業(yè)的不穩(wěn)定。首先， Chandy-Lamport 分布式快照的結(jié)束依賴于 Marker 的流動(dòng)，而反壓則會(huì)限制 Marker 的流動(dòng)，導(dǎo)致快照的完成時(shí)間變長(zhǎng)甚至超時(shí)。無論是哪種情況，都會(huì)導(dǎo)致 Checkpoint 的時(shí)間點(diǎn)落后于實(shí)際數(shù)據(jù)流較多。這時(shí)作業(yè)的計(jì)算進(jìn)度是沒有被持久化的，處于一個(gè)比較脆弱的狀態(tài)，如果作業(yè)出于異常被動(dòng)重啟或者被用戶主動(dòng)重啟，作業(yè)會(huì)回滾丟失一定的進(jìn)度。如果 Checkpoint 連續(xù)超時(shí)且沒有很好的監(jiān)控，回滾丟失的進(jìn)度可能高達(dá)一天以上，對(duì)于實(shí)時(shí)業(yè)務(wù)這通常是不可接受的。更糟糕的是，回滾后的作業(yè)落后的 Lag 更大，通常帶來更大的反壓，形成一個(gè)惡性循環(huán)。
優(yōu)化1: rebalance分區(qū)改為rescale分區(qū)
rebalance使用Round-ribon思想將數(shù)據(jù)均勻分配到各實(shí)例上。Round-ribon是負(fù)載均衡領(lǐng)域經(jīng)常使用的均勻分配的方法，上游的數(shù)據(jù)會(huì)輪詢式地分配到下游的所有的實(shí)例上。如下圖所示，上游的算子會(huì)將數(shù)據(jù)依次發(fā)送給下游所有算子實(shí)例。
dataStream.rebalance()
rescale與rebalance很像，也是將數(shù)據(jù)均勻分布到各下游各實(shí)例上，但它的傳輸開銷更小，因?yàn)閞escale并不是將每個(gè)數(shù)據(jù)輪詢地發(fā)送給下游每個(gè)實(shí)例，而是就近發(fā)送給下游實(shí)例。
dataStream.rescale()
如上圖所示，當(dāng)上游有兩個(gè)實(shí)例時(shí)，上游第一個(gè)實(shí)例將數(shù)據(jù)發(fā)送給下游第一個(gè)和第二個(gè)實(shí)例，上游第二個(gè)實(shí)例將數(shù)據(jù)發(fā)送給下游第三個(gè)和第四個(gè)實(shí)例，相比rebalance將數(shù)據(jù)發(fā)送給下游每個(gè)實(shí)例，rescale的傳輸開銷更小。下圖則展示了當(dāng)上游有四個(gè)實(shí)例，上游前兩個(gè)實(shí)例將數(shù)據(jù)發(fā)送給下游第一個(gè)實(shí)例，上游后兩個(gè)實(shí)例將數(shù)據(jù)發(fā)送給下游第二個(gè)實(shí)例。
優(yōu)化2: 升級(jí)flink1.11, 使用Unaligned Checkpoint + rocksdb生成Checkpoint
flink1.11新特性相關(guān)介紹:?https://www.h5w3.com/33867.html
Rocksdb state ssd:? 使用rocksdb緩存checkpoint, 并且從原來的全量生成改為增量生成的方式, 速度更快
Unaligned Checkpoint
Flink 現(xiàn)有的 Checkpoint 機(jī)制下，每個(gè)算子需要等到收到所有上游發(fā)送的 Barrier 對(duì)齊后才可以進(jìn)行 Snapshot 并繼續(xù)向后發(fā)送 barrier。在反壓的情況下，Barrier 從上游算子傳送到下游可能需要很長(zhǎng)的時(shí)間，從而導(dǎo)致 Checkpoint 超時(shí)的問題。
針對(duì)這一問題，F(xiàn)link 1.11 增加了 Unaligned Checkpoint 機(jī)制。開啟 Unaligned Checkpoint 后當(dāng)收到第一個(gè) barrier 時(shí)就可以執(zhí)行 checkpoint，并把上下游之間正在傳輸?shù)臄?shù)據(jù)也作為狀態(tài)保存到快照中，這樣 checkpoint 的完成時(shí)間大大縮短，不再依賴于算子的處理能力，解決了反壓場(chǎng)景下 checkpoint 長(zhǎng)期做不出來的問題。
可以通過 env.getCheckpointConfig().enableUnalignedCheckpoints();開啟unaligned Checkpoint 機(jī)制。
總的來說, 新特性一定程度解決了Checkpoint與反壓的耦合
分析過程:?
首先測(cè)查算子間是否存在反壓, 在flink web ui后臺(tái)可以查看:
我的flink作業(yè)沒有反壓的問題
定位問題的原因是:?部分幾個(gè)subtask處理速度跟不上, 導(dǎo)致barrier流向慢, input緩沖區(qū)占滿, barrier對(duì)齊不了, 導(dǎo)致整體的checkpoint生成失敗
flink作業(yè)operator處理數(shù)據(jù)的效率不均的原因主要是:
數(shù)據(jù)的多樣性: 不同數(shù)據(jù)的類型或大小不一致, 導(dǎo)致處理的時(shí)間不一致,
如果使用了rebalance分區(qū)策略, 還是會(huì)負(fù)載均衡地分配到每個(gè)subtask上, 本來負(fù)載高的subtask還是會(huì)發(fā)配到任務(wù)處理, 導(dǎo)致了惡性循環(huán)
Flink 現(xiàn)有的物理分區(qū)策略全是靜態(tài)的負(fù)載均衡策略，沒有動(dòng)態(tài)根據(jù)負(fù)載能力進(jìn)行負(fù)載均衡的策略
未升級(jí)之前:?
網(wǎng)上看到一篇分析得很好的文章, 恰好就是現(xiàn)在內(nèi)容引入出現(xiàn)的問題:?Flink 中的木桶效應(yīng)：?jiǎn)蝹€(gè) subtask 卡死導(dǎo)致整個(gè)任務(wù)卡死? 建議大家看一看`~
引用如下:?
代碼實(shí)現(xiàn):? 略過, 可以參考官方文檔
優(yōu)化后的效果:
參考文獻(xiàn):
Flink 1.11 Unaligned Checkpoint 解析
Flink 中的木桶效應(yīng)：?jiǎn)蝹€(gè) subtask 卡死導(dǎo)致整個(gè)任務(wù)卡死
flink消費(fèi)kafka時(shí)出現(xiàn)數(shù)據(jù)傾斜的原因和處理方式
