基於MRS-Hudi構建資料湖的典型應用場景介紹

阿新 • • 發佈：2022-03-23

一、傳統資料湖存在的問題與挑戰

傳統資料湖解決方案中，常用Hive來構建T+1級別的資料倉庫，通過HDFS儲存實現海量資料的儲存與水平擴容，通過Hive實現元資料的管理以及資料操作的SQL化。雖然能夠在海量批處理場景中取得不錯的效果，但依然存在如下現狀問題：

問題一：不支援事務

由於傳統大資料方案不支援事務，有可能會讀到未寫完成的資料，造成資料統計錯誤。為了規避該問題，通常控制讀寫任務順序呼叫，在保證寫任務完成後才能啟動讀任務。但並不是所有讀任務都能夠被排程系統約束住，在讀取時仍存在該問題。

問題二：資料更新效率低

業務系統庫的資料，除流水錶類的資料都是新增資料外，還有很多狀態類資料表需要更新操作（例如：賬戶餘額表，客戶狀態表，裝置狀態表等），而傳統大資料方案無法滿足增量更新，常採用拉鍊方式，先進行join操作再進行insert overwrite操作，通過覆蓋寫的方式完成更新操作，該操作往往需要T+1的批處理模式，從而導致端到端資料時延T+1，存在效率低、成本高等問題。

問題三：無法及時應對業務表變化

上游業務系統對資料schema發生變更後，會導致資料無法入湖，需要資料湖的表schema進行同步調整。從技術實現上採用資料表重建的方式來滿足該場景，導致資料湖的資料表的管理與維護方案複雜，實現成本高。另外該種場景通常需要業務部門與資料團隊相配合，通過管理流程來實現表結構的同步。

問題四：歷史快照表資料冗餘

傳統資料湖方案需要對歷史的快照表進行儲存，採用全量歷史儲存的方式實現，例如：天級歷史快照表，每天都會全量儲存全表資料。這樣就造成了大量的資料儲存冗餘，佔用大量的儲存資源。

問題五：小批量增量資料處理成本高

傳統資料湖為了實現增量ETL，通常將增量資料按照分割槽的方式進行儲存，若為了實現T+0的資料處理，增量資料需要按照小時級或者分鐘級的分割槽粒度。該種實現形式會導致小檔案問題，大量分割槽也會導致元資料服務壓力增大。

基於以上問題，華為FunsionInsight MRS整合Apache Hudi元件，希望通過Hudi元件來改善傳統資料湖存在的問題。

二、MRS雲原生資料湖Hudi的關鍵特性

Apache Hudi是資料湖的檔案組織層，對Parquet等格式檔案進行管理提供資料湖能力，支援多種計算引擎，提供IUD介面，在 HDFS/OBS的資料集上提供了插入更新和增量拉取的流原語，具有如下特點：

支援ACID

支援SnapShot資料隔離，保證資料讀取完整性，實現讀寫併發能力
資料commit，資料入湖秒級可見

快速Upsert能力

支援可插拔索引進位制實現新增更新資料快速入湖
擴充套件Merge操作，實現新增、更新、刪除混合資料同時入湖

支援寫入同步小檔案合併能力，寫入資料自動按照預設檔案大小進行檔案合併

Schema Evolution

支援湖內資料schema的同步演進
支援多種常見schema變更操作

多種檢視讀取介面

支援實時快照資料讀取方式
支援歷史快照資料讀取方式
支援當前增量和歷史增量資料讀取方式
支援快速資料探索分析

多版本

資料按照提交版本儲存，保留歷史操作記錄，方便資料回溯
資料回退操作簡單，速度快。

三、MRS-Hudi的典型應用場景

基於MRS-CDL元件實現資料實時入湖

場景說明：

可以從業務資料庫中直接抽取資料
資料入湖需要高實時性，秒級延遲
資料表變更需要與資料湖表結構實時同步

方案介紹：

該方案基於MRS-CDL元件構建，由CDL元件實現業務庫的操作事件捕獲並寫入的基於MRS-Hudi的資料湖儲存。

MRS-CDL是FusionInsight MRS推出的一種資料實時同步服務，旨在將傳統OLTP資料庫中的事件資訊捕捉並實時推送到資料湖中去。該方案有以下特性支援：

MRS-CDL支援捕獲業務系統庫的DDL和DML事件。
支援將MRS-Hudi作為資料目標端。
視覺化操作，採集任務、入湖任務以及任務管理都是視覺化操作。
入湖任務支援多租戶，保證資料許可權與湖內許可權保持一致。
全程任務開發零程式碼，節省開發成本。

方案收益：

入湖操作簡單，全程零程式碼開發。
入湖時效快，從業務系統資料調整到入湖，可在分鐘內完成。

基於Flink SQL入湖

** 場景說明：**

無需直接對接資料庫，資料由已有采集工具傳送到Kafka或者由業務系統直接傳送到Kafka。
不需要實時同步DDL操作事件。

** 方案說明：**

MRS的FlinkSQL入湖鏈路是基於Flink+Hudi成的。MRS-Flink以下特性支援該方案：

