阿里云ADB基于Hudi構(gòu)建Lakehouse的實(shí)踐

作者：李少鋒 2022-12-23 16:52:22

今天非常高興能夠借這個(gè)機(jī)會(huì)和大家分享下阿里云 ADB 基于 Apache Hudi 構(gòu)建 Lakehouse 的應(yīng)用與實(shí)踐。

導(dǎo)讀：大家好，我是來自阿里云數(shù)據(jù)庫的李少鋒，現(xiàn)在主要專注于 ADB Hudi & Spark 的研發(fā)以及產(chǎn)品化，今天非常高興能夠借這個(gè)機(jī)會(huì)和大家分享下阿里云 ADB 基于 Apache Hudi 構(gòu)建 Lakehouse 的應(yīng)用與實(shí)踐。

接下來我將分為 3 個(gè)部分給大家介紹今天的議題，首先我會(huì)介紹經(jīng)過將近一年打磨推出的ADB 湖倉版的架構(gòu)以及關(guān)鍵優(yōu)勢，接著會(huì)介紹在支持客戶構(gòu)建 Lakehouse 時(shí)，我們是如何克服基于 Hudi 構(gòu)建千億數(shù)據(jù)入湖的挑戰(zhàn)；最后將介紹基于 ADB 構(gòu)建 Lakehouse 的實(shí)踐。

1、ADB 湖倉版機(jī)構(gòu)與關(guān)鍵優(yōu)勢

首先先來介紹下 ADB 湖倉版架構(gòu)及其關(guān)鍵優(yōu)勢。

一體版本，我們稱為 ADB 湖倉版。湖倉版在數(shù)據(jù)全鏈路的「采存算管用」5 大方面都進(jìn)行了全面升級。

在「采集」方面，我們推出了數(shù)據(jù)管道 APS 功能，可以一鍵低成本接入數(shù)據(jù)庫、日志、大數(shù)據(jù)中的數(shù)據(jù)。

在「存儲(chǔ)」方面，我們除了新增 Hudi 格式的外表能力，也對內(nèi)部存儲(chǔ)進(jìn)行了升級改造。通過只存一份數(shù)據(jù)，同時(shí)滿足離線、在線 2 類場景。

在「計(jì)算」方面，我們對自研的 XIHE BSP SQL 引擎進(jìn)行容錯(cuò)性、運(yùn)維能力等方面的提升，同時(shí)引入開源 Spark 引擎滿足更復(fù)雜的離線處理場景和機(jī)器學(xué)習(xí)場景。

在「管理」方面，我們推出了統(tǒng)一的元數(shù)據(jù)管理服務(wù)，統(tǒng)一湖倉元數(shù)據(jù)及權(quán)限，讓湖倉數(shù)據(jù)的流通更順暢。

在「應(yīng)用」方面，除了通過SQL方式的BI分析應(yīng)用外，還支持基于 Spark 的 AI 應(yīng)用。

我們希望通過資源一體化和體驗(yàn)一體化，2 個(gè)一體化能力，幫助客戶實(shí)現(xiàn)降本增效。資源一體化是指一份數(shù)據(jù)、極致彈性和融合引擎。體驗(yàn)一體化是指統(tǒng)一的計(jì)費(fèi)單位、數(shù)據(jù)管道、數(shù)據(jù)管理和數(shù)據(jù)訪問。

在 ADB 湖倉版中，首先將一份全量數(shù)據(jù)存在低成本高吞吐存儲(chǔ)介質(zhì)上，低成本離線處理場景直接讀寫低成本存儲(chǔ)介質(zhì)，降低數(shù)據(jù)存儲(chǔ)和數(shù)據(jù) IO 成本，保證高吞吐。其次將實(shí)時(shí)數(shù)據(jù)存在單獨(dú)的存儲(chǔ) IO 節(jié)點(diǎn)（EIU）上，保證「行級」的數(shù)據(jù)實(shí)時(shí)性，同時(shí)對全量數(shù)據(jù)構(gòu)建索引，并通過 Cache 能力對數(shù)據(jù)進(jìn)行加速，滿足百 ms 級高性能在線分析場景。因此，數(shù)據(jù)湖中的數(shù)據(jù)可以在數(shù)倉中加速訪問；而數(shù)倉中的數(shù)據(jù)，也可以利用離線資源進(jìn)行計(jì)算。

