實時數據湖Hudi應用解決方案.pdf

《實時數據湖Hudi應用解決方案.pdf》由會員分享，可在線閱讀，更多相關《實時數據湖Hudi應用解決方案.pdf（26頁珍藏版）》請在三個皮匠報告上搜索。

1、DataFunSummitDataFunSummit#20242024實時入湖實時入湖HudiHudi應用解決方案應用解決方案楊宣-華為-大數據開發工程師數據集成整體方案數據集成整體方案數據入湖通用方案數據入湖通用方案數據入湖進階方案數據入湖進階方案目錄目錄 CONTENTCONTENTDataFunSummitDataFunSummit#202420240101數據集成整體方案數據集成整體方案數據集成整體方案數據庫文件消息隊列批量集成Loder實時集成CDL消息隊列JDBC直連CDC采集第三方工具實時采集Hive表Hudi表Spark/FlinkFTP服務批量集成LoderHive表實時集成

2、CDLSpark/FlinkHudi表非標準格式標準格式批量批量實時實時數據量大(百萬到千萬級)小(單表萬級TPS)運行態周期常駐資源消耗周期性峰值高/低峰期時延分鐘到小時級秒級批量入湖方案1.特點適用于存量數據搬遷補數增量對時效要求不高，比如T+12.挑戰數據重復問題。數據庫JDBC直連方式或者文件導出方式無法識別更新和刪除，直接寫入目標表會導致數據重復問題。JDBC直連方式讀取數據庫數據會受到底層網絡資源的影響，JDBC協議通道也有限，大數據量場景該方式采集數據不僅效率低而且對業務庫帶來壓力。文件入湖需要更多的上下游協同來保證完整性，依賴可以管理上下游任務調度的平臺。對接消息管道批量入湖需

3、要關注數據老化時間，以防止丟失數據。3.推薦Hudi表（需要主鍵）擁有行級的更新能力，可以自動去重。建議對表進行分區，這樣去重環節比較方便。在業務庫網絡通道充足且有備庫的情況下，可用JDBC方式進行大數量采集?；蛘卟捎梦募牒硪幈?。文件入湖可以進行壓縮上傳和下載，降低網絡通道消耗，可以采用flag標記文件的上傳狀態，確保文件完整性。消息管道批量入湖可以通過限流來保證入湖程序的穩定性，增加監控對消費終止和積壓等進行告警，降低數據老化風險。實時入湖方案1.特點入湖頻率高，單次數據量低，數據都是包含新增、更新和刪除的過程數據，而非最終快照數據。業務需要快速的數據計算，滿足業務的實時決策需求。任務常

4、駐，資源不釋放，降低資源消耗峰值和源庫壓力。2.挑戰Flink引擎直連數據源的方案單個流只能處理單個表，資源消耗大，無并發，吞吐量小。面對異常場景帶來的問題，分析起來難度大，可靠性低。Spark引擎直連數據源的方案開發成本高。實時場景DDL和DML操作需要一定的有序性保證。實時場景對于數據存儲模型的設計非常重要。3.推薦建議采用專業的CDC工具。它可以提供的可視化無代碼的方式同步；單任務可以采集多表，資源復用，高吞吐；支持的數據源和目標存儲格式豐富；最關鍵的是專業的CDC工具可以快速的從異常場景恢復，丟數風險低，有豐富的告警和監控來保證任務的可靠性。保證數據湖的DDL操作要早于業務庫變更，可以

5、在入湖程序對關鍵表的數據格式進行檢查，如字段增減、數據類型調整，發現異常程序立即退出并告警，保證數據質量。實時數據入湖只能采用Hudi格式的存儲，特大表入湖推薦使用MOR表+Bucket索引+分區。Hudi表模型設計方案 類型入湖實時性要求高就選擇MOR表。一般端到端的實時入湖性能要求都在分鐘內。表字段的大小寫以及字段類型在不同的引擎上都會有差別，建議統一字段大小寫，調研各引擎之間字段類型的映射關系。索引如果業務涉及到多個引擎操作同一個Hudi表，要統一Hudi表的索引。Bucket索引適合Spark/Flink引擎交互操作。Bucket索引的分桶要合理，否則性能會下降。分區表一般建議按業務峰

