Hudi 實踐 | 快手基于 Apache Hudi 的實踐
分享一篇Apache Hudi在快手的實踐，如何使用Apache Hudi解決效率問題
分享者為靳國衛(wèi)，快手大數據研發(fā)專家，負責用戶增長數據團隊
分為三部分介紹Hudi如何解決效率問題，首先是實際應用中遇到的痛點有哪些，業(yè)務訴求是什么，然后調研業(yè)界的解決方案，為什么選擇Hudi來解決痛點問題，然后介紹在實踐中如何使用Hud解決業(yè)務問題，并形成體系化的解決方案。
業(yè)務痛點包括數據調度、數據同步和修復回刷三大類痛點，包括數據全量回刷效率低。
三個場景拉通來看，從業(yè)務訴求就是希望更快看到結果，像業(yè)務庫那樣數據準備好了就可以使用，由于業(yè)務庫引擎限制，又希望使用大數據技術做分析，總的來看可以結合實時化和大數據的CRUD。
在業(yè)界進行調研后，發(fā)現有一些解決方案，但最后為什么選擇了Hudi呢？
對比了現在業(yè)界通用的解決方案，并且從功能豐富度、與公司痛點匹配度、自動化程度、與Flink集成、社區(qū)活躍度等方面考慮，快手最后選擇Hudi作為解決方案。
首先來看Hudi的架構體系，通過Spark/Flink將上游數據同步到數據湖的Raw Tables中，并可對Raw Tables進行增刪改查，與快手內部需求及痛點匹配度非常高。
下面來看數據在Hudi的寫入流程，從Kafka中取數據時會先進行一次rebalance來預防數據熱點問題，然后對數據進行合并后進行檢索，最后會丟棄一部分無用數據（重復或亂序到達的數據）。
經過數據寫入后Parquet文件格式存在，其結構包括數據、Footter（包含一些元數據信息）等，Hudi是一個數據存儲解決方案，可以解決離線數倉中的增刪改問題。
接下來從實踐的角度來看Hudi如何解決業(yè)務問題
對大量數據進行大量更新時效性差，SLA壓力大，另外就是數據局部更新資源浪費嚴重。
Hudi的模型設計與傳統(tǒng)的離線數倉模型設計不相同，認知上有所不同。
另外一個挑戰(zhàn)是Hudi的寫模型設計，包括主鍵、分區(qū)設計以及一些策略的設計等。
基于Hudi的模型，對數據同步模型進行了設計，來解決千億級數據量的億級更新問題。
確定合適的分區(qū)和文件大小來解決數據更新中的毛刺問題
對于數據回刷場景下的局部更新也有了很好的解決，沉淀了一套通用解決方案。
還有一個挑戰(zhàn)是如何保障Hudi作業(yè)正常運行，包括設計流程、時效性和準確性幾方面做了一些建設。
使用Hudi方案后取得了很好的效果，包括時效、資源、基于Hudi的通用解決方案等方面效果都非常不錯。
推薦閱讀