1. 應用背景及痛點介紹

華米科技是一家基于云的健康服務提供商，擁有全球領先的智能可穿戴技術。在華米科技，數(shù)據(jù)建設主要圍繞兩類數(shù)據(jù)：設備數(shù)據(jù)和APP數(shù)據(jù)，這些數(shù)據(jù)存在延遲上傳、更新頻率高且廣、可刪除等特性，基于這些特性，前期數(shù)倉ETL主要采取歷史全量+增量模式來每日更新數(shù)據(jù)。隨著業(yè)務的持續(xù)發(fā)展，現(xiàn)有數(shù)倉基礎架構已經(jīng)難以較好適應數(shù)據(jù)量的不斷增長，帶來的顯著問題就是成本的不斷增長和產出效率的降低。

針對數(shù)倉現(xiàn)有基礎架構存在的問題，我們分析了目前影響成本和效率的主要因素如下：

• 更新模式過重，存在較多數(shù)據(jù)的冗余更新增量數(shù)據(jù)的分布存在長尾形態(tài)，故每日數(shù)倉更新需要加載全量歷史數(shù)據(jù)來做增量數(shù)據(jù)的整合更新，整個更新過程存在大量歷史數(shù)據(jù)的冗余讀取與重寫，帶來的過多的成本浪費，同時影響了更新效率；
• 回溯成本高，多份全量存儲帶來的存儲浪費，數(shù)倉設計中為了保證用戶可以訪問數(shù)據(jù)某個時間段的歷史狀態(tài)，會將全量數(shù)據(jù)按照更新日期留存多份，故大量未變化的歷史冷數(shù)據(jù)會被重復存儲多份，帶來存儲浪費；

為了解決上述問題，保證數(shù)倉的降本提效目標，我們決定引入數(shù)據(jù)湖來重構數(shù)倉架構，架構如下：

• 業(yè)務數(shù)據(jù)源實時接入Kafka，F(xiàn)link接Kafka構建ODS實時增量數(shù)據(jù)層，實時ODS增量層主要作用有兩方面：
  • 依賴ODS實時增量數(shù)據(jù)（保留原始格式，不做清洗轉化）每日離線入湖來構建ODS層離線湖倉，ODS層數(shù)據(jù)后續(xù)作為業(yè)務數(shù)據(jù)的備份、滿足DWD層全量數(shù)據(jù)重做需求；
  • 對ODS實時增量數(shù)據(jù)進行清洗、轉換，編碼后，每日增量數(shù)據(jù)離線寫入DWD層，構建DWD層離線湖倉；
• DWS層定義為主題公共寬表層，主要是對DWD層和DIM維度層各表信息，根據(jù)業(yè)務需求做多表關聯(lián)轉換整合，為業(yè)務和分析人員提供更易用的模型數(shù)據(jù)
• OLAP層會提供強大的數(shù)據(jù)快速查詢能力，作為對外的統(tǒng)一查詢入口，用戶直接通過OLAP引擎來即席查詢分析湖倉中所有的表數(shù)據(jù)
• ADS層會依賴其他各層數(shù)據(jù)來對業(yè)務提供定制化的數(shù)據(jù)服務

2. 技術方案選型

基于上述我們比較關心的指標進行對比。Hudi可以很好的在任務執(zhí)行過程中進行小文件合并，大大降低了文件治理的復雜度，依據(jù)業(yè)務場景所需要的原子語義、小文件管理復雜度以及社區(qū)活躍度等方面綜合考量，我們選擇Hudi來進行湖倉一體化改造。

3. 問題與解決方案

3.1.增量數(shù)據(jù)字段對齊問題

華米數(shù)據(jù)云端由于業(yè)務原因會產生表Schema變更需求，從而避免因Schema變更而重做歷史Base數(shù)據(jù)帶來的高額計算成本。但由于新增產生的數(shù)據(jù)實體字段相對位置的亂序問題，導致入湖同步Hive的過程中產生異常。針對該問題，華米大數(shù)據(jù)團隊也在和社區(qū)聯(lián)動，解決數(shù)據(jù)字段對齊問題。在社區(qū)支持更完善的Schema Evolution之前，當前華米大數(shù)據(jù)團隊的解決方案為：根據(jù)歷史Base數(shù)據(jù)的Schema順序重新對增量數(shù)據(jù)Schema順序做編排，然后統(tǒng)一增量入湖。具體處理流程如下圖所示：歷史Base數(shù)據(jù)的Schema順序為{id, fdata, tag, uid}，增量數(shù)據(jù)的Schema{id, fdata, extract, tag, uid}，可見新增extract字段順序打亂了原先歷史Base數(shù)據(jù)的Schema，可以根據(jù)所讀取的歷史數(shù)據(jù)Schema順序對新增數(shù)據(jù)進行調整：