極致彈性通過彈得好、彈得起、彈得快三個(gè)特點(diǎn)，貼合業(yè)務(wù)負(fù)載，保證查詢性能，降低資源成本。

彈得好是指提供了適合在線分析業(yè)務(wù)的分時(shí)彈性和適合離線處理、機(jī)器學(xué)習(xí)的按需彈性，完美貼合業(yè)務(wù)負(fù)載，滿足業(yè)務(wù)需求。

彈得起是指基于神龍 + ECS + ECI構(gòu)建了三級資源庫存供給能力，保障彈性資源交付率超過 95%。

彈得快是指資源池化后通過緩存加速等技術(shù)，彈性啟動(dòng)效率可以達(dá)到 10s 內(nèi)。

支撐離線、在線兩類場景的背后，除了剛才提到的一份數(shù)據(jù)。還有自研的XIHE融合計(jì)算引擎，同時(shí)提供 MPP 模式和 BSP 模式，并提供自動(dòng)切換能力。

自動(dòng)切換能力是指當(dāng)查詢使用 MPP 模式無法在一定耗時(shí)內(nèi)完成時(shí)，系統(tǒng)會(huì)自動(dòng)切換為 BSP模式進(jìn)行執(zhí)行。未來，我們還將在一個(gè)查詢中，根據(jù)算子特點(diǎn)部分算子采用 MPP 模式，部分算子采用 BSP 模式，兼顧高性能和高吞吐，提供更智能的查詢體驗(yàn)。

同時(shí)融合引擎為提供資源利用率提供了可能，通常離線處理發(fā)生在晚上，在線分析發(fā)生在白天，一份資源可以同時(shí)支持 2 類場景，通過錯(cuò)峰提升資源利用率。

最后再介紹一下統(tǒng)一數(shù)據(jù)管道APS。數(shù)據(jù)快速接入，是數(shù)據(jù)分析的第一步，也是最容易流失客戶的一步。但我們發(fā)現(xiàn)數(shù)據(jù)接入面臨體驗(yàn)差、成本高、門檻高等痛點(diǎn)。

所以，我們決定跟其它接入工具做好深度優(yōu)化的同時(shí)，面向中小客戶，構(gòu)建一個(gè)統(tǒng)一數(shù)據(jù)管道 APS，底層基于 Flink 實(shí)時(shí)引擎，提供易用性好、低延時(shí)、低成本的數(shù)據(jù)接入體驗(yàn)。

對于湖倉中的表元數(shù)據(jù)，ADB 做了統(tǒng)一元數(shù)據(jù)服務(wù)，湖倉中的元數(shù)據(jù)/權(quán)限可互通，可通過不同引擎自由訪問湖倉數(shù)據(jù)；而對于湖倉數(shù)據(jù)，為了屏蔽底層數(shù)據(jù)存儲(chǔ)格式的差異，便于第三方引擎集成，ADB 提供了面向內(nèi)存列存格式 Arrow，滿足對吞吐的要求，對于內(nèi)部存儲(chǔ)，已經(jīng)通過 Arrow 格式完成 Spark 對接，提供高吞吐能力。

自研是打造技術(shù)深度的基礎(chǔ)，但同時(shí)我們積極擁抱開源，滿足已經(jīng)生長在開源生態(tài)上的客戶可以更平滑地使用湖倉版。外表類型，在 Parquet/ORC/JSON/CSV 等 Append 類型數(shù)據(jù)格式的基礎(chǔ)上，為支持在對象存儲(chǔ)上低成本 Lakehouse，支持了Apache Hudi，提供近實(shí)時(shí)的更新、刪除能力，滿足客戶對低成本的訴求。

