?

我要更快、更快更快?。?！

?

通過(guò)本文你可以 get 到：

1. 起因篇-為什么要做數(shù)據(jù)時(shí)效保障
2. 定義篇-數(shù)據(jù)時(shí)效保障包含哪些內(nèi)容
3. 目標(biāo)篇-時(shí)效性監(jiān)控以及保障的目標(biāo)
4. 機(jī)制篇-怎么去做數(shù)據(jù)時(shí)效監(jiān)控以及保障
5. 效果篇-上述機(jī)制幫助用戶暴露出過(guò)什么問(wèn)題
6. 現(xiàn)狀以及展望篇

1.序篇

所有的數(shù)據(jù)建設(shè)都是為了用戶更快、更方便、更放心的使用數(shù)據(jù)。

在用戶使用實(shí)時(shí)數(shù)據(jù)的過(guò)程中，最影響用戶體感的指標(biāo)有兩個(gè)：

• 數(shù)據(jù)質(zhì)量：實(shí)時(shí)數(shù)據(jù)產(chǎn)出的準(zhǔn)確性。舉個(gè)例子：實(shí)時(shí)數(shù)據(jù)在某些場(chǎng)景下不能保障端到端 exactly-once，因此實(shí)時(shí)與離線相同口徑的數(shù)據(jù)會(huì)有 diff。而 1% 和 0.01% 的 diff 給用戶的體驗(yàn)是完全不同的。
• 數(shù)據(jù)時(shí)效：實(shí)時(shí)數(shù)據(jù)產(chǎn)出的及時(shí)性。舉個(gè)例子：延遲 1min 和 延遲 1ms 的用戶體驗(yàn)也是完全不同的。

而本文主要對(duì)數(shù)據(jù)時(shí)效保障進(jìn)行解讀。

懶癌患者福利，先說(shuō)本文結(jié)論，通過(guò)以下兩個(gè)指標(biāo)就已經(jīng)能監(jiān)控和判定 90% 數(shù)據(jù)延遲、亂序問(wèn)題了。

• 「數(shù)據(jù)延遲監(jiān)控：flink 消費(fèi)上游的 lag（比如看消費(fèi) kafka lag 情況）」
• 「數(shù)據(jù)亂序監(jiān)控：Task/Operator numLateRecordsDropped^[1] 可以得到由于亂序?qū)е麓翱诘膩G數(shù)情況。」

2.起因篇-為什么要做數(shù)據(jù)時(shí)效保障

要做一個(gè)東西時(shí)，我們首要分析的就是用戶的痛點(diǎn)是什么，用戶想要什么。從以下兩個(gè)方面的分析入手。

• 業(yè)務(wù)側(cè)：首先從正向結(jié)果來(lái)看，業(yè)務(wù)側(cè)能拿到第一手準(zhǔn)確的實(shí)時(shí)數(shù)據(jù)，就能根據(jù)準(zhǔn)確，快速的數(shù)據(jù)做出業(yè)務(wù)策略調(diào)整，擴(kuò)大收益。但是正向結(jié)果是我們預(yù)期的目標(biāo)，開(kāi)發(fā)所要做的就是解決達(dá)成預(yù)期目標(biāo)過(guò)程中的各種不穩(wěn)定因素，這些不穩(wěn)定因素就是負(fù)向結(jié)果。從負(fù)向結(jié)果看，一旦出現(xiàn)數(shù)據(jù)產(chǎn)出延遲，數(shù)據(jù)不準(zhǔn)，就有可能讓業(yè)務(wù)錯(cuò)失一個(gè)熱點(diǎn)，產(chǎn)生巨大損失，兩者之間的關(guān)系如下圖；因此從保障層面出發(fā)，這就要求更低的數(shù)據(jù)延遲、更小的數(shù)據(jù)亂序（某些對(duì)于數(shù)據(jù)亂序敏感的任務(wù)，產(chǎn)出的數(shù)據(jù)質(zhì)量強(qiáng)依賴數(shù)據(jù)亂序情況）

