基於 Flink 的實時資料消費應用 / 功能質量保障方法

Kilmer發表於2020-06-12

由於最近公司的實時資料處理引擎再向Flink遷移，所以專門設計、總結了一篇“基於Flink的實時資料消費應用/功能質量保障方法”。歡迎大家一起分享探討在大資料方面的測試方法和經驗。

什麼是Flink？

Apache Flink是由Apache軟體基金會開發的開源流處理框架，其核心是用Java和Scala編寫的分散式流資料流引擎。Flink以資料並行和流水線方式執行任意流資料程式，Flink的流水線執行時系統可以執行批處理和流處理程式。此外，Flink的執行時本身也支援迭代演算法的執行。

為什麼在實時資料處理，分析場景下要選擇Flink？

Flink 是目前唯一能同時集高吞吐、低延遲、高效能三者於一身的分散式流式資料處理框架。Apache Spark 只有高吞吐、高效能。因為Spark Stream 做不到低延遲，本質還是微批處理。Apache Storm 只有低延遲、高效能，但達不到高吞吐。

Flink的優點
- 同時支援高吞吐、低延遲、高效能；
- 支援事件事件（Event Time）概念
- 支援有狀態計算
- 支援高度靈活的視窗（Window）操作
- 基於輕量級分散式快照實現的容錯
- 基於JVM實現獨立的記憶體管理
- Save Points的實現

關於Flink的基礎介紹可以檢視連結：https://flink.apache.org/

實時資料消費應用中資料的一般流轉路徑

要保障實時資料消費應用的質量，首先需要清楚基於實時資料加工的業務鏈路是怎樣的，資料流轉路徑是怎麼樣的。

原始資料層
- 可以理解為上游原始資料，這對我們整個消費應用來說除了資料本身外其他都是黑盒，不可見的。目前我們消費應用接入的資料來源提供方式常見的有KAFKA，MQ。
資料處理層
- 整個資料流轉路徑的核心，負責根據業務需求將原始資料進行處理並轉發。處理實時資料的應用框架可以是Flink，Storm,Spark streaming等。
資料儲存層
- 加工後的資料存放的地方，業務功能可以在這裡取到需要使用的資料。一般可以為基於記憶體的key-value資料庫redis，列式資料庫ClickHouse，也可以將資料轉發至另一個資料通道中。
業務層
- 負責具體使用資料，在這裡可以對資料進行業務層面的處理。
視覺化層
- 負責展示資料，也就是資料視覺化。

質量目標

根據實時資料的應用場景和實時資料相關業務鏈路，實時資料消費應用的質量目標包括以下幾點：

資料完整性:目標有效資料從資料來源頭到資料加工再到前端資料展示，不能因為加工邏輯許可權，儲存異常，前端展現異常等原因導致資料丟失。例如：
1. 資料來源層出現背壓時，導致資料來源頭（MQ,KAFKA）訊息積壓，積壓嚴重時導致資源耗盡，進而導致資料丟失；
2. 資料處理層資料加工未按照需求進行加工，導致目標有效資料丟失；
3. 資料儲存層的儲存容量寫滿時，導致新資料無法繼續寫入導致資料丟失；
4. 資料加工正確性、資料加工及時性、資料快速恢復性構成資料完整性；
資料加工正確性：目標源資料按照業務需求加工成目標有效資料，目標有效資料根據不同維度不同指標計算成需要展示的不同指標資料。例如：
1. 資料來源層原始資料包含不同聯盟的點選資料，那麼資料處理層過濾掉不需要的聯盟點選資料，並將目標聯盟的點選資料根據媒體和創意資訊補齊當前點選所屬的賬號、計劃、單元；
2. 業務層根據媒體，賬號、計劃、單元不同維度計算出對應的點選總量；
資料加工及時性：目標源資料從產生到前端展示的時間需要控制合理的時間範圍內；
資料快速恢復性：資料在流轉路徑中因為異常導致流轉中斷，資料停止在某一個環節中，當異常解決，系統恢復正常時，停止的資料（停止的資料）需要快速恢復流轉，並且這種恢復是正確的，不應該存在重複的消費和加工或者遺漏。例如：
1. 資料處理層因為消費程式效能問題導致訊息積壓，效能問題解決後資料擠壓問題逐步得到緩解直到恢復正常水平；
2. 資料處理層因為消費程式bug導致程式崩潰，重啟後資料消費正常；
資料可監控性：資料流轉路徑中關鍵節點的關鍵狀態可以有效監控；
資料高可用性：資料不能因為災難性的問題導致丟失造成不能使用的情況，因此需要考慮實時資料消費應用叢集和儲存叢集的主備和可容災;