2、基于 Hudi 構(gòu)建千億數(shù)據(jù)入湖的挑戰(zhàn)

以上就是 ADB 湖倉版的架構(gòu)與關(guān)鍵優(yōu)勢，接著介紹基于 Hudi 構(gòu)建千億數(shù)據(jù)入湖的挑戰(zhàn)以及如何我們是如何克服這些挑戰(zhàn)的。

首先我們看下典型的業(yè)務(wù)場景，業(yè)務(wù)源端數(shù)據(jù)通過數(shù)據(jù)采集進(jìn)入阿里云 SLS，然后通過 APS數(shù)據(jù)管道服務(wù)進(jìn)入ADB 湖倉版，基于 ADB 湖倉版之上構(gòu)建日志查詢、日志導(dǎo)出、日志分析等功能。

該業(yè)務(wù)場景有如下典型的特點(diǎn)：

1.高吞吐，單鏈路最高 4GB/s 吞吐，日增數(shù)據(jù)量 350TB，總存儲(chǔ)量超 20PB。

2.數(shù)據(jù)傾斜/熱點(diǎn)嚴(yán)重：源端數(shù)據(jù)傾斜非常嚴(yán)重，從百萬到幾十條數(shù)據(jù)不等。

3.掃描量大：日志查詢的掃描量 50GB ~ 500GB 不等，查詢并發(fā)在 100+。

如果使用數(shù)倉的話會(huì)面臨成本高的問題，另外是數(shù)倉缺少熱點(diǎn)打散能力，只能不斷加資源，瓶頸明顯；最后是數(shù)倉系統(tǒng)資源是固化的，沒有動(dòng)態(tài)彈性能力，或者彈性能力較弱，承載不同客戶查詢需求時(shí)，容易互相干擾，尤其是大客戶的數(shù)據(jù)掃描。

先來看下日志數(shù)據(jù)入湖的技術(shù)架構(gòu)，數(shù)據(jù)從 SLS 讀取，然后通過 Flink 寫入 Hudi，整個(gè)架構(gòu)非常簡單，其中對于 SLS 和 Flink 的狀態(tài)存儲(chǔ)說明如下：

1.SLS 多 Shard 存儲(chǔ)，由 Flink 的多個(gè) Source 算子并行消費(fèi)。

2.消費(fèi)后通過 Sink 算子調(diào)用 Hudi Worker/Writer 寫出到 Hudi（實(shí)際鏈路還存在 Repartition，熱點(diǎn)打散等邏輯）。

3.Flink Checkpoint 后端存儲(chǔ)以及 Hudi 數(shù)據(jù)存儲(chǔ)在OSS。

接著來看下 Flink 寫入 Hudi 的主流程，首先明確 Flink 寫 Hudi 時(shí)會(huì)存在兩種角色，Coordinator 負(fù)責(zé)處理元數(shù)據(jù)，如對 Hudi Instant 的相關(guān)操作，Worker/Writer 負(fù)責(zé)處理數(shù)據(jù)，如寫入數(shù)據(jù)為 parquet 格式，寫入步驟如下：

1.Coordinator 開啟一個(gè) Hudi Instant。

2.Filnk Sink 發(fā)送數(shù)據(jù)給 Hudi Worker 寫出。

3.觸發(fā) Flink Checkpoint 時(shí)，則通過 Sink 算子通知 Worker Flush 數(shù)據(jù)，同時(shí)持久化operator-state。

4.當(dāng) Flink 完成 Checkpoint 持久化時(shí)，通知 Coordinator 提交該 Instant，Coordinator 完成最終提交，寫 commit 文件，數(shù)據(jù)對外可見。