將{id, fdata, extract, tag, uid}變更為{id, fdata, tag, uid, extract}，然后調用Schema Evolution給歷史Base數(shù)據(jù)的Schema添加一個extract字段，最終將調整后的增量數(shù)據(jù)寫入歷史Base。

3.2 全球存儲兼容性問題

華米大數(shù)據(jù)存儲涉及多種存儲（HDFS，S3，KS3），華米大數(shù)據(jù)團隊新增對KS3存儲的支持并合入社區(qū)代碼，在Hudi0.9版本后可以支持KS3存儲。

3.3 云主機時區(qū)統(tǒng)一問題

由于華米全球各個數(shù)據(jù)中心采用按需方式進行節(jié)點擴容，申請得到的云主機可能會出現(xiàn)節(jié)點時區(qū)不一致，從而會造成commit失敗，我們對Hudi源碼進行了改造，在hudi源碼中統(tǒng)一了Timeline的時區(qū)（UTC）時間來保證時區(qū)統(tǒng)一，避免commitTime回溯導致的Commit失敗。

3.4 升級新版本問題

在Hudi0.9升級到0.10版本中，會發(fā)現(xiàn)出現(xiàn)版本因version不一致造成的數(shù)據(jù)更新失敗問題。出現(xiàn)的不一致問題已經(jīng)反饋至社區(qū)，社區(qū)相關同學正在解決，現(xiàn)在我們暫時使用重建元數(shù)據(jù)表（直接刪除metadata目標）來解決該問題，再次執(zhí)行作業(yè)時，Hudi會自動重新構建元數(shù)據(jù)表。

3.5 多分區(qū)Upsert性能問題

Hudi on Spark需要根據(jù)增量數(shù)據(jù)所在的分區(qū)采集文件的索引文件，更新分區(qū)過多的情況下，性能較差。針對這一問題，目前我們通過兩個層面來進行處理：

• 推進上游進行數(shù)據(jù)治理，盡可能控制延遲數(shù)據(jù)，重復數(shù)據(jù)的上傳
• 代碼層進行優(yōu)化，設定時間范圍開關，控制每日入湖的數(shù)據(jù)在設定時間范圍內，避免延遲較久的極少量數(shù)據(jù)入湖降低表每日更新性能；對于延遲較久的數(shù)據(jù)匯集后定期入湖，從而降低整體任務性能開銷

3.6 數(shù)據(jù)特性適應問題

從數(shù)據(jù)入湖的性能測試中來看，Hudi性能跟數(shù)據(jù)組織的策略有較大的關系，具體體現(xiàn)在以下幾個方面：

• 聯(lián)合主鍵多字段的順序決定了Hudi中的數(shù)據(jù)排序，影響了后續(xù)數(shù)據(jù)入湖等性能；主鍵字段的順序決定了hudi中數(shù)據(jù)的組織方式，排序靠近的數(shù)據(jù)會集中分布在一起，可利用這個排序特性結合更新數(shù)據(jù)的分布特性，以盡可能減少入湖命中的base文件數(shù)據(jù)，提升入湖性能；
• 數(shù)據(jù)湖中文件塊記錄條數(shù)與布隆過濾器參數(shù)的適應關系，影響了索引構建的性能；在使用布隆過濾器時，官方給出的默認存儲在布隆過濾器中的條目數(shù)為6萬(假設maxParquetFileSize為128MB，averageRecordSize為1024)，如果數(shù)據(jù)較為稀疏或者數(shù)據(jù)可壓縮性比較高的話，每個文件塊可能會存儲的記錄數(shù)遠大于6萬，從而導致每次索引查找過程中會掃描更多的base文件，非常影響性能，建議根據(jù)業(yè)務數(shù)據(jù)的特性適當調整該值，入湖性能應該會有較好的提升；

4. 上線收益

