基於Apache Hudi + Flink的億級資料入湖實踐

leesf 發表於 2022-01-09
Flink

本次分享分為5個部分介紹Apache Hudi的應用與實踐

  • 實時資料落地需求演進
  • 基於Spark+Hudi的實時資料落地應用實踐
  • 基於Flink自定義實時資料落地實踐
  • 基於Flink+Hudi的應用實踐
  • 後續應用規劃及展望

基於Apache Hudi + Flink的億級資料入湖實踐

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

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

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

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

基於Apache Hudi + Flink的億級資料入湖實踐

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

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

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

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

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

基於Apache Hudi + Flink的億級資料入湖實踐

這套主要基於以下考慮:

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

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

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

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

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

基於Apache Hudi + Flink的億級資料入湖實踐

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

先看下接入後整體架構

基於Apache Hudi + Flink的億級資料入湖實踐

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

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

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

實際使用過程如下

基於Apache Hudi + Flink的億級資料入湖實踐

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

5. 後續應用規劃及展望

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

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

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

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

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

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

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

相關文章