5.提交后會(huì)立即開啟一個(gè)新的 Instant，繼續(xù)上述循環(huán)。

如果把 Flink 寫 Hudi 保證端到端一致性分成兩部分，一部分是 Flink 框架內(nèi)部的，另外一個(gè)部分是與 Hudi 交互的部分。

1.其中步驟 1 到 3 之間是 Flink Checkpoint 邏輯，如果異常在這些步驟上發(fā)生，則認(rèn)為 Checkpoint失敗，觸發(fā) Job 重啟，從上一次 Checkpoint 恢復(fù)，相當(dāng)于兩階段提交的 Precommit 階段失敗，事務(wù)回滾，如果有 Hudi 的 inflight commit，等待 Hudi Rollback 即可，無數(shù)據(jù)不一致問題。

2.當(dāng) 3 到 4 之間發(fā)生異常，則出現(xiàn) Flink 和 Hudi 狀態(tài)不一致。此時(shí) Flink 認(rèn)為 Checkpoint 已結(jié)束，而 Hudi 實(shí)際尚未提交。如果對此情況不做處理，則發(fā)生了數(shù)據(jù)丟失，因?yàn)镕link Checkpoint 完畢后，SLS 位點(diǎn)已經(jīng)前移，而這部分?jǐn)?shù)據(jù)在 Hudi 上并未完成提交，因此容錯(cuò)的重點(diǎn)是如何處理此階段引起的數(shù)據(jù)一致性問題。

3.我們拿一個(gè)例子舉例分析在步驟 3 和 4 之前發(fā)生異常時(shí)，如果保證數(shù)據(jù)一致性。

4.否則認(rèn)為上一次 Instant 執(zhí)行失敗，等待 Rollback 即可，臟數(shù)據(jù)對用戶不可見。

我們舉例分析下在步驟 3 和 4 之間發(fā)生異常時(shí)，是如何保證數(shù)據(jù)一致性的，可以看到對于1615 的 commit 在 Flink 完成 Checkpoint 時(shí)會(huì)將其 instant 信息持久化至 Flink 后端存儲(chǔ)。

從 checkpoint 恢復(fù)時(shí)有如下步驟：

1.Checkpoint 時(shí) Sink 算子 Flush 數(shù)據(jù)及持久化 Instant 的 state。

2.Worker 請求處于 pending 的 Instant，與從 state 恢復(fù)的 Instant 做對比并匯報(bào)給 Coordinator。

3.Coordinator 從 Instant Timeline 中獲取最新的 Instant 信息，并接收所有 Worker 的匯報(bào)。

4.如果 Worker 匯報(bào) Instant 相同，并且不在 Timeline 中已完成的 Instant 中，則表示該 Instant 尚未提交，觸發(fā) Recommit。

經(jīng)過上述步驟可以保證在 Flink 完成 Checkpoint 時(shí)，但對于 Hudi Commit 失敗時(shí)的場景會(huì)進(jìn)行 recommit，從而保證數(shù)據(jù)的一致性。

?接著介紹我們在處理 4GB/s 的高吞吐時(shí)面臨的挑戰(zhàn)，一個(gè)非常大的挑戰(zhàn)就是熱點(diǎn)數(shù)據(jù)處理，我們統(tǒng)計(jì)了 5 分鐘內(nèi)各 Task 處理數(shù)據(jù)的大小，發(fā)現(xiàn)各 Task 處理數(shù)據(jù)從 200W 條到幾十條不等，熱點(diǎn)問題明顯。

而在寫入鏈路中會(huì)根據(jù)分區(qū)字段做 shuffle，同一個(gè)分區(qū)由一個(gè) Task 寫入,對于上述存在的熱點(diǎn)問題會(huì)導(dǎo)致部分TM上的分區(qū)寫入非常慢，導(dǎo)致數(shù)據(jù)延遲/作業(yè)掛掉。