• 數(shù)據(jù)加工鏈路側(cè)：從調(diào)研數(shù)據(jù)源階段角度出發(fā)，DE 需要確定某些原始數(shù)據(jù)的延遲和亂序情況，確定數(shù)據(jù)源可用性，從而進(jìn)行定制化的處理和優(yōu)化；從保障數(shù)據(jù)匯結(jié)果時(shí)效性出發(fā)，某些實(shí)時(shí)數(shù)據(jù)加工鏈路是很長(zhǎng)的，ods -> dwd -> dws -> ads，當(dāng)數(shù)據(jù)產(chǎn)出延遲時(shí)，DE 需要快速定位到問(wèn)題任務(wù)進(jìn)行處理，如下圖。數(shù)據(jù)加工時(shí)延越小，數(shù)據(jù)的亂序情況越小，說(shuō)明整條處理鏈路的穩(wěn)定性也越好，也就有能力提供更高的 SLA 保障；從以上角度出發(fā)，也需要我們對(duì)整個(gè)生產(chǎn)鏈路的數(shù)據(jù)延遲、亂序情況有一個(gè)全局視角的掌握。

「結(jié)論：數(shù)據(jù)時(shí)效保障就是對(duì)數(shù)據(jù)產(chǎn)出延遲、數(shù)據(jù)亂序的監(jiān)控報(bào)警能力的構(gòu)建、保障方案規(guī)范化的建設(shè)。」

3.定義篇-數(shù)據(jù)時(shí)效保障包含哪些內(nèi)容

如上節(jié)場(chǎng)景分析，實(shí)時(shí)數(shù)據(jù)時(shí)效保障可分為兩部分：

1. 數(shù)據(jù)時(shí)延監(jiān)控、報(bào)警、保障：衡量實(shí)時(shí)數(shù)據(jù)產(chǎn)出的延遲情況，設(shè)定報(bào)警閾值，超過(guò)閾值觸發(fā)報(bào)警。并且需要對(duì)數(shù)據(jù)產(chǎn)出延遲有一個(gè)全鏈路的視角，保障數(shù)據(jù)產(chǎn)出延遲在預(yù)期范圍內(nèi)；
2. 數(shù)據(jù)亂序監(jiān)控、報(bào)警、保障：亂序是實(shí)時(shí)任務(wù)處理中要關(guān)注的一個(gè)重要指標(biāo)，如果數(shù)據(jù)源亂序非常嚴(yán)重的話，會(huì)影響窗口類任務(wù)產(chǎn)出的實(shí)時(shí)數(shù)據(jù)質(zhì)量，所以我們也需要對(duì)齊進(jìn)行監(jiān)控以及保障。

?

Notes: 亂序的本質(zhì)其實(shí)就是數(shù)據(jù)的延遲。亂序是一種特殊的延遲，數(shù)據(jù)延遲導(dǎo)致的一種結(jié)果。

?

4.目標(biāo)篇-時(shí)效性監(jiān)控以及保障的目標(biāo)

• 探查：了解數(shù)據(jù)源的延遲、亂序情況。針對(duì)數(shù)據(jù)源的延遲、亂序情況可以針對(duì)性優(yōu)化。也對(duì)此能提出合理的 SLA 保障；
• 監(jiān)控：針對(duì)具體延遲、亂序嚴(yán)重程度設(shè)定報(bào)警閾值，讓開(kāi)發(fā)可以快速感知問(wèn)題；
• 定位：根據(jù)延遲、亂序報(bào)警快速定位數(shù)據(jù)延遲、亂序?qū)е碌馁|(zhì)量問(wèn)題；
• 恢復(fù)：?jiǎn)栴}解決完成之后，可以根據(jù)監(jiān)控查看到實(shí)際的效果；

5.機(jī)制篇-怎么去做數(shù)據(jù)時(shí)效監(jiān)控以及保障

接下來(lái)我們「對(duì)癥（延遲、亂序情況）下藥（監(jiān)控、報(bào)警、保障措施）」，先分析在數(shù)據(jù)生產(chǎn)、傳輸、加工的過(guò)程中哪些環(huán)節(jié)會(huì)導(dǎo)致數(shù)據(jù)的延遲以及亂序。

通過(guò)分析上述數(shù)據(jù)生產(chǎn)、傳輸、加工鏈路之后，我們可以發(fā)現(xiàn)能從「數(shù)據(jù)源、數(shù)據(jù)處理任務(wù)」兩個(gè)不同的維度去分析會(huì)導(dǎo)致延遲、亂序的原因。

