柚子快報邀請碼778899分享：數(shù)據(jù)倉庫選型建議

http://yzkb.51969.com/

1 數(shù)倉分層

1.1 數(shù)倉分層的意義

**數(shù)據(jù)復(fù)用，減少重復(fù)開發(fā)：**規(guī)范數(shù)據(jù)分層，開發(fā)一些通用的中間層數(shù)據(jù)，能夠減少極大的重復(fù)計算。數(shù)據(jù)的逐層加工原則，下層包含了上層數(shù)據(jù)加工所需要的全量數(shù)據(jù)，這樣的加工方式避免了每個數(shù)據(jù)開發(fā)人員都重新從源系統(tǒng)抽取數(shù)據(jù)進行加工。通過匯總層的引人，避免了下游用戶邏輯的重復(fù)計算， 節(jié)省了用戶的開發(fā)時間和精力，同時也節(jié)省了計算和存儲。極大地減少不必要的數(shù)據(jù)冗余，也能實現(xiàn)計算結(jié)果復(fù)用，極大地降低存儲和計算成本。**數(shù)據(jù)血緣追蹤：**簡單來講可以這樣理解，我們最終給業(yè)務(wù)呈現(xiàn)的是一張直接使用的業(yè)務(wù)表，但是它的來源有很多，如果有一張來源表出問題了，我們希望能夠快速準(zhǔn)確地定位到問題，并清楚它的危害范圍。**把復(fù)雜問題簡單化。**講一個復(fù)雜的任務(wù)分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便于維護數(shù)據(jù)的準(zhǔn)確性，當(dāng)數(shù)據(jù)出現(xiàn)問題之后，可以不用修復(fù)所有的數(shù)據(jù)，只需要從有問題的步驟開始修復(fù)。

1.2 數(shù)倉分層規(guī)范

數(shù)倉從下往上一般分ODS->DWD->DWS-ADS 4層。

2 主流數(shù)倉架構(gòu)

目前主流數(shù)據(jù)倉庫建設(shè)主要分兩種，基于Lakehouse(湖倉一體)的流批一體架構(gòu)和基于MPP數(shù)據(jù)庫的輕量級數(shù)據(jù)倉庫。

一個企業(yè)數(shù)倉的整體邏輯如上圖所示，數(shù)倉在構(gòu)建的時候通常需要 ETL 處理和分層設(shè)計，基于業(yè)務(wù)系統(tǒng)采集的結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)進行各種 ETL 處理成為 DWD 層，再基于 DWD 層設(shè)計上層的數(shù)據(jù)模型層，形成 DM，中間會有 DWB/DWS 作為部分中間過程數(shù)據(jù)。

從技術(shù)選型來說，從數(shù)據(jù)源的 ETL 到數(shù)據(jù)模型的構(gòu)建通常需要長時任務(wù)，也就是整個任務(wù)的運行時間通常是小時及以上級別。而 DM 層主要是支持業(yè)務(wù)的需求，對實效性要求比較高，通常運行在 DM 層上的任務(wù)時間在分鐘作為單位。

基于如上的分層設(shè)計的架構(gòu)圖可以發(fā)現(xiàn)，雖然目前有非常多的組件，像 Presto，Doris，ClickHouse，Hive 等等，但是這些組件各自工作在不同的場景下，像數(shù)倉構(gòu)建和交互式分析就是兩個典型的場景。

交互式分析強調(diào)的是時效性，一個查詢可以快速出結(jié)果，像 Presto，Doris，ClickHouse 雖然也可以處理海量數(shù)據(jù)，甚至達到 PB 及以上，但是主要還是是用在交互式分析上，也就是基于數(shù)據(jù)倉庫的 DM 層，給用戶提供基于業(yè)務(wù)的交互式分析查詢，方便用戶快速進行探索。由于這類引擎更聚焦在交互式分析上，因此對于長時任務(wù)的支持度并不友好，為了達到快速獲取計算結(jié)果，這類引擎重度依賴內(nèi)存資源，需要給這類服務(wù)配置很高的硬件資源，這類組件通常有著如下約束：

沒有任務(wù)級的重試，失敗了只能重跑 Query，代價較高。一般全內(nèi)存計算，無 shuffle 或 shuffle 不落盤，無法執(zhí)行海量數(shù)據(jù)。架構(gòu)為了查詢速度快，執(zhí)行前已經(jīng)調(diào)度好了 task 執(zhí)行的節(jié)點，節(jié)點故障無法重新調(diào)度。

一旦發(fā)生任務(wù)異常，例如網(wǎng)絡(luò)抖動引起的任務(wù)失敗，機器宕機引起的節(jié)點丟失，再次重試所消耗的時間幾乎等于全新重新提交一個任務(wù)，在分布式任務(wù)的背景下，任務(wù)運行的時間越長，出現(xiàn)錯誤的概率越高，對于此類組件的使用業(yè)界最佳實踐的建議也是不超過 30 分鐘左右的查詢使用這類引擎是比較合適的。

而在離線數(shù)倉場景下，幾乎所有任務(wù)都是長時任務(wù)，也就是任務(wù)運行時常在小時及以上，這時就要求執(zhí)行 ETL 和構(gòu)建數(shù)倉模型的組件服務(wù)需要具有較高的容錯性和穩(wěn)定性，當(dāng)任務(wù)發(fā)生錯誤的時候可以以低成本的方式快速恢復(fù)，盡可能避免因為部分節(jié)點狀態(tài)異常導(dǎo)致整個任務(wù)完全失敗。