6、值預估最大的分區未壓縮前的數據量/2G 來分桶，非分區表建議按照業務峰值預估整表未壓縮前的數據量/2G*2來分桶。狀態索引建議在2億數據量以下使用，Cow多數采用Simple索引（大表建議采用Bloom索引），MOR大數據量表建議Bucket索引。分區建議事實表采用日期分區表，維度表采用非分區或者粗粒度的日期分區表。分區要基于數據更新范圍以及下游作業讀取方位來確定。模式UpsertAppend快照表方案1.增量同步快照表2.全量同步快照表 場景小表+批量入湖源表物理刪除 實現Truncate+InsertInsert Overwrite Table批量同步任務Hive增量臨時表Hive快照表存

7、增量合并Hive最新臨時快照Insert OverwriteHudi快照表實時同步任務UpsertUpsert拉鏈表方案1.Hudi增量拉鏈表 特點通常采用分區表，根據業務需要選擇合適的分區粒度。每個分區內的數據都是該時間范圍產生的增量數據的最新快照。分區之間可以存在主鍵重復，分區內沒有主鍵重復，每個主鍵對應的分區字段可以變化。替換老數據批量同步任務Hudi最新快照表Hudi舊快照表Hudi增量數據獲取Hudi增量拉鏈表業務源表批量增量拉鏈實時增量拉鏈全表同步Upsert寫入2024-03-01 2024-03-02.增量同步拉鏈表方案2.Hudi全量拉鏈表 特點每個分區內的數據都是全量數據的

8、最新快照，冗余巨大。適合于源表數據量小，但是變更操作占比很大，新增操作占比很小。拉鏈表的時間分區通常為拉鏈程序運行日減一天。實時同步任務Hudi最新快照表Hudi全量拉鏈表業務源表批量同步任務Upsert寫入2024-03-01 2024-03-02.批量進行全量拉鏈全表同步拉鏈表方案3.數倉拉鏈表ID(PK)ID(PK)UserIdUserIdBalanceBalanceStartTimeStartTimeEndTimeEndTime11000182023022220220302210002820230223202203013100031820220228999912314100021120

9、22030199991231510001102022030299991231 應用場景表的數據量較大表中的部分字段會更新，并且更新的比率和頻率不大。業務需要查看一個時間點或時間段內的歷史快照信息。DataFunSummitDataFunSummit#202420240202實時入湖通用方案實時入湖通用方案實時入湖通用方案1.整體方案流式加工批補表服務TTL動態Bucket桶隱式分區分區演進 特點實時任務只負責數據加工，Hudi表服務由異步Spark任務完成或者托管到HDMS表管理服務。分區動態擴縮容能力可以保證Hudi表自適應業務流量高峰期和低峰期。不停止流作業，實時分區老化。實時入湖通用方案

10、2.分區老化 特點Flink流式加工對時延和穩定性有要求，建議TTL任務與Flink任務解耦。如果TTL物理刪除分區對下游讀作業有影響，可以采用TTL邏輯刪除分區。TTL支持批量分區的老化，與寫不沖突，不需要停止流任務。Sql開啟TTL邏輯刪除分區配置分區配置老化時間物理刪除分區寫提交Clean流式加工實時入湖通用方案3.動態Bucket桶 特點Flink/Spark寫任務動態分桶，不需要重寫分區甚至重導表。支持定制未來分區的桶數或者自動預測未來分區的桶數。支持原地調整現有分區的桶數，此方案需要覆寫分區。建表是否預分桶指定預分桶策略執行分桶AI分桶預測*-11-11:50*-11-11:502