「數(shù)據(jù)源延遲亂序」：屬于數(shù)據(jù)源本身的屬性，和下游消費(fèi)的任務(wù)無(wú)關(guān)。

「數(shù)據(jù)加工延遲亂序」：這是和具體的任務(wù)綁定。

其對(duì)應(yīng)關(guān)系如下。

5.1.數(shù)據(jù)時(shí)延監(jiān)控

5.1.1.整體時(shí)延

整體時(shí)延可以從以下兩個(gè)角度出發(fā)進(jìn)行計(jì)算。

• 用戶視角：只關(guān)心最終產(chǎn)出結(jié)果時(shí)延
• 開(kāi)發(fā)視角：需要關(guān)心整個(gè)鏈路處理時(shí)延

5.1.2.結(jié)果時(shí)延監(jiān)控

5.1.2.1.監(jiān)控指標(biāo)以及報(bào)警機(jī)制

從用戶體驗(yàn)角度直觀的反映出數(shù)據(jù)的整體時(shí)延情況。

• 「監(jiān)控方式」：有數(shù)據(jù)時(shí)效監(jiān)控中心提供延遲監(jiān)控 sdk。在看板的 web server 側(cè)將數(shù)據(jù)時(shí)延上報(bào)到延遲監(jiān)控 sdk 中。

• 「監(jiān)控指標(biāo)」：計(jì)算 web-server-system-current-timestamp - message-event-timestamp 計(jì)算 P99 等指標(biāo)。

• 「監(jiān)控方式優(yōu)點(diǎn)」：能從用戶體感角度出發(fā)，準(zhǔn)確的刻畫時(shí)延情況。

• 「監(jiān)控方式缺點(diǎn)」：對(duì) web server 有埋點(diǎn)侵入性。

• 「報(bào)警機(jī)制」：定時(shí)（比如 1min/次） check 監(jiān)控指標(biāo)的 P99 指標(biāo)。

• 「報(bào)警閾值」：判斷監(jiān)控指標(biāo)的 P99 指標(biāo)是否超過(guò)某個(gè)閾值（比如 5 min）。

• 「報(bào)警接收人」：報(bào)警反饋給任務(wù)鏈路負(fù)責(zé)人。

5.1.3.鏈路時(shí)延監(jiān)控

5.1.3.1.數(shù)據(jù)源時(shí)延

?

這個(gè)時(shí)延和處理任務(wù)無(wú)關(guān)，單純從指數(shù)據(jù)本身的屬性，數(shù)據(jù)本身上報(bào)就存在的時(shí)延。

?

舉例：從用戶發(fā)生消費(fèi)事件一直到日志進(jìn)入數(shù)據(jù)源存儲(chǔ)引擎中（比如 kafka），這期間存在的時(shí)延。

5.1.3.1.1.監(jiān)控指標(biāo)以及報(bào)警機(jī)制

• 「監(jiān)控方式」：?jiǎn)为?dú)有一個(gè)任務(wù)消費(fèi)并處理數(shù)據(jù)源。需要保障這個(gè)任務(wù)任何時(shí)刻都不能有 lag，才能刻畫出一個(gè)準(zhǔn)確的數(shù)據(jù)源時(shí)延情況。

• 「監(jiān)控指標(biāo)」：使用 system-current-timestamp - message-event-timestamp P99 等指標(biāo)。

• 「監(jiān)控方式優(yōu)點(diǎn)」：「在數(shù)據(jù)源角度」能準(zhǔn)確的刻畫出數(shù)據(jù)源事件時(shí)間時(shí)延情況。

• 「監(jiān)控方式缺點(diǎn)」：為了監(jiān)控?cái)?shù)據(jù)源亂序情況，需要單獨(dú)啟動(dòng)一個(gè)任務(wù)耗費(fèi)資源。不建議這種方式進(jìn)行，如果要做，可以進(jìn)行采樣。而且會(huì)侵入用戶代碼，需要用戶指定時(shí)間戳。

• 「報(bào)警機(jī)制」：定時(shí)（比如 1min/次） check 監(jiān)控指標(biāo)的 P99 指標(biāo)。

• 「報(bào)警閾值」：判斷監(jiān)控指標(biāo)的 P99 指標(biāo)是否超過(guò)某個(gè)閾值（比如 5 min）。

