一、傳統資料湖存在的問題與挑戰
傳統資料湖解決方案中，常用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可以構建分鐘級資料處理方案，實作較大資料量的復雜計算實時處理能力，大大提升資料時效性，讓資料價值近在眼前！
本文由華為云發布，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/448108.html
標籤：其他