? ? ? ?導讀：從領域模型建設的角度，我們知道需要對業務場景進行合理的拆解、規劃、設計，使得我們在進行數據內容的建設時思路清晰、模型復用度高。然而在實際的實施過程會遇到一些復雜場景，在我們極盡優化之后仍然出現就緒晚、執行效率低的情況。所以，如果當前的技術手段不再能解決這些問題，我們會分出一些精力去探索新的技術方案來解決這些效率問題。

? ? ? ?01痛點業務場景

? ? ? ?1. 痛點場景

? ? ? ?(1)?數據調度

? ? ? ?日常工作中有些業務周期不是自然周期，比如我們的花費計算場景是14點啟調，調度啟動晚。業務上可能更新近3個月的局部數據，需要動態回刷3個月的數據，計算周期長。調度啟動晚和計算周期長，造成就緒比較晚，影響業務對數據的使用訴求。

? ? ? ?(2) 數據同步

? ? ? ?每天會同步大量的過程明細數據到數倉進行計算，用于支持業務決策。有些場景需最新狀態，比如我們有一份用戶關系數據，只需要最新的關系對。還需要將關注過程做合并計算。過程數據量大和合并計算耗時長，造成完成晚，并且同步任務是鏈路根節點，導致整條鏈路的SLA保障壓力大。

? ? ? ?(3)?修復回刷

? ? ? ?進行歷史數據回刷時，其實僅需要更新小部分數據即可，然而離線數倉是全量批更新模式，需要耗費大量的資源做全量回刷。因此回刷修復會耗費大量資源、數據修復周期長。

? ? ? ?2. 基于痛點場景的思考

? ? ? ?從業務痛點出發，不論從研發的角度還是業務的角度其訴求一致：數據能夠快速就緒、產出最新的數據。

? ? ? ?為什么當前的離線數據建設技術方案不能滿足需求？從本質來看，仍是采用傳統的調度+離線計算的方式，只不過采用了資源換效率的方式，改變的僅僅是調度的頻次。

? ? ? ?根據數據特點 + 【產出快】【狀態新】的訴求，也做過一些嘗試。

? ? ? ?調度場景，因為只有千萬級的3個月數據，可以全部保存在Flink的內存中，以天為窗口Sink一次，這樣可以實時獲取最新數據。但隨著業務增長，資源占用、穩定性保障都面臨較大挑戰。

? ? ? ?同步場景，將每小時數據進行同步，同時完成小時內過程數據的合并，再同前一個小時的全量歷史數據合并生成小時級別的全量數據。這樣時效性有所提升，但存儲和計算的成本是天合并的數倍。

? ? ? ?我們希望能在生產時像業務系統那樣，實時完成業務數據處理，分析擁有離線大數據的強大計算能力，希望可以對離線數據模型進行增刪改查，拆解后就是【實時化計算】+【離線數據模型】的CRUD。

? ? ? ?02為什么選擇Hudi來解決問題

? ? ? ?為了實現【實時化計算】+【離線數據模型】的CRUD的訴求，業界的解決方案不止一種，我們選擇Hudi基于以下原因：

? ? ? ?功能豐富度：更多的功能才能支持更多的場景，從而解決更多的業務痛點問題；

? ? ? ?公司融合度：數據內容建設依托公司的體系架構，與公司的體系架構匹配，才能隨著公司體系架構建設，讓數據內容建設的效率更高、保障更好；

? ? ? ?自動化程度：數據內容建設的核心目標是高效的解決業務問題，因此方案的自動化程度越高，我們就可以抽更多的時間聚焦于業務問題的解決，而不是技術細節本身；

? ? ? ?Flink集成度：快手的實時化計算的解決方案以Flink為主；

? ? ? ?社區活躍度：整體來說數據湖的應用還處于比較初期，因此遇到問題可以在社區討論，集合社區同學智慧，獲取建議、經驗，從而高效的有效的解決問題。

? ? ? ?Hudi可以從以下方面解決痛點問題：

? ? ? ?從實時數據源Binlog & Kafka采集數據，通過Flink & Spark Streaming進行數據處理，滿足實時化計算的訴求；

? ? ? ?計算過程中可以實現對離線表進行增刪改生成Row Tables，同時可以被離線數倉識別和應用，滿足離線數據模型CRUD的訴求。

? ? ? ?從上圖中一條數據的Hudi之旅我們看下數據的計算過程。

? ? ? ?從實時源采集數據到系統后，首先做數據的打散平均重分布，從而避免因為業務熱點或者分區數據不均勻造成的數據傾斜和長尾問題；

? ? ? ?經過重分布之后在每個節點上就可以拿到均勻的分區對應的數據；

? ? ? ?經過Shuffle之后可以將相同分區的數據分發到相同的節點，此過程和hudi的設計有關，hudi是一個分布式集群計算，它最終在數據刷盤的時候是按照分區進行pipeline計算的，這時候如果多個物理節點存在相同分區就會造成寫鎖的搶占影響效率；

