本次分享分為5個(gè)部分介紹Apache Hudi的應(yīng)用與實(shí)踐

1. 實(shí)時(shí)數(shù)據(jù)落地需求演進(jìn)

實(shí)時(shí)平臺(tái)上線后，主要需求是開(kāi)發(fā)實(shí)時(shí)報(bào)表，即抽取各類數(shù)據(jù)源做實(shí)時(shí)etl后，吐出實(shí)時(shí)指標(biāo)到oracle庫(kù)中供展示查詢。

隨著實(shí)時(shí)平臺(tái)的穩(wěn)定及推廣開(kāi)放，各種使用人員有了更廣發(fā)的需求：

• 對(duì)實(shí)時(shí)開(kāi)發(fā)來(lái)說(shuō)，需要將實(shí)時(shí)sql數(shù)據(jù)落地做一些etl調(diào)試，數(shù)據(jù)取樣等過(guò)程檢查；
• 數(shù)據(jù)分析、業(yè)務(wù)等希望能結(jié)合數(shù)倉(cāng)已有數(shù)據(jù)體系，對(duì)實(shí)時(shí)數(shù)據(jù)進(jìn)行分析和洞察，比如用戶行為實(shí)時(shí)埋點(diǎn)數(shù)據(jù)結(jié)合數(shù)倉(cāng)已有一些模型進(jìn)行分析，而不是僅僅看一些高度聚合化的報(bào)表；
• 業(yè)務(wù)希望將實(shí)時(shí)數(shù)據(jù)作為業(yè)務(wù)過(guò)程的一環(huán)進(jìn)行業(yè)務(wù)驅(qū)動(dòng)，實(shí)現(xiàn)業(yè)務(wù)閉環(huán)；
• 針對(duì)部分需求，需要將實(shí)時(shí)數(shù)據(jù)落地后，結(jié)合其他數(shù)倉(cāng)數(shù)據(jù)，T - 1離線跑批出報(bào)表；

>

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

總的來(lái)說(shuō)，實(shí)時(shí)平臺(tái)輸出高度聚合后的數(shù)據(jù)給用戶，已經(jīng)滿足不了需求，用戶渴求更細(xì)致，更原始，更自主，更多可能的數(shù)據(jù)

而這需要平臺(tái)能將實(shí)時(shí)數(shù)據(jù)落地至離線數(shù)倉(cāng)體系中，因此，基于這些需求演進(jìn)，實(shí)時(shí)平臺(tái)開(kāi)始了實(shí)時(shí)數(shù)據(jù)落地的探索實(shí)踐

2. 基于Spark+Hudi的實(shí)時(shí)數(shù)據(jù)落地應(yīng)用實(shí)踐

最早開(kāi)始選型的是比較流行的Spark + Hudi體系，整體落地架構(gòu)如下：

這套主要基于以下考慮：

• 數(shù)倉(cāng)開(kāi)發(fā)不需寫Scala/Java打Jar包做任務(wù)開(kāi)發(fā)
• ETL邏輯能夠嵌入落數(shù)據(jù)任務(wù)中
• 開(kāi)發(fā)入口統(tǒng)一

我們當(dāng)時(shí)做了通用的落數(shù)據(jù)通道，通道由Spark任務(wù)Jar包和Shell腳本組成，數(shù)倉(cāng)開(kāi)發(fā)入口為統(tǒng)一調(diào)度平臺(tái)，將落數(shù)據(jù)的需求轉(zhuǎn)化為對(duì)應(yīng)的Shell參數(shù)，啟動(dòng)腳本后完成數(shù)據(jù)的落地。

3. 基于Flink自定義實(shí)時(shí)數(shù)據(jù)落地實(shí)踐

由于我們當(dāng)時(shí)實(shí)時(shí)平臺(tái)是基于Flink，同時(shí)Spark+Hudi對(duì)于大流量任務(wù)的支持有一些問(wèn)題，比如落埋點(diǎn)數(shù)據(jù)時(shí)，延遲升高，任務(wù)經(jīng)常OOM等，因此決定探索Flink落數(shù)據(jù)的路徑。

當(dāng)時(shí)Flink+Hudi社區(qū)還沒(méi)有實(shí)現(xiàn)，我們參考Flink+ORC的落數(shù)據(jù)的過(guò)程，做了實(shí)時(shí)數(shù)據(jù)落地的實(shí)現(xiàn)，主要是做了落數(shù)據(jù)Schema的參數(shù)化定義，使數(shù)據(jù)開(kāi)發(fā)同事能shell化實(shí)現(xiàn)數(shù)據(jù)落地。