面對寫入熱點(diǎn)問題，我們開發(fā)了熱點(diǎn)打散功能，通過配置指定規(guī)則打散熱點(diǎn)數(shù)據(jù)，同時(shí)可以根據(jù)數(shù)據(jù)流量自動(dòng)更新熱點(diǎn)打散規(guī)則，確保系統(tǒng)的健壯性，可以看到經(jīng)過熱點(diǎn)打散后個(gè) TM 處理的數(shù)據(jù)量/CPU占用/內(nèi)存占用基本相同并且比較平穩(wěn)，作業(yè)穩(wěn)定性也得到了提升。?

?另外一個(gè)挑戰(zhàn)是 OOM，其實(shí)和熱點(diǎn)打散也有很大關(guān)系，我們發(fā)現(xiàn)作業(yè)運(yùn)行時(shí)會(huì)出現(xiàn)OOM，導(dǎo)致作業(yè)掛掉，數(shù)據(jù)延遲上漲，因此我們對堆外/堆內(nèi)內(nèi)存的使用做了比較細(xì)致的梳理，使用內(nèi)存的部分主要集中在：

1.寫 Parquet 文件占用堆外內(nèi)存?。

2.OSS Flush 占用堆外內(nèi)存。

3.單 TM 的 Slot 數(shù)、寫并發(fā)都影響內(nèi)存占用，如每個(gè)寫并發(fā)處理 30-50 Handle，TM 16 并發(fā)，8M row group size 最多占用 6400 M 內(nèi)存。

4.堆內(nèi)內(nèi)存負(fù)載過高導(dǎo)致頻繁Full GC。

我們針對上述分內(nèi)存使用做了優(yōu)化，如：

1.row group size 配置為 4M，減少堆外內(nèi)存占用，同時(shí)將堆外內(nèi)存調(diào)大。

2.close 時(shí)及時(shí)釋放 compressor 占用的內(nèi)存，這部分對 parquet 源碼做了改造。

3.透出堆外內(nèi)存指標(biāo)，增加堆外內(nèi)存監(jiān)控，這部分也是對 parquet 源碼做了改造。

4.源端 source 算子與 Shard 分配更均衡，以此保證各 TM 消費(fèi)的 shard 數(shù)基本均等。

最后一個(gè)比較大的挑戰(zhàn)就是 OSS 限流，云對象存儲(chǔ)（如OSS）對 List 操作不友好，list objects 對 OSS 服務(wù)器壓力較大，如在我們場景下，1500 寫并發(fā)，會(huì)產(chǎn)生 1W QPS list object，OSS 側(cè)目前限流 1K QPS，限流明顯，限流會(huì)導(dǎo)致作業(yè)處理變慢，延遲變高，為解決該問題，我們也梳理了寫入鏈路對 OSS 的請求，在元數(shù)據(jù)鏈路對 OSS 的請求如下：

1.Timeline 構(gòu)建需要 list .hoodie 目錄。

2.Flink CkpMetaData 基于 OSS 傳遞給 Worker。

3.Hadoop-OSS SDK create/exists/mkdir 函數(shù)依賴 getStatus 接口，getStatus 接口現(xiàn)有實(shí)現(xiàn)導(dǎo)致大量 list 請求，其中 getStatus 接口對于不存在的文件，會(huì)額外進(jìn)行一次 list objects 請求確認(rèn) Path 是不是目錄，對 Marker File、partitionMetadata、數(shù)據(jù)文件都會(huì)產(chǎn)生大量的 list objects 請求。

在數(shù)據(jù)鏈路對 OSS 請求如下：先臨時(shí)寫到本地磁盤，再上傳至 OSS，導(dǎo)致本地磁盤寫滿。

針對上述對 OSS 的請求，我們做了如下優(yōu)化，在元數(shù)據(jù)側(cè)：

1.Timeline Based CkpMetaData，將TM請求打到 JM，避免大量 TM 掃描 OSS 文件。

