Apache Hudi結合Flink的億級資料入湖實踐解析

2022-03-30 19:04:55

1. 實時資料落地需求演進

實時平臺上線後，主要需求是開發實時報表，即抽取各類資料來源做實時etl後，吐出實時指標到oracle庫中供展示查詢。

隨著實時平臺的穩定及推廣開放，各種使用人員有了更廣發的需求：

對實時開發來說，需要將實時sql資料落地做一些etl偵錯，資料取樣等過程檢查；
資料分析、業務等希望能結合數倉已有資料體系，對實時資料進行分析和洞察，比如使用者行為實時埋點資料結合數倉已有一些模型進行分析，而不是僅僅看一些高度聚合化的報表；
業務希望將實時資料作為業務過程的一環進行業務驅動，實現業務閉環；
針對部分需求，需要將實時資料落地後，結合其他數倉資料，T - 1離線跑批出報表；

除了上述列舉的主要的需求，還有一些零碎的需求。

總的來說，實時平臺輸出高度聚合後的資料給使用者，已經滿足不了需求，使用者渴求更細緻，更原始，更自主，更多可能的資料

而這需要平臺能將實時資料落地至離線數倉體系中，因此，基於這些需求演進，實時平臺開始了實時資料落地的探索實踐

2. 基於Spark+Hudi的實時資料落地應用實踐

最早開始選型的是比較流行的Spark + Hudi體系，整體落地架構如下：

這套主要基於以下考慮：

數倉開發不需寫Scala/Java打Jar包做任務開發
ETL邏輯能夠嵌入落資料任務中
開發入口統一

我們當時做了通用的落資料通道，通道由Spark任務Jar包和Shell指令碼組成，數倉開發入口為統一排程平臺，將落資料的需求轉化為對應的Shell引數，啟動指令碼後完成資料的落地。

3. 基於Flink自定義實時資料落地實踐

由於我們當時實時平臺是基於Flink，同時Spark+Hudi對於大流量任務的支援有一些問題，比如落埋點資料時，延遲升高，任務經常OOM等，因此決定探索Flink落資料的路徑。

當時Flink+Hudi社群還沒有實現，我們參考Flink+ORC的落資料的過程，做了實時資料落地的實現，主要是做了落資料Schema的引數化定義，使資料開發同事能shell化實現資料落地。

4. 基於Flink + Hudi的落地資料實踐

Hudi整合Flink版本出來後，實時平臺就著手準備做相容，把Hudi納入了實時平臺開發內容。

先看下接入後整體架構

實時平臺對各類資料來源及Sink端都以各類外掛接入，我們參考了HudiFlinkTable的Sink流程，將Hudi接入了我們的實時開發平臺。

為了提高可用性，我們主要做了以下輔助功能;

Hive表後設資料自動同步、更新；
Hudi schema自動拼接；
任務監控、Metrics資料接入等

實際使用過程如下

整套體系上線後，各業務線報表開發，實時線上分析等方面都有使用，比較好的賦能了業務，上線鏈路共26條，單日資料落入約3億條左右

5. 後續應用規劃及展望

後續主要圍繞如下幾個方面做探索

5.1 取代離線報表，提高報表實時性及穩定性

離線報表特點是 T - 1，凌晨跑數，以及報表整體依賴鏈路長。兩個特點導致時效性不高是一個方面，另一個方面是，資料依賴鏈路長的情況下，中間資料出問題容易導致後續整體依賴延時，而很多異常需要等到報表任務實際跑的時候，才能暴露出來。並且跑批問題凌晨暴露，解決的時效與資源協調都是要降低一個等級的，這對穩定性準時性要求的報表是不可接受的，特別是金融公司來說，通過把報表遷移至實時平臺，不僅僅是提升了報表的時效性，由於抽數及報表etl是一直再實時跑的，報表資料給出的穩定效能有一個較大的提升。這是我們Hudi實時落資料要應用的規劃之一

5.2 完善監控體系，提升落資料任務穩定性

目前僅僅做到落資料任務的監控，即任務是否正常執行，有沒有拋異常等等。但實際使用者更關心資料由上游到Hive整條鏈路的監控情況。比如資料是否有延遲，是否有背壓，資料來源消費情況，落資料是否有丟失，各個task是否有瓶頸等情況，總的來說，使用者希望能更全面細緻的瞭解到任務的執行情況，這也是後面的監控需要完善的目標

5.3 落資料中間過程視覺化探索

這個是和上面的監控有類似的地方，使用者希望確定，一條資料從資料來源接進來，經過各個運算元的處理，它的一些詳細情況。比如這個資料是否應該被過濾，處於哪個視窗，各個運算元的處理時間等等，否則對於使用者，整個資料SQL處理流程是一個黑盒。

以上就是Apache Hudi結合Flink的億級資料入湖實踐解析的詳細內容，更多關於Apache Hudi結合Flink的億級資料的資料請關注it145.com其它相關文章！