4. 基于Flink + Hudi的落地?cái)?shù)據(jù)實(shí)踐

Hudi整合Flink版本出來(lái)后，實(shí)時(shí)平臺(tái)就著手準(zhǔn)備做兼容，把Hudi納入了實(shí)時(shí)平臺(tái)開(kāi)發(fā)內(nèi)容。

先看下接入后整體架構(gòu)

實(shí)時(shí)平臺(tái)對(duì)各類數(shù)據(jù)源及Sink端都以各類插件接入，我們參考了HudiFlinkTable的Sink流程，將Hudi接入了我們的實(shí)時(shí)開(kāi)發(fā)平臺(tái)。

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

• Hive表元數(shù)據(jù)自動(dòng)同步、更新；
• Hudi schema自動(dòng)拼接；
• 任務(wù)監(jiān)控、Metrics數(shù)據(jù)接入等

實(shí)際使用過(guò)程如下

整套體系上線后，各業(yè)務(wù)線報(bào)表開(kāi)發(fā)，實(shí)時(shí)在線分析等方面都有使用，比較好的賦能了業(yè)務(wù)，上線鏈路共26條，單日數(shù)據(jù)落入約3億條左右

5. 后續(xù)應(yīng)用規(guī)劃及展望

后續(xù)主要圍繞如下幾個(gè)方面做探索

5.1 取代離線報(bào)表，提高報(bào)表實(shí)時(shí)性及穩(wěn)定性

離線報(bào)表特點(diǎn)是 T - 1，凌晨跑數(shù)，以及報(bào)表整體依賴鏈路長(zhǎng)。兩個(gè)特點(diǎn)導(dǎo)致時(shí)效性不高是一個(gè)方面，另一個(gè)方面是，數(shù)據(jù)依賴鏈路長(zhǎng)的情況下，中間數(shù)據(jù)出問(wèn)題容易導(dǎo)致后續(xù)整體依賴延時(shí)，而很多異常需要等到報(bào)表任務(wù)實(shí)際跑的時(shí)候，才能暴露出來(lái)。并且跑批問(wèn)題凌晨暴露，解決的時(shí)效與資源協(xié)調(diào)都是要降低一個(gè)等級(jí)的，這對(duì)穩(wěn)定性準(zhǔn)時(shí)性要求的報(bào)表是不可接受的，特別是金融公司來(lái)說(shuō)，通過(guò)把報(bào)表遷移至實(shí)時(shí)平臺(tái)，不僅僅是提升了報(bào)表的時(shí)效性，由于抽數(shù)及報(bào)表etl是一直再實(shí)時(shí)跑的，報(bào)表數(shù)據(jù)給出的穩(wěn)定性能有一個(gè)較大的提升。這是我們Hudi實(shí)時(shí)落數(shù)據(jù)要應(yīng)用的規(guī)劃之一

5.2 完善監(jiān)控體系，提升落數(shù)據(jù)任務(wù)穩(wěn)定性

目前僅僅做到落數(shù)據(jù)任務(wù)的監(jiān)控，即任務(wù)是否正常運(yùn)行，有沒(méi)有拋異常等等。但實(shí)際使用者更關(guān)心數(shù)據(jù)由上游到Hive整條鏈路的監(jiān)控情況。比如數(shù)據(jù)是否有延遲，是否有背壓，數(shù)據(jù)源消費(fèi)情況，落數(shù)據(jù)是否有丟失，各個(gè)task是否有瓶頸等情況，總的來(lái)說(shuō)，用戶希望能更全面細(xì)致的了解到任務(wù)的運(yùn)行情況，這也是后面的監(jiān)控需要完善的目標(biāo)

5.3 落數(shù)據(jù)中間過(guò)程可視化探索

這個(gè)是和上面的監(jiān)控有類似的地方，用戶希望確定，一條數(shù)據(jù)從數(shù)據(jù)源接進(jìn)來(lái)，經(jīng)過(guò)各個(gè)算子的處理，它的一些詳細(xì)情況。比如這個(gè)數(shù)據(jù)是否應(yīng)該被過(guò)濾，處于哪個(gè)窗口，各個(gè)算子的處理時(shí)間等等，否則對(duì)于用戶，整個(gè)數(shù)據(jù)SQL處理流程是一個(gè)黑盒。

以上就是Apache Hudi結(jié)合Flink的億級(jí)數(shù)據(jù)入湖實(shí)踐解析的詳細(xì)內(nèi)容，更多關(guān)于Apache Hudi結(jié)合Flink的億級(jí)數(shù)據(jù)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論