2.Hadoop-OSS SDK，透出直接創(chuàng)建文件的接口，不進(jìn)行目錄檢查。

3.PartitionMetaData 緩存處理，在內(nèi)存中對每個(gè)分區(qū)的元數(shù)據(jù)文件做了緩存處理，盡量減少與 OSS 的交互。

4.Create Marker File 異步處理，異步化處理不阻塞對 Handle 的創(chuàng)建，減少創(chuàng)建 Handle 的成本。

5.開啟 Timeline Based Marker File，這個(gè)是社區(qū)已經(jīng)有的能力，直接開啟即可。

這里額外補(bǔ)充下可能有小伙伴比較好奇為什么開啟 hudi metadata table 來解決云對象存儲(chǔ)的限流問題，我們內(nèi)部做過測試，發(fā)現(xiàn)開啟 metadata table 時(shí)，寫入會(huì)越來越慢，無法滿足高吞吐的場景。

以上就是我們在處理日志數(shù)據(jù)入湖時(shí)面臨的典型挑戰(zhàn)以及我們?nèi)绾慰朔@些挑戰(zhàn)，接著講講我們在處理數(shù)據(jù)入湖時(shí)為滿足業(yè)務(wù)要求做的關(guān)鍵特性開發(fā)。

首先是支持并發(fā)寫，業(yè)務(wù)側(cè)要求鏈路有補(bǔ)數(shù)據(jù)能力，補(bǔ)數(shù)據(jù)場景涉及多 Flink Client 寫不同分區(qū)，實(shí)時(shí)寫鏈路，補(bǔ)數(shù)據(jù)鏈路，Table Service 鏈路并發(fā)操作表數(shù)據(jù)/元數(shù)據(jù)，這要求：

1.表數(shù)據(jù)不錯(cuò)亂。

2.補(bǔ)數(shù)據(jù)/TableService 鏈路不影響實(shí)時(shí)寫鏈路。

因此我們對 Hudi 內(nèi)核側(cè)做了部分修改來支持并發(fā)寫場景：

1.CkpMetadata 唯一標(biāo)識(shí)，保證不同作業(yè)使用不同 ckp meta。

2.ViewStorage 唯一標(biāo)識(shí)，保證不同作業(yè) Timeline Server 隔離。

3.Lazy Table Service，保證并行作業(yè)不互相 rollback commit，避免數(shù)據(jù)錯(cuò)亂。

4.Instant 生成重試策略，保證 Timeline Instant 的唯一性，避免數(shù)據(jù)錯(cuò)亂。

5.獨(dú)立 Table Service 處理，使用單獨(dú)的作業(yè)運(yùn)行 Table Service，與實(shí)時(shí)寫鏈路完全隔離。

另外一個(gè)關(guān)鍵特性是出于成本考慮，業(yè)務(wù)側(cè)要求 Hudi 中數(shù)據(jù)不能無限地保存，需要按照用戶設(shè)定的策略保留指定時(shí)間的數(shù)據(jù)，這要求：

1.Hudi 提供分區(qū)級別按照數(shù)據(jù)量，分區(qū)數(shù)和過期時(shí)間等不同維度進(jìn)行生命周期管理的能力。

2.Hudi 支持并發(fā)設(shè)置生命周期管理策略，因?yàn)槊嫦蚨嘧鈶魰?huì)涉及并發(fā)更新管理策略。

針對業(yè)務(wù)對生命周期管理的需求，我們開發(fā) Hudi 的生命周期管理功能，具體實(shí)現(xiàn)如下：

1.對于生命周期管理使用，首先通過 call command 添加生命周期管理策略，并進(jìn)行持久化，為支持并發(fā)更新，我們參考 Hudi MOR 表中 Base 文件和 Log 文件的設(shè)計(jì)，并發(fā)更新會(huì)寫入不同的 Log 文件。