• 「報(bào)警接收人」：報(bào)警反饋給任務(wù)鏈路負(fù)責(zé)人。

上面這種方式是站在數(shù)據(jù)源視角去精準(zhǔn)的衡量出數(shù)據(jù)延遲情況的，但是很多時(shí)候我們只需要在下游任務(wù)視角去做這件事會(huì)更方便。比如：

• 「監(jiān)控方式」：在下游任務(wù)處處理數(shù)據(jù)源時(shí)記錄數(shù)據(jù)延遲情況。

• 「監(jiān)控指標(biāo)」：使用任務(wù)本地 system-current-timestamp - message-event-timestamp P99 等指標(biāo)。

• 「監(jiān)控方式優(yōu)點(diǎn)」：節(jié)約資源。

• 「監(jiān)控方式缺點(diǎn)」：一旦下游任務(wù)消費(fèi)有延遲，我們就不能準(zhǔn)確的衡量出數(shù)據(jù)源的延遲情況了。而且會(huì)侵入用戶代碼，需要用戶指定時(shí)間戳。

• 「報(bào)警機(jī)制」：定時(shí)（比如 1min/次） check 監(jiān)控指標(biāo)的 P99 指標(biāo)。

• 「報(bào)警閾值」：判斷監(jiān)控指標(biāo)的 P99 指標(biāo)是否超過(guò)某個(gè)閾值（比如 180s）。

• 「報(bào)警接收人」：報(bào)警反饋給任務(wù)鏈路負(fù)責(zé)人。

?

Notes：這里衍生出一個(gè)問(wèn)題，客戶端日志數(shù)據(jù)一般會(huì)有以下兩種時(shí)間戳：

1. 客戶端時(shí)間戳：用戶在客戶端操作時(shí)的時(shí)間戳
2. 服務(wù)端時(shí)間戳：客戶端日志上報(bào)到服務(wù)端時(shí)，日志 server 打上的本地時(shí)間戳

因?yàn)榭蛻舳说能浖姹?、網(wǎng)絡(luò)環(huán)境、機(jī)型、地區(qū)的不同，會(huì)導(dǎo)致上報(bào)的日志「客戶端時(shí)間戳」（用戶操作時(shí)間戳）的準(zhǔn)確性參差不齊（你可能會(huì)發(fā)現(xiàn)有歷史、未來(lái)的時(shí)間戳）。因此事件時(shí)間都采用服務(wù)端時(shí)間戳（日志上報(bào)到服務(wù)端時(shí)，服務(wù)端的本地時(shí)間戳）來(lái)避免這種問(wèn)題。

當(dāng)我們采用服務(wù)端時(shí)間戳?xí)r，就基本會(huì)發(fā)現(xiàn)數(shù)據(jù)源的時(shí)延幾乎為 0，因?yàn)閿?shù)據(jù)處理鏈路和日志 server 都是 server 端，因此其之間的數(shù)據(jù)時(shí)延是非常小的，幾乎可以忽略不計(jì)。

?

5.1.3.2.數(shù)據(jù)加工時(shí)延

用于衡量實(shí)時(shí)任務(wù)處理鏈路的時(shí)延。定位鏈路瓶頸問(wèn)題。

5.1.3.2.1.監(jiān)控指標(biāo)以及報(bào)警機(jī)制

第一個(gè)就是 flink 消費(fèi)數(shù)據(jù)源的延遲。比如 flink 任務(wù)性能不足，產(chǎn)生反壓就會(huì)有大量 lag。

• 「監(jiān)控方式」：在下游任務(wù)處處理數(shù)據(jù)源時(shí)記錄數(shù)據(jù)延遲情況。

• 「監(jiān)控指標(biāo)」：使用任務(wù)本地 system-current-timestamp - kafka-timestamp P99 等指標(biāo)。

• 「監(jiān)控方式優(yōu)點(diǎn)」：不侵入用戶代碼。

• 「監(jiān)控方式缺點(diǎn)」：可以衡量出任務(wù)消費(fèi)時(shí)延情況。

• 「報(bào)警機(jī)制」：定時(shí)（比如 1min/次） check 監(jiān)控指標(biāo)的 P99 指標(biāo)。

