徐昱
Apache Hudi Contributor
華米高級大數據開發工程師
巨東東
華米大數據開發工程師
1. 應用背景及痛點介紹
華米科技是一家基於雲的健康服務提供商，擁有全球領先的智能可穿戴技術。在華米科技，數據建設主要圍繞兩類數據：設備數據和APP數據，這些數據存在延遲上傳、更新頻率高且廣、可刪除等特性，基於這些特性，前期數倉ETL主要採取歷史全量+增量模式來每日更新數據。隨着業務的持續發展，現有數倉基礎架構已經難以較好適應數據量的不斷增長，帶來的顯著問題就是成本的不斷增長和產出效率的降低。
針對數倉現有基礎架構存在的問題，我們分析了目前影響成本和效率的主要因素如下：
•更新模式過重，存在較多數據的冗餘更新增量數據的分布存在長尾形態，故每日數倉更新需要加載全量歷史數據來做增量數據的整合更新，整個更新過程存在大量歷史數據的冗餘讀取與重寫，帶來的過多的成本浪費，同時影響了更新效率；•回溯成本高，多份全量存儲帶來的存儲浪費，數倉設計中為了保證用戶可以訪問數據某個時間段的歷史狀態，會將全量數據按照更新日期留存多份，故大量未變化的歷史冷數據會被重複存儲多份，帶來存儲浪費；
為了解決上述問題，保證數倉的降本提效目標，我們決定引入數據湖來重構數倉架構，具體如下：
•業務數據源實時接入Kafka，Flink接Kafka構建ODS實時增量數據層，實時ODS增量層主要作用有兩方面：•依賴ODS實時增量數據（保留原始格式，不做清洗轉化）每日離線入湖來構建ODS層離線湖倉，ODS層數據後續作為業務數據的備份、滿足DWD層全量數據重做需求；•對ODS實時增量數據進行清洗、轉換，編碼後，每日增量數據離線寫入DWD層，構建DWD層離線湖倉；•DWS層定義為主題公共寬表層，主要是對DWD層和DIM維度層各表信息，根據業務需求做多表關聯轉換整合，為業務和分析人員提供更易用的模型數據•OLAP層會提供強大的數據快速查詢能力，作為對外的統一查詢入口，用戶直接通過OLAP引擎來即席查詢分析湖倉中所有的表數據•ADS層會依賴其他各層數據來對業務提供定製化的數據服務
2. 技術方案選型
基於上述我們比較關心的指標進行對比。Hudi可以很好的在任務執行過程中進行小文件合併，大大降低了文件治理的複雜度，依據業務場景所需要的原子語義、小文件管理複雜度以及社區活躍度等方面綜合考量，我們選擇Hudi來進行湖倉一體化改造。
3. 問題與解決方案3.1.增量數據字段對齊問題
華米數據云端由於業務原因會產生表Schema變更需求，從而避免因Schema變更而重做歷史Base數據帶來的高額計算成本。但由於新增產生的數據實體字段相對位置的亂序問題，導致入湖同步Hive的過程中產生異常。針對該問題，華米大數據團隊也在和社區聯動，解決數據字段對齊問題。在社區支持更完善的Schema Evolution之前，當前華米大數據團隊的解決方案為：根據歷史Base數據的Schema順序重新對增量數據Schema順序做編排，然後統一增量入湖。具體處理流程如下圖所示：歷史Base數據的Schema順序為{id, fdata, tag, uid}，增量數據的Schema{id, fdata, extract, tag, uid}，可見新增extract字段順序打亂了原先歷史Base數據的Schema，可以根據所讀取的歷史數據Schema順序對新增數據進行調整：
將{id, fdata, extract, tag, uid}變更為{id, fdata, tag, uid, extract}，然後調用Schema Evolution給歷史Base數據的Schema添加一個extract字段，最終將調整後的增量數據寫入歷史Base。
3.2 全球存儲兼容性問題
華米大數據存儲涉及多種存儲（HDFS，S3，KS3），華米大數據團隊新增對KS3存儲的支持併合入社區代碼，在Hudi0.9版本後可以支持KS3存儲。
3.3 雲主機時區統一問題
由於華米全球各個數據中心採用按需方式進行節點擴容，申請得到的雲主機可能會出現節點時區不一致，從而會造成commit失敗，我們對Hudi源碼進行了改造，在hudi源碼中統一了Timeline的時區（UTC）時間來保證時區統一，避免commitTime回溯導致的Commit失敗。
3.4 升級新版本問題
在Hudi0.9升級到0.10版本中，會發現出現版本因version不一致造成的數據更新失敗問題。出現的不一致問題已經反饋至社區，社區相關同學正在解決，現在我們暫時使用重建元數據表（直接刪除metadata目標）來解決該問題，再次執行作業時，Hudi會自動重新構建元數據表。
3.5 多分區Upsert性能問題
Hudi on Spark需要根據增量數據所在的分區採集文件的索引文件，更新分區過多的情況下，性能較差。針對這一問題，目前我們通過兩個層面來進行處理：
•推進上游進行數據治理，儘可能控制延遲數據，重複數據的上傳•代碼層進行優化，設定時間範圍開關，控制每日入湖的數據在設定時間範圍內，避免延遲較久的極少量數據入湖降低表每日更新性能；對於延遲較久的數據匯集後定期入湖，從而降低整體任務性能開銷
3.6 數據特性適應問題
從數據入湖的性能測試中來看，Hudi性能跟數據組織的策略有較大的關係，具體體現在以下幾個方面：
•聯合主鍵多字段的順序決定了Hudi中的數據排序，影響了後續數據入湖等性能；主鍵字段的順序決定了hudi中數據的組織方式，排序靠近的數據會集中分布在一起，可利用這個排序特性結合更新數據的分布特性，以儘可能減少入湖命中的base文件數據，提升入湖性能；•數據湖中文件塊記錄條數與布隆過濾器參數的適應關係，影響了索引構建的性能；在使用布隆過濾器時，官方給出的默認存儲在布隆過濾器中的條目數為6萬(假設maxParquetFileSize為128MB，averageRecordSize為1024)，如果數據較為稀疏或者數據可壓縮性比較高的話，每個文件塊可能會存儲的記錄數遠大於6萬，從而導致每次索引查找過程中會掃描更多的base文件，非常影響性能，建議根據業務數據的特性適當調整該值，入湖性能應該會有較好的提升；
4. 上線收益
從業務場景和分析需求出發，我們主要對比了實時數據湖模式和離線數據湖模式的成本與收益，實時成本遠高於離線模式。鑑於目前業務實時需求並不是很高，故華米數倉在引入數據湖時暫採取Hudi + Spark離線更新模式來構建湖倉ODS原始層和DWD明細層，從測試對比和上線情況來看，收益總結如下：
4.1 成本方面
引入Hudi數據湖技術後，數據倉庫整體成本有一定程度的下降，預計會降低1/4~1/3的費用。主要在於利用Hudi數據湖提供的技術能力，可以較好的解決應用背景部分闡述的兩大痛點，節約數倉Merge更新與存儲兩部分的費用開銷。
4.2 效率方面
Hudi利用索引更新機制避免了每次全量更新表數據，使得數倉表每次更新避免了大量的冗餘數據的讀取與寫入操作，故而表的更新效率有了一定的提升。從我們數倉+BI報表整體鏈條層面來看，整體報表產出時間會有一定程度的提前。
4.3 穩定性層面
程序穩定性層面暫時沒有詳細評估，結合實際場景說下目前情況：
•中大表更新引入Hudi會相對較為穩定。基於Aws Spot Instance機制，對於數據量過大的表，每次全量shuffle的數據量過大，會導致拉取數據的時間過長，Spot機器掉線，程序重試甚至失敗，或者內存原因導致的fetch失敗，造成任務的不穩定。引入Hudi後，可以很大程度減少每次shuffle的數據量，有效緩解這一問題；•Hudi的Metadata表機制功能穩定性待繼續完善，開啟後影響程序穩定性。考慮提升程序性能，前期開啟了Metadata表，程序運行一段時間後會出現報錯，影響錯誤已經反饋給社區，暫時關閉該功能，待穩定後再開啟；
4.4 查詢性能層面
Hudi寫入文件時根據主鍵字段排序後寫入，每個Parquet文件中記錄是按照主鍵字段排序，在使用Hive或者Spark查詢時，可以很好的利用Parquet謂詞下推特性，快速過濾掉無效數據，相對之前的數倉表，有更好的查詢效率。
5. 總結與展望
從數據湖上線和測試過程來看，目前數據湖能解決我們的一些數倉痛點，但是依然存在一些問題。
總結如下
•Hudi on Spark 布隆過濾器查找與構建索引過程性能尚待提升，由於華米數據分布特性（更新頻率多，範圍廣），現階段部分大表的更新性能提升有待加強；•Metadata表的使用是為了提升整體入湖性能，但目前由於穩定性問題暫時關閉，後續會持續關注社區Metadata表的改進；•更新數據分布特性的研究至關重要，決定着如何組織數據湖中的數據分布，較大影響着任務性能，這塊需要後續做進一步優化；
展望如下
•利用Flink + Hudi技術棧搭建實時數倉，構建kafka -> ods -> dwd -> olap的實時數據鏈條，滿足業務近實時需求•索引優化方案 -> HBase構建二級索引
推薦閱讀
基於Hudi的流式CDC實踐一：聽說你準備了面試題？如何將數據更快導入Apache Hudi？Flink + Hudi，構架倉湖一體化解決方案基於Apache Hudi 的CDC數據入湖內附PPT下載｜萬字乾貨！阿里雲基於Apache Hudi構建Lakehouse實踐探索
留言列表