可以發(fā)現(xiàn)在這樣的訴求下類似于 Presto，Doris，ClickHouse 就很難滿足這樣的要求，而像 Hive，Spark 這類計算引擎依托于 Yarn 做資源管理，對于分布式任務(wù)的重試，調(diào)度，切換有著非?？煽康谋ＷC。Hive，Spark 等組件自身基于可重算的數(shù)據(jù)落盤機制，確保某個節(jié)點出現(xiàn)故障或者部分任務(wù)失敗后可以快速進行恢復(fù)。數(shù)據(jù)保存于 HDFS 等分布式存儲系統(tǒng)上，自身不管理數(shù)據(jù)，具有極高的穩(wěn)定性和容錯處理機制。

反過來，因為 Hive，Spark 更善于處理這類批處理的長時任務(wù)，因此這類組件不擅長與上層的交互式分析，對于這種對于時效性要求更高的場景，都不能很好的滿足。所以在考慮構(gòu)建數(shù)倉的時候，通常會選擇 Hive，Spark 等組件來負責(zé)，而在上層提供交互式分析查詢的時候，通常會使用 Presto，Doris，ClickHouse 等組件。

歸納下來如下：

**Doris，ClickHouse，Presto：**更注重交互式分析，對單機資源配置要求很高，重度依賴內(nèi)存，缺乏容錯恢復(fù)，任務(wù)重試等機制，適合于 30 分鐘以內(nèi)的任務(wù)，通常工作在企業(yè)的 DM 層直接面向業(yè)務(wù)，處理業(yè)務(wù)需求。**Spark，Hive：**更注重任務(wù)的穩(wěn)定性，對網(wǎng)絡(luò)，IO 要求比較高，有著完善的中間臨時文件落盤，節(jié)點任務(wù)失敗的重試恢復(fù)，更加合適小時及以上的長時任務(wù)運行，工作在企業(yè)的的 ETL 和數(shù)據(jù)模型構(gòu)建層，負責(zé)清洗和加工上層業(yè)務(wù)所需要的數(shù)據(jù)，用來支撐整個企業(yè)的數(shù)倉構(gòu)建。

2.1 基于湖倉一體的流批一體架構(gòu)

目前市面上核心的數(shù)據(jù)湖開源產(chǎn)品大致有這么幾個：Apache Hudi、Apache Iceberg和 Delta。國內(nèi)使用jiao較多的為Apache Hudi。

此架構(gòu)可以滿足目前業(yè)務(wù)需求：

批處理：采用Spark 進行批處理加工任務(wù)流處理：采用Flink + Hudi完成流處理任務(wù)交互式分析：離線數(shù)據(jù)采用導(dǎo)入到Doris或者Doris聯(lián)邦查詢的方式進行交互式分析；實時數(shù)據(jù)ADS層直接在Doris提供交互式分析能力。機器學(xué)習(xí)：機器學(xué)習(xí)應(yīng)用采用分布式機器學(xué)習(xí)框架Spark ML進行模型訓(xùn)練。

優(yōu)點：

超大規(guī)模大數(shù)據(jù)平臺主流架構(gòu)，經(jīng)過主流大廠驗證，運行穩(wěn)定可靠。 實時場景支持?jǐn)?shù)倉分層模型，可支持復(fù)雜邏輯大量數(shù)據(jù)的實時增量計算。 實時數(shù)倉基于 Flink-SQL 實現(xiàn)了流批一體，批處理和流處理同一套代碼，代碼維護成本低； 存儲數(shù)據(jù)多元化，結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)都能存儲。

缺點：

組件過多，數(shù)據(jù)鏈路長，運維成本高，對開發(fā)人員要求高。組件過多，成本高。

2.2 基于MPP數(shù)據(jù)庫的輕量級數(shù)據(jù)倉庫

目前主流開源OLAP MPP數(shù)據(jù)庫有 Doris, ClickHouse, Presto等，尤其以Doris勢頭強勁。

此架構(gòu)可以滿足目前業(yè)務(wù)需求：

批處理：采用DorisSQL進行批處理任務(wù)加工。流處理：采用Flink + Doris完成ODS層的實時構(gòu)建，后面采用DorisSQL定時調(diào)度完成增量數(shù)據(jù)的構(gòu)建。交互式分析：使用Doris對外提供服務(wù)。機器學(xué)習(xí)：機器學(xué)習(xí)應(yīng)用采用分布式機器學(xué)習(xí)框架Spark ML進行模型訓(xùn)練。但是每次模型訓(xùn)練都需要從Doris中讀取數(shù)據(jù)，給Doris造成壓力。

優(yōu)點：

組件單一，數(shù)據(jù)鏈路少，運維成本低，對開發(fā)人員要求低。組件單一，建設(shè)成本低。

缺點：

實時場景不支持?jǐn)?shù)倉分層模型批處理也在Doris加工，Doris是基于內(nèi)存計算的，當(dāng)大規(guī)模數(shù)據(jù)量進行加工時，容易遇到瓶頸。

2.3 湖倉一體和MPP對比

開源數(shù)倉架構(gòu)數(shù)據(jù)量運維成本開發(fā)成本團隊人數(shù)湖倉一體（Hudi）0-100PB級高高10人以上MPP（Doris）10PB以下低低10人以下

柚子快報邀請碼778899分享：數(shù)據(jù)倉庫選型建議

http://yzkb.51969.com/

推薦文章