• 「報(bào)警閾值」：判斷監(jiān)控指標(biāo)的 P99 指標(biāo)是否超過(guò)某個(gè)閾值（常用 180s）。

• 「報(bào)警接收人」：報(bào)警反饋給任務(wù)鏈路負(fù)責(zé)人。

第二部分就是 flink 整個(gè)處理過(guò)程中的延遲情況。

• 「監(jiān)控方式」：flink 本身自帶有 latency marker 機(jī)制（詳見(jiàn) flink latency marker）。
• 「監(jiān)控指標(biāo)」：flink latency marker 官方文檔。
• 「監(jiān)控方式優(yōu)點(diǎn)」：「在下游消費(fèi)任務(wù)的角度」準(zhǔn)確的刻畫出整個(gè) flink 任務(wù)加工時(shí)延。
• 「監(jiān)控方式缺點(diǎn)」：這個(gè)機(jī)制會(huì)有性能損耗，官方建議只在測(cè)試階段進(jìn)行使用。這其實(shí)已經(jīng)足夠，因?yàn)槲覀冊(cè)跍y(cè)試階段就可以基本測(cè)試出，flink 任務(wù)處理計(jì)算的耗時(shí)情況。

5.2.數(shù)據(jù)亂序監(jiān)控

數(shù)據(jù)亂序監(jiān)控主要是用來(lái)監(jiān)控?cái)?shù)據(jù)源、處理任務(wù)過(guò)程中操作的亂序?qū)Ξa(chǎn)出數(shù)據(jù)的影響。

5.2.1.數(shù)據(jù)源亂序

指數(shù)據(jù)本身就存在的亂序，比如客戶端網(wǎng)絡(luò)上報(bào)存在的亂序，有的用戶在偏遠(yuǎn)網(wǎng)絡(luò)較差的地區(qū)，所以上報(bào)可能就會(huì)比很多用戶延遲很多，這就造成了數(shù)據(jù)的亂序。

5.2.1.1.監(jiān)控指標(biāo)以及報(bào)警機(jī)制

• 「監(jiān)控方式」：?jiǎn)为?dú)有一個(gè)任務(wù)消費(fèi)并處理數(shù)據(jù)源。需要保障這個(gè)任務(wù)任何時(shí)刻都不能有 lag，才能刻畫出一個(gè)準(zhǔn)確的數(shù)據(jù)源時(shí)延情況。

• 「監(jiān)控指標(biāo)」：具體衡量亂序的指標(biāo)類似于 watermark 分配方式。即為每一個(gè) source consumer 維護(hù)一個(gè) max(timestamp)，記為 max_ts，后續(xù)來(lái)的數(shù)據(jù)的時(shí)間戳記為 cur_tx，如果 cur_tx > max_ts，則說(shuō)明沒(méi)有亂序，設(shè)置 max_tx = cur_ts，如果出現(xiàn) cur_ts < max_ts，則說(shuō)明這條數(shù)據(jù)發(fā)生了亂序，計(jì)算出 abs(cur_ts - max_ts) 為具體亂序時(shí)長(zhǎng)，最終計(jì)算亂序時(shí)長(zhǎng)的 P99 等值。

• 「監(jiān)控方式優(yōu)點(diǎn)」：「在數(shù)據(jù)源角度」能準(zhǔn)確的刻畫出數(shù)據(jù)源事件時(shí)間亂序情況。

• 「監(jiān)控方式缺點(diǎn)」：為了監(jiān)控?cái)?shù)據(jù)源亂序情況，需要單獨(dú)啟動(dòng)一個(gè)任務(wù)耗費(fèi)資源。不建議這種方式進(jìn)行，如果要做，可以進(jìn)行采樣。

• 「報(bào)警機(jī)制」：定時(shí)（比如 1min/次） check 監(jiān)控指標(biāo)的 P99 指標(biāo)。

• 「報(bào)警閾值」：判斷監(jiān)控指標(biāo)的 P99 指標(biāo)是否超過(guò)某個(gè)閾值（常用 180s）。

• 「報(bào)警接收人」：報(bào)警反饋給任務(wù)負(fù)責(zé)人。

上面這種方式是站在「數(shù)據(jù)源視」角去精準(zhǔn)的衡量出數(shù)據(jù)亂序情況的，但是很多時(shí)候我們只需要在「下游任務(wù)視角」去做這件事會(huì)更方便。比如：

