Hudi 數據湖在順豐的應用實踐.pdf

《Hudi 數據湖在順豐的應用實踐.pdf》由會員分享，可在線閱讀，更多相關《Hudi 數據湖在順豐的應用實踐.pdf（30頁珍藏版）》請在三個皮匠報告上搜索。

1、Hudi 數據湖在順豐的應用實踐演講人：唐尚文-順豐科技-數據湖技術負責人應用場景010203未來展望目錄實踐與優化數據湖在順豐的應用Part 01順豐集團業務概覽快遞物流快遞快運同城即時配送國際冷鏈醫藥倉配一體增值服務供應鏈綜合物流其他業務豐巢順豐房托豐泰產業園順豐數科更多.順豐科技業務全景數據中臺AI中臺大數據平臺順豐云平臺DevOps一站式研發平臺智能運維平臺信息安全運營平臺數字化全流程管理數字化企業經營智能化升級，助力管理效率提升大網數字化貫穿收轉運派全生命周期的數字化科技能力供應鏈數字化自研一體化的供應鏈系統及平臺，實現多元供應鏈生態科技服務標準科技產品基于科技能力的標準化標桿對外應

2、用產品行業解決方案提供端到端基于泛物流場景的多行業一體化解決方案數字化物流開放平臺基于Lass 對外提供數字化物流服務能力運籌大數據區塊鏈人工智能無人XGIS隱私計算數據湖 Hudi 具備怎樣的能力？離線批計算實時流計算優勢：技術成熟穩定、可應對復雜邏輯缺點：時效性低（天級/小時級）優勢：時效性高（秒級）缺點：開發成本、穩定性低，復雜度有限近實時計算Hudi優勢時效性高（分鐘級）支持流批寫入，增量查詢等能力優秀的局部更新能力支持 ACID支持多版本.在某些場景下，兼顧時效性和數據復雜度，對原有數倉架構進行能力補充數據湖在順豐的應用可視化監控與分析經營熱力圖件量、客戶、產品、收派比可視化分析中轉

3、/流向預測件量預測參考對件量進行預測將結果給到場地進行參考，對人力和資源進行安排運單/運力異常監控對運力進行實時/準實時監控，快速識別運力異常，干預并降低損失異常風險識別航空資源動態調整資源缺口識別近實時識別航空資源的動態缺口，調整資源分配數據湖在順豐的實踐和優化Part 02數據湖在順豐的實踐和優化01實時數據入湖實踐02離線數據開發實踐順豐實時數據接入發展歷程201720192021JStorm+CanalFlink+CanalFlink+CDCFlink+Canal 實現數據入湖存在的問題Binlog采用不鎖表的方式進行數據采集，容易導致數據狀態的變化時序無法和數據庫保持一致數據一致性難

4、保障數據需要經過多個組件才能實現數據入湖、維護起來復雜、穩定性難保障架構復雜、加工鏈路長全量canal.Flink寫入 binlog讀取 binlog全量查詢實時數據入湖的需求和技術選型增量同步Flink CDC斷點續傳無鎖讀取全量+增量分布式數據轉換能力強能夠保障數據一致全量增量數據同步自動切換，并能夠保障數據的一致對源數據庫影響最低盡量不使用鎖，同時避免一個表一個同步任務，盡量降低對源數據庫造成影響具有較好的同步性能能夠支持分布式采集，具有很好的穩定性去保障數據的同步效率核心需求技術選型基于開源的 Flink CDC 實現數據入湖步驟實時計算平臺1.SQL/JAR大數據集群2.提交作業用戶

5、數據管理員1.數據源申請數據庫2.權限維護數據地圖1.數據資產注冊2.數據查找能夠滿足基本需求但也存在一些問題！步驟1:申請數據源權限用戶用戶用戶步驟2:實時數據入湖任務開發/調試步驟3:數據資產注冊和維護易用性問題穩定性問題易用性問題：開源方式接入門檻高、難度大接入用戶需要了解較多的 Flink、Hudi等 使用方法、數據庫等配置信息，對于小白用戶或者數據接入放來說，使用門檻較高接入門檻高數據庫連接信息維護難、沒有統一的數據源管理、權限控制等，數據源管理員工作量大，并且這種管理方式也存在一定的安全問題維護難度大解決方案：通過產品化降低數據入湖門檻順豐實時數據直通車通過數據源管理授權用戶訪問、

6、避免密碼泄漏，方便用戶進行數據管理和數據共享安全可控、易維護用戶只需勾選待同步的表及相關信息，就能自動生成對應的數據同步任務，完成敏感字段數據自動加密等工作，無需了解 Flink、Hudi 相關配置就能夠實現數據快速數據入湖高效接入、零門檻數據安全加密數據源管理無需保留敏感信息根據用戶量級匹配自動生成對應的接入參數，提高接入的效率實時接入產品應用架構數據源管理數據應用2.數據源授權1.申請數據源實時數據直通車MySQL4.同步 Schema 等信息3.創建作業實時計算平臺數據地圖5.提交數據同步作業6.新建資產用戶數據開發平臺數據接入數據使用大數據集群元數據獲取7.提交作業提交作業簡要步驟數據