? ? ? ?在此過程中我們可以對數據做合并策略優化，相同key的數據進行合并，只保留策略訴求的數，從而減少hudi的計算量；

? ? ? ?拿到了需要更新的數據，我們要知道哪條記錄更新到哪個文件中就需要用到索引檢索服務，合理的選擇索引可以提升數據與文件的匹配速度；

? ? ? ?最終將記錄寫入文件的時候還可以添加丟棄策略，比如文件中已經有更新版本的數據了，就可以丟棄本次記錄，從而進一步提升寫效率。

? ? ? ?經過一系列的操作和優化之后，我們就可以將數據寫入到集群，之后可以通過Hive的元數據掛載成普通表進行使用。

? ? ? ?對于存儲結構，Partition的目錄結構就是我們的hive分區結構，Base是我們的Hdfs存儲路徑。

? ? ? ?在了解Hudi的架構(骨架)、計算過程(大動脈)、存儲結構(細胞)之后，我們會思考Hudi究竟是什么呢?

? ? ? ?初衷是為了解決離線模型更新的問題，以存儲的方式來實現，因此是一個數據存儲解決方案；

? ? ? ?為了實現數據更新需要用到計算，Hudi借用了當前成熟的計算方案來實現自己的架構，所以算是集成了計算引擎。

? ? ? ?03如何使用Hudi解決業務問題

? ? ? ?簡單回顧一下前面提到的痛點：

? ? ? ?計算數據量大 + 計算時間長 + 同步任務是鏈路根節點，造成SLA壓力大

? ? ? ?回刷周期長 + 技術方案單一，導致資源浪費嚴重、修復效率低

? ? ? ?1. 挑戰一：基于Hudi的模型設計

? ? ? ?我們的訴求是使用Hudi來解決時效性和效率問題，然而Hudi和離線的模型設計是不一樣的，要避免思維的慣性和認知的偏差。

? ? ? ?比如，數倉分區設計：

? ? ? ?讓數據的組織形式更加匹配業務形態，在使用的時候更加易于理解，易于使用

? ? ? ?在技術層面，分區用來做數據裁剪，進而提升查詢效率

? ? ? ?小文件合并優化：

? ? ? ?當前hdfs的架構設計下，系統過多的小文件會影響集群的穩定性

? ? ? ?小文件太多會啟動過多的任務，從而降低集群的任務并行度

? ? ? ?然而，在Hudi場景下，除了數倉的模型設計規范，還需要考慮以下幾點。

? ? ? ?數倉分區設計：

? ? ? ?分區與Hudi寫數據的并發有關

? ? ? ?分區是解決寫傾斜的處理手段之一

? ? ? ?小文件合并優化：

? ? ? ?文件越小更新效率越高

? ? ? ?早期Hudi更新單個數據文件的時候是順序的，如果文件過多等待的排隊時間會變長，要取舍排隊和更新時間的平衡

? ? ? ?從我們的痛點出發，設計的時候會更多的考慮寫的效率，因為寫數據要與磁盤交互，效率比較低，所以設計思路有兩點：減少數據量和提升寫效率。

? ? ? ?基于減流量、寫效率的指導思想，我們基于Hudi的數據模型設計會考慮以下幾方面。

? ? ? ?主鍵&分區設計

? ? ? ?- 主鍵是確定數據記錄和對其進行增刪改的根本依據，因此需要深刻的理解業務并以此為依據設計合理的穩定的主鍵，否則當主鍵改變時，需要重新構建數據，成本較高；

? ? ? ?- 主鍵是索引的生成依據，當主鍵改變時，需要重新構建數據；

? ? ? ?- 分區決定了數據寫到哪個目錄，在哪個目錄內更新，如果分區的設計發生改變，相同主鍵的數據會被寫入到不同的目錄中，造成數據查詢時數據重復，當分區改變時，需要重新構建數據；

? ? ? ?- Hudi的分區數量可以用來控制pipeline的并發量。

? ? ? ?合并&索引策略

? ? ? ?- 通過數據的合并策略可以減少Hudi處理的量，從而提升處理效率；

? ? ? ?- 索引策略是定位key與文件關系的依據，快速的定位策略可以更快的完成文件查找，提升Hudi效率。

? ? ? ?并發&丟棄策略

? ? ? ?- 分區是提升并發的手段之一；

? ? ? ?- 在真正寫文件時，Hudi會對比待處理數據與已存在數據的的狀態，這樣亂序、重復數據直接被丟棄掉。

? ? ? ?基于寫模型設計，在數據同步的場景，可將數據模型設計如上圖。

? ? ? ?2. 挑戰二：集中毛刺更新