2.對于生命周期管理的執(zhí)行，在每一次 commit 結(jié)束后進(jìn)行統(tǒng)計(jì)信息增量采集并更新至統(tǒng)計(jì)信息文件，然后按照分區(qū)策略進(jìn)行過期分區(qū)的處理，對于過期分區(qū)會(huì)生成一個(gè) replace commit，等待后續(xù)被 clean 即可，同時(shí)會(huì)合并前面的策略 Base 文件和 Log 文件，生成新的 Base 文件以及更新統(tǒng)計(jì)信息。

我們也提供了按照分區(qū)數(shù)、數(shù)據(jù)量、過期時(shí)間三種不同策略來管理 Hudi 表中的分區(qū)的生命周期，很好的滿足業(yè)務(wù)側(cè)的需求。

最后一個(gè)比較大的關(guān)鍵特性是獨(dú)立 TableService，業(yè)務(wù)側(cè)要求保證實(shí)時(shí)寫鏈路穩(wěn)定，同時(shí)希望提高入湖數(shù)據(jù)的查詢性能，這要求：

1.在不影響主鏈路同步性能情況下，清理 Commits/文件版本，保證表狀態(tài)大小可控。

2.為提高查詢性能，提供異步 Clustering 能力，合并小文件，減少掃描量，提高查詢性能。

基于上述訴求我們開發(fā)了基于 ADB 湖倉版的獨(dú)立 Table Service 服務(wù)，在入湖鏈路寫入完成后會(huì)進(jìn)行一次調(diào)度，然后將請求寫入調(diào)度組件，供調(diào)度組件后續(xù)拉起彈性的 Flink/Spark TableService 作業(yè)，可以做到對實(shí)時(shí)寫入鏈路無影響。

對于表狀態(tài)管理以及數(shù)據(jù)布局優(yōu)化均是采用的獨(dú)立 TableService 作業(yè)執(zhí)行，保證表的狀態(tài)大小可控，同時(shí)通過異步 Clustering 操作，端到端查詢性能提升 40% 以上。

在對日志入湖鏈路進(jìn)行了深入打磨后，我們可以保證最高 4GB/s 的數(shù)據(jù)寫入，延遲在 5min內(nèi)，滿足業(yè)務(wù)需求。

同時(shí)也建設(shè)了指標(biāo)監(jiān)控大盤與異常鏈路告警功能，便于快速定位問題以及出現(xiàn)問題后快速響應(yīng)。

以上介紹便是我們是如何基于Hudi構(gòu)建千億數(shù)據(jù)入湖以及如何克服入湖挑戰(zhàn)的。

3、基于 ADB 構(gòu)建 Lakehouse 的實(shí)踐

最后介紹下基于 ADB 構(gòu)建 Lakehouse 的實(shí)踐。

前面也提到 ADB 湖倉版擁抱開源技術(shù)，ADB 集成了流式處理引擎 Flink，并在此基礎(chǔ)上推出了 APS 數(shù)據(jù)管道服務(wù)，APS 具備如下優(yōu)勢：

1.低成本，低延遲：作業(yè)級別彈性資源，按量付費(fèi)；按流量自由設(shè)定作業(yè)資源；充分享受 Flink 流式處理性能紅利。

2.多數(shù)據(jù)源快速集成：得益于 Flink 成熟的 Connectors 機(jī)制，可以方便對接如 SLS、Kafka 等數(shù)據(jù)源，同時(shí)可以保證數(shù)據(jù)入湖的精確一致性。

3.低使用門檻：支持白屏化操作快速構(gòu)建 Lakehouse，基于統(tǒng)一元數(shù)據(jù)服務(wù)，Lakehouse 數(shù)據(jù)可通過 Spark/ADB 引擎無縫訪問。

而為了滿足客戶對于批處理以及機(jī)器學(xué)習(xí)能力的訴求，ADB 集成了 Spark 引擎，并在此技術(shù)上推出了 Servlersss Spark，其具備如下優(yōu)勢：