增加了Flink引擎與Hudi的對接能力。支援了對Hudi中COW表以及MOR表的讀寫操作。
FlinkServer（Flink開發平臺）增加了對Hudi的流量表支援。
作業開發與作業維護視覺化操作。

方案收益：

入湖程式碼開發簡單。

通過FlinkSQL實現入湖的語句如下：

Insert into table_hudi select * from table_kafka;

入湖時效快，最快可達秒級資料入湖。

湖內資料快速ETL

場景說明：

湖內資料通常會採用數倉分層儲存，例如：貼源層（SDI）、彙總層（DWS）、集市層（DW），各家企業也會有不同的分層標準。資料在各層直接流轉也會有相應的規範。傳統資料湖通常採用天級全量資料ETL處理以實現各層之間資料流轉。

現在Hudi支援ACID特性、Upsert特性和增量資料查詢特性，可以實現增量的ETL，在不同層之間快速的流轉。

增量ETL作業與傳統ETL作業業務邏輯完全一樣，涉及到的增量表讀取採用commit_time來獲取增量資料，在作業邏輯中的多表關聯可以使Hudi表與Hudi表關聯，也可以是Hudi表與存量Hive表的關聯。 ETL作業開發可以基於SparkSQL、FlinkSQL開發。基於增量檢視的ETL語句樣例如下：Upsert table_dws select * from table_SDI where commit_time > “2021-07-07 12:12:12”。

由於採用了增量ETL方式，每次所處理的資料量也會下降，具體下降多少有賴於業務實際流量情況和增量的週期粒度。例如：物聯網的業務資料，全天24小時流量穩定，採用10分鐘級別的增量ETL，那麼所處理的數量將全天資料量的1/（24*60/10）。因此在處理資料量大幅下降情況下，所需的計算資源也有相應的下降。

方案收益：

單個ETL作業處理時延降低，端到端時間縮短。
消耗資源下降，單位ETL作業所處理資料量大幅下降，所需計算資源也會相應下降。
原有湖記憶體儲的模型無需調整。

支援互動式分析場景

場景說明：

資料湖儲存的資料具有資料種類全、維度多、歷史週期長的特點，業務所需資料在資料湖中基本都是存在的，因此直接互動式分析引擎直接對接資料湖可以滿足業務各類需求資料需求。

在資料探索、BI分析、報表展示等業務場景需要具備針對海量資料查詢秒級返回的能力，同時要求分析介面簡單SQL化。

方案說明：

在該場景中可以採用MRS-HetuEngine來實現該方案，MRS-HetuEngine是分散式高效能的互動式分析引擎，主要用於資料的快速實時查詢場景。MRS-HetuEngine具備以下特性可以很好的支撐該場景：

MRS-HetuEngine引擎已經完成與MRS-Hudi的對接，能夠快速讀取Hudi儲存的資料。
支援讀取快照查詢，查詢當前最新快照資料和歷史快照資料。
支援增量查詢，根據commit_time，查詢任一時間段內的增量資料。
針對MOR儲存模型，尤其在資料探索場景可以通過讀優化查詢介面，快速分析MOR模型的Hudi表資料。
支援多源異構協同，具備跨Hudi與其他DB的聯合分析能力，例如：維度資料存在TP庫中，可以實現資料湖的事實表與TP維度表的關聯分析。
查詢語句SQL化，支援JDBC介面。

方案收益：

結合MRS-CDL資料入湖，業務系統庫資料變更可在分鐘內實現在資料湖內可見。
對TB級到PB的資料量的互動式查詢可達到秒級結果返回。
可對湖內各層資料進行分析。

基於Hudi構建批流一體

場景說明：

傳統處理架構中採用Lambda或者Kappa架構。Lambda使用比較靈活，也可以解決業務場景，但是在該架構中需要兩套系統來完成，維護比較複雜。資料分流以後也很難再關聯應用。例如：流處理場景使用批處理的結果。Kappa架構是為實時處理的架構，該架構缺少了批處理的能力。

方案說明：

在很多實時場景中，對時延要求可以是分鐘級的，這樣可以通過MRS-Hudi和實時計算引擎Flink和Spark-Streaming進行增量計算實現資料的快速處理，端到端實現分鐘級延遲。另外MRS-Hudi本身就是湖儲存，可以儲存海量資料，因此也可以支援批量計算，常用的批處理引擎可以採用Hive和Spark。

方案價值：

資料統一儲存，實時資料與批量資料共用相同的儲存。
同時支援實時計算與批量計算。相同業務邏輯的處理結果複用。
滿足分鐘級延時的實時處理能力和海量的批量處理。

五、總結

傳統大資料由於不支援事務等痛點問題，造成T+1時延，雖然能夠基於Flink流式計算實現少量資料在簡單場景的秒級資料處理能力，但依然缺乏海量複雜場景的實時更新、事務支援能力。現在基於華為雲FusionInsight MRS的Hudi可以構建分鐘級資料處理方案，實現較大資料量的複雜計算實時處理能力，大大提升資料時效性，讓資料價值近在眼前！