? ? ? ?快手會在節假日做活動，這時候關系數據就會成倍于日常的增長，預熱期間數據開始爬坡式增長，活動期數據增長速度達到頂峰，活動結尾數據增長變緩。

? ? ? ?基于三段式的增長趨勢，在實現上我們也面臨了三個階段的挑戰：數據開始增長，程序處理壓力變大，收到預警；隨著預熱進行數據持續變大，程序的處理能力出現瓶頸，任務開始失敗；數據持續變大積壓，同時失敗原因是處理失敗，所以即使重啟也不能完成數據處理，造成需求支持失敗。

? ? ? ?針對以上三個階段的問題做了以下應對：

? ? ? ?減少Hudi數據處理量

? ? ? ?- 通過業務數據分析發現，在活動期間有用戶參加活動后取消關系的操作，設置合并策略可以減少Hudi的數據處理量；

? ? ? ?- 通過設置丟棄策略可以減少亂序、重復數據的處理，提高Hudi的寫文件效率。

? ? ? ?提升索引的效率&穩定性

? ? ? ?- 選用分區布隆索引，key與文件的映射關系存儲在文件中，系統重啟、任務發布時可保證數據正確性；

? ? ? ?- 通過分區個數控制單分區的數據量，因為單分區的索引大小可控，索引加載效率可控；

? ? ? ?- 索引大小可控，索引在內存中占用的比例可控，可提升執行程序的穩定性。

? ? ? ?提升寫效率

? ? ? ?- 第一階段為解決并發問題， 采用user_id做mod來控制并發度，讓程序在平峰時可以穩定運行；

? ? ? ?- 第二階段發現個別分區有明顯長尾效應，發現是大V分區數據傾斜，所以采用user_id + follow_id做mod來控制并發，解決傾斜長尾問題；

? ? ? ?- 早期為提升寫文件效率設置單個小文件大小為128M，后來出現長尾效應后發現Hudi在執行數據更新時在一個分區內是一個個文件排隊更新的，這時候如果小文件過多會出現排隊時間較長的情況（新版本已經可以設置單分區的寫文件并發量）；

? ? ? ?- 需要平衡設計文件更新時間和文件執行排隊時間的最優解。

? ? ? ?分區的改變需要重新構建數據，所以一定要在模型設計時深刻的理解業務做好規劃，盡量不要出現邊開飛機邊換發動機的情況。

? ? ? ?3. 挑戰三：數據回刷局部更新

? ? ? ?已經解決了基礎數據大數據量更新的復雜場景，還希望在處理數據回刷局部更新問題時，能解決研發效率問題，形成一套標準化的可以復用的解決方案。

? ? ? ?訴求是有一份業務數據，包含日期分區、主鍵設備ID、渠道屬性，在01~03號的時候渠道為SEM，在04號的時候希望將數據更新為PinPai。

? ? ? ?經過探索后，我們最終形成了離線 + 實時 + Hudi的通用解決方案。通過回刷補數的案例來說明。

? ? ? ?因為是補數場景所以暫時不需要所有的例行都是用實時的方式生成Hudi可識別的數據結構，因此日常生產可以通過離線批處理的方式生成Hudi可識別的存儲結構就可以。當需要進行數據修復的時候生成需要更新的記錄即可(Hudi目前是按行整體更新的)，比如右上圖的修復記錄。將修復數據傳遞給實時的Hudi處理程序，對結果數據直接更新即可。修復數據是通過更高的版本來覆蓋例行版本，比如例行版本號為0，修復版本號為20210503，其原理是合并&丟棄策略。對于對時效要求高的需求，可以直接從實時數據源采集數據，通過Hudi實時處理，生成下游可用的結果表。

? ? ? ?通過以上的架構我們可以實現對高時效、補數回刷的場景的覆蓋，同時也沉淀了一套通用的模板，進而提升了整體的研發效率。

? ? ? ?4. 挑戰四：Hudi保障

? ? ? ?通過數據同步、補數回刷場景的實踐，Hudi已經解決了我們的業務痛點，也可以提升我們的研發效率。然而初期業務上線時仍有一些擔心，比如如何及時發現問題、定位問題、確保數據準確性？我們通過如下方法來提供保障。

? ? ? ?時效性：將整個數據流程分成6個階段5個流轉過程，當收到監控預警時可以根據預警的流轉階段第一時間識別哪個階段哪個流轉出了問題，從而能第一時間定位問題發生在哪里，進行問題排查；

? ? ? ?準確性：通過探針每隔10分鐘從業務數據抽取10條數據與Row Tables做對比，如果95%一致則通過、90%以上介入驗證、90%以下則進行業務阻斷，人工確認問題或修復問題后再恢復任務；

? ? ? ?流程&設計：Hudi的模型設計和數倉的模型設計有一些差異，會對模型設計進行嚴格評審，對開發、測試、上線、監控配置流程做嚴格的審查。