1.一份數(shù)據(jù)存儲(chǔ)，在離線共享：無縫對接 ADB 已有元數(shù)據(jù)和數(shù)據(jù)；支持大吞吐讀寫 ADB 數(shù)據(jù)；Spark 批量寫入的數(shù)據(jù)，在線分析查詢可直接訪問。

2.數(shù)據(jù)庫體系&體驗(yàn)：使用 ADB 統(tǒng)一的賬號、權(quán)限和鑒權(quán)體系；支持通過 ADB Workflow、DMS 以及 DataWorks 調(diào)度編排 SparkSQL 作業(yè)。

3.完全兼容 Spark 生態(tài)：基于最新的 Apache Spark 3.X 版本，充分享受開源社區(qū)紅利；支持 SparkSQL、DataFrame API 主流編程接口以及 Thrift Server；支持 Spark UDF，支持 Hive UDF/UDTF/UDAF。

4.按量計(jì)費(fèi)，秒級彈性：開箱即用，按量計(jì)費(fèi)無任何持有成本；基于神龍、ECS/ECI 的管控底座以及資源池化，緩存加速等技術(shù)，支持 Spark Pod 秒級拉起。

對于實(shí)時(shí)性有訴求的場景，可以基于 ADB APS 服務(wù)可以非常方便的構(gòu)建準(zhǔn)實(shí)時(shí) Lakehouse，白屏化操作快速配置入湖通道，多種數(shù)據(jù)源支持，滿足不同數(shù)據(jù)源接入訴求，更多數(shù)據(jù)源也在持續(xù)集成中。

而對于實(shí)時(shí)性沒有訴求的場景，可以基于 Spark + Hudi + ADB 工作編排構(gòu)建離線 Lakehouse,如想對 RDS 數(shù)據(jù)構(gòu)建離線Lakehouse進(jìn)行分析，可使用ADB工作編排，利用 Spark 將 RDS 數(shù)據(jù)離線導(dǎo)入 Lakehouse，并做數(shù)據(jù)的清洗和加工，有需要最后可通過一條簡單的 Spark SQL將數(shù)據(jù)從 Hudi 導(dǎo)入 ADB 做查詢分析加速。

另外 ADB Spark 與 Hudi 和 ADB 表都做了深度集成，便于客戶使用，如對于 Hudi 表的使用，免去了很多 Hudi 額外的配置，開箱即用；對于 ADB 表，可通過 Spark 創(chuàng)建、刪除 ADB 表元數(shù)據(jù)，也支持讀寫 ADB 表數(shù)據(jù)。

另外最后介紹下 Spark 與 ADB 集成提供的 Zero-ETL 解決方案，這也與 2022 AWS reinvent 推出的數(shù)據(jù)集成服務(wù) Zero-ETL 類似，我們通過一個(gè)場景了解 Zero-ETL 的應(yīng)用及其優(yōu)勢。

客戶如果對于 ADB 表有分析挖掘的需求，受限于 JDBC 方式吞吐的限制，需要先將 ADB內(nèi)表數(shù)據(jù)以 parquet 格式導(dǎo)出到 OSS，利用 OSS 的帶寬，再通過 Spark 進(jìn)行分析挖掘，最后輸出挖掘結(jié)果，可以看到這種方案中存在ETL操作，從而引入數(shù)據(jù)一致性差、時(shí)效性低的問題。

在 ADB 湖倉版中 Spark 與 ADB 做了深度集成，通過 Lakehouse API直接訪問 ADB 內(nèi)表數(shù)據(jù)，吞吐高，所以面對同樣的場景，可以使用下面的鏈路，即直接通過 Spark 分析 ADB 數(shù)據(jù)，無需 ETL，數(shù)據(jù)一致性好，時(shí)效性也很高；另外對于 Lakehouse API 層的訪問也支持列投影、謂詞下推、分區(qū)裁剪等能力，更多下推能力也在持續(xù)建設(shè)中。