從業(yè)務場景和分析需求出發(fā)，我們主要對比了實時數(shù)據(jù)湖模式和離線數(shù)據(jù)湖模式的成本與收益，實時成本遠高于離線模式。鑒于目前業(yè)務實時需求并不是很高，故華米數(shù)倉在引入數(shù)據(jù)湖時暫采取Hudi + Spark離線更新模式來構建湖倉ODS原始層和DWD明細層，從測試對比和上線情況來看，收益總結如下：

4.1 成本方面

引入Hudi數(shù)據(jù)湖技術后，數(shù)據(jù)倉庫整體成本有一定程度的下降，預計會降低1/4~1/3的費用。主要在于利用Hudi數(shù)據(jù)湖提供的技術能力，可以較好的解決應用背景部分闡述的兩大痛點，節(jié)約數(shù)倉Merge更新與存儲兩部分的費用開銷。

4.2 效率方面

Hudi利用索引更新機制避免了每次全量更新表數(shù)據(jù)，使得數(shù)倉表每次更新避免了大量的冗余數(shù)據(jù)的讀取與寫入操作，故而表的更新效率有了一定的提升。從我們數(shù)倉+BI報表整體鏈條層面來看，整體報表產出時間會有一定程度的提前。

4.3 穩(wěn)定性層面

程序穩(wěn)定性層面暫時沒有詳細評估，結合實際場景說下目前情況：

• 中大表更新引入Hudi會相對較為穩(wěn)定?；贏ws Spot Instance機制，對于數(shù)據(jù)量過大的表，每次全量shuffle的數(shù)據(jù)量過大，會導致拉取數(shù)據(jù)的時間過長，Spot機器掉線，程序重試甚至失敗，或者內存原因導致的fetch失敗，造成任務的不穩(wěn)定。引入Hudi后，可以很大程度減少每次shuffle的數(shù)據(jù)量，有效緩解這一問題；
• Hudi的Metadata表機制功能穩(wěn)定性待繼續(xù)完善，開啟后影響程序穩(wěn)定性?？紤]提升程序性能，前期開啟了Metadata表，程序運行一段時間后會出現(xiàn)報錯，影響錯誤已經(jīng)反饋給社區(qū)，暫時關閉該功能，待穩(wěn)定后再開啟；

4.4 查詢性能層面

Hudi寫入文件時根據(jù)主鍵字段排序后寫入，每個Parquet文件中記錄是按照主鍵字段排序，在使用Hive或者Spark查詢時，可以很好的利用Parquet謂詞下推特性，快速過濾掉無效數(shù)據(jù)，相對之前的數(shù)倉表，有更好的查詢效率。

5. 總結與展望

從數(shù)據(jù)湖上線和測試過程來看，目前數(shù)據(jù)湖能解決我們的一些數(shù)倉痛點，但是依然存在一些問題。

總結如下

• Hudi on Spark 布隆過濾器查找與構建索引過程性能尚待提升，由于華米數(shù)據(jù)分布特性（更新頻率多，范圍廣），現(xiàn)階段部分大表的更新性能提升有待加強；
• Metadata表的使用是為了提升整體入湖性能，但目前由于穩(wěn)定性問題暫時關閉，后續(xù)會持續(xù)關注社區(qū)Metadata表的改進；
• 更新數(shù)據(jù)分布特性的研究至關重要，決定著如何組織數(shù)據(jù)湖中的數(shù)據(jù)分布，較大影響著任務性能，這塊需要后續(xù)做進一步優(yōu)化；

展望如下

• 利用Flink + Hudi技術棧搭建實時數(shù)倉，構建kafka -> ods -> dwd -> olap的實時數(shù)據(jù)鏈條，滿足業(yè)務近實時需求
• 索引優(yōu)化方案 -> HBase構建二級索引

以上就是Apache Hudi基于華米科技應用湖倉一體化改造 的詳細內容，更多關于Apache Hudi華米科技應用改造的資料請關注本站其它相關文章！

海外穩(wěn)定服務器

版權聲明：本站文章來源標注為YINGSOO的內容版權均為本站所有，歡迎引用、轉載，請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務器上建立鏡像，否則將依法追究法律責任。本站部分內容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學習參考，不代表本站立場，如有內容涉嫌侵權，請聯(lián)系alex-e#qq.com處理。