徐昱

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構建二級索引

PS:如果您覺得閱讀本文對您有幫助，請點一下“推薦”按鈕，您的“推薦”，將會是我不竭的動力！
作者：leesf掌控之中，才會成功；掌控之外，註定失敗。
出處：http://www.cnblogs.com/leesf456/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線，否則保留追究法律責任的權利。
如果覺得本文對您有幫助，您可以請我喝杯咖啡!