7、源授權：用戶申請數據源讀取權限并獲得管理員授權作業創建：直通車根據用戶勾選的相關信息生成對應的同步作業元數據同步：直通車根據待同步的表信息在數據資產創建對應的元數據數據使用：用戶根據數據資產上面的信息，通過查詢引擎使用同步后的數據應用架構簡圖穩定性問題：實時數據入湖鏈路穩定性差MySQL 1數據源MySQL 2MySQL N數據計算數據湖 Hudi Flink CDC實時數據采集upsert實時數據入湖數據采集階段數據入湖階段源端系統影響大全量采集階段成功率低增量采集階段效率低數據質量問題超過物理內存被 YARN KILLTM 的資源利用率不高TM 容易發生 Timeout資源占用較大等等.解

8、決方案：采集階段全/增量讀取性能優化全量采集階段成功率低增量采集階段效率低TM 容易發生 Timeout資源占用較大MySQL 1MySQL NCDC APP分庫分表多實例生成 snapshot 任務snapshot 同步binlog 任務分配binlog 采集Binlog 同步階段 Task 分配傾斜在分庫分表場景下 Binlog 階段同步 Task 默認都分配到 SubTask-0，導致采集傾斜，內存消耗大，容易造成長時間的 GC 停頓和效率低的問題Snapshot 階段切分邏輯缺陷在生成 snapshot 任務時，在字符串為主鍵的大表場景下，因為不同字符集存在大小寫不區分的情況，導致 s

9、plit 過早結束，造成某個split 過大，同步效率低，任務不穩定的問題缺乏重連機制，影響作業穩定性在寫入造成任務存在反壓的情況下容易導致鏈接數據庫出現異常，影響作業穩定性原因分析解決方案：提高全增量同步穩定性優化 Binlog 同步階段 Task 分配算法將 Task 打散到不支持隨機分發采集任務策略，避免所有binlog采集任務分配到 Subtask-0增加重連機制，提高任務的穩定性通過增加重連機制，避免任務因為下游反壓導致的異常問題，提高任務的穩定性完善 Snapshot 階段切分邏輯在進行 chunk 切分時，同時判斷返回的數據條數，如果符合預設條件，證明后續可能還存在數據，這樣可以

10、避免因為數據庫的設置導致切分傾斜的問題解決方案：采集階段讀取限流和任務合并MySQL 1CDC APPFlink CDCFlink CDC存儲端存儲端Binlog 被反復拉取多次多個任務同時采集相同數據庫實例，導致數據源的 binlog 數據被反復拉取，容易造成源數據庫壓力過高無流量限制讀取突發的采集高峰可能會導致源數據庫流量過大，增加服務的負載容易造成系統不穩定對源端系統影響大優化前CDC APP解決方案：任務合并、限流，降低源庫負載讀取限流通過全量、增量階段限流降低對原數據庫的影響任務合并通過對滿足合并條件的數據同步任務，由實時計算平臺發起合并任務請求，將任務進行合并后重新拉起，降低重復同

11、步 Binlog 數據對源數據庫帶來的性能開銷MySQL 1CDC APP存儲端存儲端優化后CDC APP實時計算平臺存儲端存儲端上報消費進度MySQL 1合并啟動CDC APP流量控制解決方案：數據入湖階段 Bucket 策略優化超過物理內存被 YARN KILLTM 的資源利用率不高資源占用較大小文件過多的問題CDC APPTask 1 Task 100MySQL 1MySQL N分庫分表多實例Task 2 Task 60.Task 1 DataBucketDataBucketDataBucketTask10102030Task 1-10Task 20-10Task 30-60Task 6

12、0-100DataBucket 分布情況原因分析解決方案：完善 Bucket 適用場景、提升寫入性能原生 Bucket 算法存在一定的缺陷原生的 Bucket 分配算法存在一定的缺陷，會導致 Databucket 在Task 分配不均的問題，很多 Task 存在空跑的情況，實際的資源利用率較低Bucket 數量無法按需指定Bucket 數量為全局配置選項，無法適應實際業務中，某些分區數據傾斜的場景，設置過大容易造成小文件過多，設置過小在傾斜的分區寫入也會到寫入性能inline compaction 容易導致作業不穩定flink 內部進行 compaction 需要合理設置 overhead 參