資料可監控性中有哪些有效的監控點

資料來源層有效監控有：
- 訊息擠壓監控；
- 重試監控（消費失敗，網路超時）;（“重試”官方解釋主要用於對業務系統臨時處理不了的訊息進行存放，然後再按照一定的策略投遞給客戶端處理。可以提供錯誤原因、錯誤處理次數等查詢。）
資料處理層有效監控有:
- 重啟監控:Flink消費應用出現異常導致重啟；
- checkpoint失敗監控：儲存應用當前最新狀態失敗；
- 背壓監控：上游因為下游原因出現背壓；
- 節點資源監控（CPU利用率，內容使用率，網路情況，磁碟使用率等）；
資料儲存層有效監控有：
- 已使用記憶體量監控；
- 主從一致性監控：主從同步延遲，寫資料同時讀取資料，可能會讀取到不一致的髒資料；
- 熱key監控；
- 大key監控；
業務層有效監控有:
- 系統存活監控；
- 介面可用率監控；
- 特定方法自定義監控；

質量目標分佈

在整個實時資料加工流程中，並不是所有的環節都需要達成相同的質量目標。將質量目標分佈在不同的加工環節上；

從質量目標的分佈上看質量目標主要集中在資料處理層，這也客觀的反映了在整個實時資料消費應用的資料流轉路徑中“資料處理層”是核心的特點。

如何守住質量目標（劃重點！）

1.原始資料層

由於“原始資料層”在整個資料流轉路徑中擔任的是原始資料提供方的角色且具體的資料產生邏輯和方式對於下游來說完全是個黑盒。所以在這裡我們需要做好對資料來源的監控，至少需要具備訊息積壓監控，且積壓閾值需要準確的設定，設定過高會導致下游資料延遲時間已經超時合理範圍但上游積壓告警還未出現。

2.資料處理層

如何守住資料正確加工？

基於Flink的實時資料消費應用是不存在功能介面供測試人員從功能角度進行驗證的，且複雜場景下，對一條訊息的處理會存在多個計算邏輯（多個運算元），因此如何保障加工邏輯的覆蓋度變得非常重要。

要保證加工邏輯的覆蓋度就需要清理出資料加工路徑，按照等價類劃分的方法構造出不同路徑下的樣例資料，進行覆蓋。確保線上執行時正常，異常資料應用都可以正常處理。至於覆蓋測試如何進行可以使用Flink-spector，一種應用於Flink程式的單元測試框架。為了進一步保證程式的健壯在資料加工路徑覆蓋測試完成後可以對程式碼進行靜態掃描。以上是從白盒角度對加工路徑進行覆蓋進行加工準確性的保證。另一種是從黑盒功能性的角度進行加工準確性的驗證；

Flink實時訊息消費應用通過不同運算元對資料的加工，這些運算元可以轉換成SQL，測試人員可以根據PRD中資料指標的具體口徑進行提數和實時加工應用的資料進行對比。（注意此方法不僅在上線前可以當做資料正確加工驗證的測試方法，也可以在上線後當做資料正確加工的監控手段。）

如何守住資料快速恢復？

Flink框架自帶保證程式的容錯恢復和程式啟動時其狀態恢復，checkpoint和savepoint，測試人員需要根據具體的實時消費場景判斷程式是否正確配置了相關內容。
（注意檢查完checkpoint配置後在測試環境中執行後，一定要在Flink UI中檢視Checkpoint耗時，如果Checkpoint配置有問題，或者狀態很大的情況發生，會極大的影響消費效能。導致積壓）

如何守住資料及時加工？

資料及時加工反應的其實是實時資料消費的效能，對實時訊息消費應用的效能測試可以從以下幾個方面入口：

單運算元效能測試：Flink應用程式是由不同運算元組成，如果一個運算元對一條訊息處理的效能本身就存在問題，那麼整個鏈路的效能也不會好到哪裡去。
多運算元效能測試：多個運算元的協作完成了對一條訊息的處理，因此需要衡量多個運算元處理完一條資料的效能
（注意單運算元或多運算元的效能在上線前需要測試外，上線後還需要做到持續的監控）如下圖：
模擬效能測試：使用真實資料對實時訊息消費應用叢集進行測試，觀察消費的效能表現。目前一般的做法可以是調整上游訊息的位點；高保真流量回放
資料取樣效能測試：從線上真實資料中取出目標資料，並積累到一定數量後對實時訊息消費應用進行測試。在模擬測試中線上流量對應的資料可能有大部分是我們加工邏輯中直接被過濾掉的，這種情況下剩下的部分資料並沒有起到效能測試的作用；實現方法如下圖：