• 「監(jiān)控方式」：在下游任務(wù)處處理數(shù)據(jù)源時(shí)記錄數(shù)據(jù)亂序情況。
• 「監(jiān)控指標(biāo)」：衡量指標(biāo)同上。

?

Notes：雖然數(shù)據(jù)源可能有亂序，但是這個(gè)亂序經(jīng)過(guò) flink 的一些策略處理后，亂序?qū)τ?jì)算數(shù)據(jù)的影響就會(huì)被消除。比如用戶設(shè)置 watermark 時(shí)調(diào)大 max-out-of-orderness 以及設(shè)置 allow-lateness 的處理之后就會(huì)解決。

?

5.2.2.數(shù)據(jù)加工亂序

單個(gè)任務(wù)消費(fèi)上游數(shù)據(jù)后，內(nèi)部做一些 rebalance shuffle 操作導(dǎo)致或者加劇數(shù)據(jù)亂序的情況。從而會(huì)導(dǎo)致一些開(kāi)窗類的任務(wù)出現(xiàn)丟數(shù)的情況，導(dǎo)致最后數(shù)據(jù)計(jì)算出現(xiàn)誤差。

舉例：

DataStream<Model> eventTimeResult = SourceFactory
        .getSourceDataStream(xxx)
        .uid("source")
        .rebalance() // 這里 rebalance 之后會(huì)加劇數(shù)據(jù)亂序，從而可能會(huì)導(dǎo)致后續(xù)事件時(shí)間窗口丟數(shù)
        .flatMap(xxx)
        .assignTimestampsAndWatermarks(new BoundedOutOfOrdernessTimestampExtractor<Model>(Time.minutes(1L)) {
            @Override
            public long extractTimestamp(Model model) {
                return model.getServerTimestamp();
            }
        })
        .keyBy(KeySelectorFactory.getRemainderKeySelector(xxx))
        .timeWindow(Time.seconds(xxx))
        .process(xxx)
        .uid("process-event-time");

5.2.2.1.監(jiān)控指標(biāo)以及報(bào)警機(jī)制

• 「監(jiān)控方式」：我們關(guān)心的是亂序最終導(dǎo)致的丟數(shù)情況，所以監(jiān)控丟數(shù)條目數(shù)即可。

• 「監(jiān)控指標(biāo)」：Task/Operator numLateRecordsDropped^[2] 可以得到由于亂序?qū)е麓翱诘膩G數(shù)情況。

• 「監(jiān)控方式優(yōu)點(diǎn)」：flink 自帶此指標(biāo)。

• 「報(bào)警機(jī)制」：定時(shí)（比如 1min/次） check 監(jiān)控指標(biāo)的條目數(shù)。

• 「報(bào)警閾值」：判斷監(jiān)控指標(biāo)的條目數(shù)是否超過(guò)某個(gè)閾值（比如 5w 條）。

• 「報(bào)警接收人」：報(bào)警反饋給任務(wù)負(fù)責(zé)人。

6.效果篇-上述機(jī)制幫助用戶暴露出過(guò)什么問(wèn)題

6.1.數(shù)據(jù)源探查階段

在數(shù)據(jù)源探查階段，通過(guò)快速啟動(dòng)數(shù)據(jù)源消費(fèi)任務(wù)去探查數(shù)據(jù)源的延遲、亂序程度，確定數(shù)據(jù)源的可用性。比如發(fā)現(xiàn)數(shù)據(jù)源延遲常年在 5min 以上，那么我們向用戶所能保障的數(shù)據(jù)時(shí)延也不會(huì)小于 5min。

6.2.暴露延遲、亂序問(wèn)題

「通過(guò)我們的實(shí)踐測(cè)試之后，我們發(fā)現(xiàn)報(bào)警和問(wèn)題原因是符合 2-8 定律的，甚至比例達(dá)到了 2 - 9。即 90% 的問(wèn)題都可以由 20% 的報(bào)警發(fā)現(xiàn)。」

6.2.1.90% 的時(shí)延問(wèn)題是由于 flink 任務(wù)性能不足導(dǎo)致