13、數，否則會容易造成物理內存超過 YARN 的限制被 KILL，影響作業的穩定性優化 Bucket 算法分配策略對 Bucket 算法進行優化，讓 DataBucket 能夠相對均勻的分布到不同的 Task 上，提高任務的內存利用率，詳情參考：HUDI-5671分區級別 Bucket 數量設置針對業務數據傾斜的場景，允許用戶按照分區數據量等方式設置bucket 數量，提高數據入湖的效率異步 Compaction 配置異步 compaction 能夠避免 overhead 設置不合理導致內存的任務不穩定的問題，還能預留內存長期占用，降低資源消耗達成效果：億級表數據實時入湖MySQL 1MySQL

14、2MySQL NFlink CDCUPSERT實時采集日志數據數據寫入數據源數據應用QUERY實時查詢日志分析數據讀取BI 報表數據湖 Hudi（T+10 min 延時）數據計算全量70+億，每天增量1億數據社區方案無法完成該量級的數據同步，服務穩定性差達成效果穩定正常運行實時數據入湖整體回顧讀取限流分庫分表敏感字段識別任務合并順豐實時直通車MySQLMySQLOracle.PG表結構同步數據源端資產注冊數據加密數據源管理Kafka.數據湖數據目標端數據地圖權限管理資產查詢.Kafka用戶 A實時接入數據同步數據同步數據同步數據同步表結構同步數據湖在順豐的實踐和優化01實時數據入湖實踐02離線

15、數據開發實踐數據湖開發當前存在的一些痛點Kafka 1Kafka 2日志服務fetchUPSERT實時數據采集數據寫入數據源數據應用QUERY實時查詢日志分析數據讀取BI 報表數據湖 Hudi（增量數據）數據計算數據湖 Hudi（底表數據）MERGE常見數據的加工鏈路痛點1：什么時候應該觸發下游離線開始計算？痛點2：全局索引模式下更新很慢，無法滿足業務時效需求解決方案：支持數據水位識別，支持流轉批場景WriteTask 1WriteTask 2WriteTask 3Coordinatort1=min(ts)t2=min(ts)t3=min(ts)eventTime=min(t1,t2,t3)h

16、udi-wm-check下游任務1下游任務22023 01-0200:05:002023 01-0123:55:00commit獲取寫入這一批中的數據最小的數據時間匯報到CoordinatorCoordinator 收集來自所有 Task 匯報上來的數據時間，取最小值并將它寫入到hudi表的目錄中（這里考慮到一個場景，因為在沒有數據的情況下，不會提交commit，可能就會導致下游永遠無法識別數據進度，但是實際今天的數據已經寫完）如果沒有實際的數據時間，就用當前的checkpoint時間下游通過檢測工具檢測數據水位進度，符合條件則觸發下游計算解決方案：記錄級別索引加速更新效率更新效率低下優化前解

17、決方案：通過記錄級別索引提高更新效率優化后大數據集 Bloomfilter 假陽性問題由于bloomfilter的誤判特性，需要將這些紀錄在文件中進行精準匹配查找以得到實際需要更新的紀錄及其對應的location，且在大數據集的情況下定位 Record 的性能非常差HBase 索引維護工作量大、成本高由于 HBase 索引也支持類似全局索引的能力，但是需要維護第三方服務成本較大，可能還會引入別的問題，不夠輕量級Hudi Mata TableRecordLevelIndexbucket 1bucket 2bucket NHFileKey1-path1,file1Key2-path2,file2K

18、ey3-path3,file3Key4-path4,file4Key5-path5,file5Key6-path6,file6Key7-path7,file7索引信息收集數據寫入元數據提交文件定位更新數據集主表數據更新Hudi TableParquet File 1獲取文件位置更新數據集主表數據更新FooterParquet File 2Footer支持記錄級別索引在 Hudi metadata 表上新增一種類型 RecordLevelIndex 用來記錄主鍵和文件的位置，并用 HFile 文件格式進行存儲加速文件定位的效率，提高大表場景下的更新性能，同時能夠避免維護第三方組件，做到輕量級同時

19、易維護達成效果：千萬級數據更新提效Kafka 1Kafka 2日志服務fetchUPSERT實時數據采集數據寫入數據源數據應用QUERY實時查詢日志分析數據讀取BI 報表數據湖 Hudi（增量數據）數據計算底表數據100+億，每天千萬級數據更新數據湖 Hudi（底表數據）MERGE社區方案全局 Boolm 索引，超過5小時任務都沒法完成達成效果記錄級別索引，完成該場景數據更新在同樣的資源耗時40min未來展望Part 04未來展望數據湖內核增強查詢優化支持 Presto 等計算引擎使用MDT下推的能力，加速查詢統一元數據構建統一的元數據服務、表管理服務的能力更新能力支持分區變更，非主鍵更新，多流更新等能力，適用更多的業務場景穩定性提高數據入湖，數據處理的能力，保障業務時效感謝觀看！