11、024-03-01:10是否實時入湖通用方案4.隱式分區 特點Hudi表不需要添加分區字段，使用業務字段即可。支持創建復雜分區滿足業務特殊需求，零開發。更加適中的分區細分粒度，可以加強分區/文件的過濾，實現查詢加速。Partitioned By(year(ts),month(ts)Bucket(col,n)Year(col)Month(col)Day(col)Hour(col)Date(col,pattern)查詢加速查詢加速隱式分區 SQLSELECT level,count(1)as count FROM logs WHERE event_time BETWEEN 2024-03-01 1

12、0:00:00AND 2024-03-01 12:00:00AND event_date=2024-03-01SELECT level,count(1)as count FROM logs WHERE event_time BETWEEN 2024-03-01 10:00:00AND 2024-03-01 12:00:00實時入湖通用方案5.分區演進 特點分區不合理時無需進行昂貴的遷移就能修復。隨時可以根據當下的業務特點來設置分區，滿足業務查詢條件多樣性和多變性，提升查詢速度。業務高峰期可以從數據量、特定的業務查詢條件等來演進分區，實現負載均衡和查詢優化。Alter Table Set(par

13、tition.rule=year(ts),month(ts),day(ts)Bucket(col,n)Year(col)Month(col)Day(col)Hour(col)Date(col,pattern)查詢加速查詢加速分區演進實時入湖通用方案5.分區演進 查詢特點演進前的分區按照舊分區策略裁剪演進后的分區按照新分區策略裁剪過濾謂詞下推到partitioningRuleDataFunSummitDataFunSummit#202420240303實時入湖進階方案實時入湖進階方案實時入湖進階方案1.ChangeLog 解決場景Kafka數據老化快/存儲成本高/無法點查changelog可以保

14、證數據正確性Kafka入湖程序交互式查詢貼原層(HUDI)聚合層(HUDI)萃取層(HUDI)Changelog數據FlinkFlinkCDC數據讀取IDIDValueValuetimestamptimestamp122024-03-01 10:00:002152024-03-01 10:00:00182024-03-01 10:30:00FlinkSQLselect id,sum(value)from tab gourp by id IDIDValueValue110215實時入湖進階方案2.高速流表 解決場景Flink任務可以從更早的時間點恢復Kafka數據老化快/存儲成本高/無法點查Fl

15、ink加工端到端速度提升10倍FlinkKafkaFlinkKafkaKafka實時數倉HDMSHDMSHDMS實時入湖進階方案3.列簇（寫）Write Job1Base file log file1 log file2Base file log file1 log file2Bucket1ColFamilyAColFamilyBBase file log file1 log file2Base file log file1 log file2BucketNColFamilyAColFamilyBWrite Job2Write Job3實時入湖進階方案3.列簇（讀）ColFamilyARead

16、erBase filelog file1log file2ColFamilyARow Readerlog file3ColFamilyNReaderBase filelog file1log file2ColFamilyNlog file3ReaderReaderReaderReaderReaderReaderReaderReaderSort MergeSort MergeSort Merge實時入湖進階方案4.MOWKeyKeyCol1Col1Col2Col2id1Id2Id3id4KeyKeyCol1Col1Col2Col2Id1(new)Id3(new)Id5id61010KeyKeyC

17、ol1Col1Col2Col2Id1(new)Id2Id3(new)id4id5id6File Group1Base File1Base File2File Group2DVKeyKeyCol1Col1Col2Col2id1Id2Id3id4KeyKeyCol1Col1Col2Col2Id1(new)Id3(new)Id5id61010File Group1Base File1Base File2File Group2DVKeyKeyCol1Col1Col2Col2id1Id2Id3id4File Group1Base File1WriteReadResult實時入湖進階方案5.MDTHUDIMDTJDBC Server8:00 17:0017:00 次日2:00次日2:00次日5:005:00 8:00刷新JDBC Server緩存中的MDT查詢作業批量作業批量作業查詢Hudi緩存MDT 性能結果批量入湖單次數據量百億(TB級)，存量在百TB級單并發3s內，50并發在10s內。感謝觀看感謝觀看謝謝觀看