1. 應(yīng)用背景及痛點(diǎn)介紹

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

針對(duì)數(shù)倉(cāng)現(xiàn)有基礎(chǔ)架構(gòu)存在的問(wèn)題，我們分析了目前影響成本和效率的主要因素如下：

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

為了解決上述問(wèn)題，保證數(shù)倉(cāng)的降本提效目標(biāo)，我們決定引入數(shù)據(jù)湖來(lái)重構(gòu)數(shù)倉(cāng)架構(gòu)，架構(gòu)如下：

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

2. 技術(shù)方案選型

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

3. 問(wèn)題與解決方案

3.1.增量數(shù)據(jù)字段對(duì)齊問(wèn)題

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

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

3.2 全球存儲(chǔ)兼容性問(wèn)題

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

3.3 云主機(jī)時(shí)區(qū)統(tǒng)一問(wèn)題

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

3.4 升級(jí)新版本問(wèn)題

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

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

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

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

3.6 數(shù)據(jù)特性適應(yīng)問(wèn)題

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

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

4. 上線收益

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

4.1 成本方面

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

4.2 效率方面

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

4.3 穩(wěn)定性層面

程序穩(wěn)定性層面暫時(shí)沒(méi)有詳細(xì)評(píng)估，結(jié)合實(shí)際場(chǎng)景說(shuō)下目前情況：

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

4.4 查詢性能層面

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

5. 總結(jié)與展望

從數(shù)據(jù)湖上線和測(cè)試過(guò)程來(lái)看，目前數(shù)據(jù)湖能解決我們的一些數(shù)倉(cāng)痛點(diǎn)，但是依然存在一些問(wèn)題。

總結(jié)如下

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

展望如下

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

以上就是Apache Hudi基于華米科技應(yīng)用湖倉(cāng)一體化改造 的詳細(xì)內(nèi)容，更多關(guān)于Apache Hudi華米科技應(yīng)用改造的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論