• 報(bào)警項(xiàng)：flink 消費(fèi) kafka lag 延遲超過(guò) 180s
• 其他監(jiān)控項(xiàng)輔助定位：flink 任務(wù) cpu 使用率超過(guò) 100%；flink 任務(wù) ygc 每分鐘超過(guò) 20s

6.2.2.10% 的時(shí)延問(wèn)題是由于數(shù)據(jù)源延遲導(dǎo)致

• 報(bào)警項(xiàng)：flink 消費(fèi) kafka lag 延遲超過(guò) 180s；數(shù)據(jù)源時(shí)延超過(guò) 180s
• 其他監(jiān)控項(xiàng)輔助定位：flink 任務(wù) cpu 使用率正常，每分鐘 ygc 時(shí)長(zhǎng)正常

6.2.3.90% 的亂序問(wèn)題是由于數(shù)據(jù)源亂序?qū)е?/span>

• 報(bào)警項(xiàng)：flink 任務(wù)窗口算子丟數(shù)超過(guò) xx 條；數(shù)據(jù)源亂序 P99 超過(guò) 180s（指 99% 的數(shù)據(jù)亂序情況不超過(guò) 180s）

6.2.4.10% 的亂序問(wèn)題是由于 flink 任務(wù)加工亂序?qū)е?/span>

• 報(bào)警項(xiàng)：flink 任務(wù)窗口算子丟數(shù)超過(guò) xx 條
• 他監(jiān)控項(xiàng)輔助定位：數(shù)據(jù)源亂序 P99 處于合理范圍；并且代碼中有 rebalance 操作之后分配 watermark

6.3.確定延遲、亂序問(wèn)題恢復(fù)情況

當(dāng)我們修復(fù)數(shù)據(jù)延遲、亂序問(wèn)題之后，我們也需要觀察任務(wù)的回復(fù)情況。上述監(jiān)控也可以幫助觀察問(wèn)題的恢復(fù)情況。比如：延遲、亂序時(shí)長(zhǎng)變小就說(shuō)明用戶的修復(fù)是有效的。

7.現(xiàn)狀以及展望篇

7.1.現(xiàn)狀

其實(shí)目前很多公司有 「flink 消費(fèi) kafka lag 時(shí)延」，「Task/Operator numLateRecordsDropped」 就已經(jīng)足夠用了。全方位建設(shè)上述整個(gè)時(shí)延監(jiān)控的成本還是很高的。

7.2.展望

7.2.1.實(shí)時(shí)數(shù)據(jù)、任務(wù)血緣 + 時(shí)效性全景圖

• 需求：數(shù)倉(cāng)的上下游鏈路是很長(zhǎng)的，如果想更快快速定位整個(gè)數(shù)據(jù)鏈路中的時(shí)效性問(wèn)題，就需要一個(gè)可視化整體鏈路時(shí)延全局圖。
• 基礎(chǔ)能力：需要實(shí)時(shí)數(shù)據(jù)、任務(wù)血緣（目前想要做到這一點(diǎn)，都已經(jīng)比較難了，很多大廠的機(jī)制都不完善，甚至說(shuō)沒(méi)有）

舉例：從最終產(chǎn)出的一個(gè) ads 層指標(biāo)出發(fā)，逆推血緣，并展示出時(shí)效情況。

7.2.2.實(shí)時(shí)時(shí)效性基線

7.2.2.1.基線

并且將時(shí)延超過(guò)閾值的鏈路使用醒目的顏色標(biāo)注

• 需求：不同的指標(biāo)有不同的產(chǎn)出時(shí)延標(biāo)準(zhǔn)，有了 6.2.1 的基礎(chǔ)能力之后，我們就可以根據(jù)具體時(shí)延要求設(shè)置時(shí)效性基線。比如設(shè)置最終指標(biāo)產(chǎn)出時(shí)延不能超過(guò) 180s。那么基線就是 180s。只要整個(gè)鏈路的產(chǎn)出時(shí)延超過(guò) 180s 就報(bào)警。也可以對(duì)某一層的加工鏈路設(shè)置基線。

舉例：從最終產(chǎn)出的一個(gè) ads 層指標(biāo)出發(fā)，設(shè)置基線 180s，那么下圖的任務(wù)就可以根據(jù)基線設(shè)定的任務(wù)，逆推計(jì)算出鏈路中時(shí)延過(guò)長(zhǎng)的任務(wù)，直接報(bào)警。