實時數倉方案五花八門，實際落地如何選型和構建

編輯 | 韓楠

約  4,989 字 | 10 分鐘閱讀

【這裡我補充說幾句：這篇分享，內容分成了一個個小塊知識呈現的，大家可結合文章概覽看看對哪部分/哪幾部分更為感興趣，或者哪部分知識點掌握程度有待加深。然後直接找到對應的小模組瀏覽學習。期待與你在留言區裡進一步討論交流。】

隨著數字化程式的推進，企業產生的資料越來越多，與此同時企業對資料的需求也變得越來越複雜多樣。

如何解決大規模複雜資料的儲存和計算，已經成為很多企業必須面對的問題？這值得我們深思。

最初企業儲存資料都在數倉中儲存，但是隨著資料量的增大，傳統資料的方案在時效性上和資料維護上變得越來越困難。實時數倉架構應運而生。

然而問題並不是這麼簡單， 在具體方案落地上實時數倉有很多方案可以選擇，那麼面對不同的業務和應用場景我們到底應該選擇哪種技術方案呢？這是困擾好多大資料架構師的問題。

圖1

本文就針對該問題梳理了市場上常見的實時數倉方案和對應的應用場景。以便大家在選擇或者使用實時數倉架構時能夠有的放矢。

當然，在職業規劃中，對應於想要成為大架構師的你而言，透過本文閱讀你將會讓你瞭解大資料架構必須掌握的數倉知識。尤其在實時數倉各種方案對比上會讓你對數倉的理解更上一層樓。

另外， 即便你不是大資料方面的研發人員，這一篇中處理資料的流程和思路，也一樣會對你日常的工作有所幫助。

在介紹實時數倉前，我們先回顧下離線數倉的分層架構，這將對我們後面理解實時數倉架構設計具有很大幫助。

數倉一般分為：ODS層、DWD層、DWS層和ADS層。這裡我會分別展開說一下。這部分內容大家瞭解數倉中每層資料的特點即可，具體研發中同學們可以根據專案再做深入體會。

圖2

1） ODS層：ODS是資料接入層，所有進入資料的資料首先會接入ODS層。一般來說ODS層的資料是多複雜多樣的。從資料粒度上看ODS層是粒度最細的資料層。

2） DWD層：為資料倉儲層，資料明細層的資料應是經過ODS清洗，轉後的一致的、準確的、乾淨的資料。DWD層資料粒度通常和ODS的粒度相同，不同的是該層的資料質量更高，欄位更全面等。在資料明細層會儲存BI系統中所有的歷史資料，例如儲存近10年來的資料。

3） DWS層：資料集市層，該層資料是面向主題來組織資料的，通常是星形或雪花結構的資料。從資料粒度來說，這層的資料是輕度彙總級的資料，已經不存在明細資料了。

4） ADS層：資料應用層，它是完全為了滿足具體的分析需求而構建的資料，也是星形或雪花結構的資料。從資料粒度來說是高度彙總的資料。其彙總的目標主要是按照應用需求進行的。

那麼數倉為什麼要分層，數倉分層後有哪些好處呢？數倉分層是一個比較麻煩且耗費工作成本的一個事情，只有理解了數倉分層到底有哪些好處，我們才能理解數倉分層的必要性。

數倉分層的總體思路是用空間換時間，其目的是透過數倉分層，使得數倉能夠更好地應對需求的變更，和提高資料的穩定性。

1） 用空間換時間：透過大量的預處理來提升應用系統的使用者體驗（效率），因此資料倉儲會存在大量冗餘的資料。

2） 能更好地應對需求的變更：如果不分層的話，如果源業務系統的業務規則發生變化，將會影響整個資料清洗過程，工作量巨大。

3） 提高資料處理過程的穩定性：透過資料分層管理可以簡化資料清洗的過程，因為把原來一步的工作分到了多個步驟去完成，相當於把一個複雜的工作拆成了多個簡單的工作，每一層的處理邏輯都相對簡單和容易理解。

這樣我們比較容易保證每一個步驟的正確性，當資料發生錯誤的時候，往往我們只需要區域性調整某個步驟即可。

圖3

前面介紹了數倉分層的一些基本理論，這將對我們後面理解實時數倉的各種架構打下一些理論知識基礎。下面為大家梳理下市場上常見的實時數倉方案和對應的應用場景。

大部分實時數倉，其實是從Lambda架構演化而來的，因此在介紹實時數倉方案前我們先回顧下Lambda架構。

Lambda架構將資料分為實時資料和離線資料。

針對實時資料使用流式計算引擎進行計算（例如Flink），針對離線資料使用批次計算引擎（例如Spark）計算。然後分別將計算結果儲存在不同的儲存引擎上對外提供資料服務。

圖4

這種架構的優點是離線資料和實時資料各自計算，既能保障實時為業務提供服務，又能保障歷史資料的快速分析。它分別結合了離線計算引擎與流式計算引擎二者的優勢。

但是有一個缺點是離線資料和實時資料的一致性比較難保障，一般在離線資料產生後會使用離線資料清洗實時資料來保障資料的強一致性。

接下來要講的這種架構，它是基於Lambda架構上的最佳化版本， Kappa架構。這種架構將資料來源的資料全部轉換為流式資料，並將計算統一到流式計算引擎上。

這種方式的特點使架構變得更加簡單，但是不足之處是需要保障資料都是實時的資料，如果資料是離線的話也需要轉化為流式資料的架構進行資料處理，具體架構可結合這張圖來看。

圖5

實時數倉的查詢需求

在正式討論實時數倉前，我們先看下行業對實時數倉的主要需求，這有助於我們理解實時數倉各種方案設計的初衷，瞭解它是基於哪些需求應運而生的。

這也將幫助我們從更多維度上思考需求、條件、落地難點等等一些關鍵要素之間如何評估和權衡，最終實現是基於現有條件下的功能如何將其價值最大化。

傳統意義上我們通常將資料處理分為離線的和實時的。對於實時處理場景，我們一般又可以分為兩類：

一類諸如監控報警類、大屏展示類場景要求秒級甚至毫秒級；另一類諸如大部分實時報表的需求通常沒有非常高的時效性要求，一般分鐘級別，比如10分鐘甚至30分鐘以內都可接受。

圖6

基於以上查詢需求，業界常見的實時數倉方案有這幾種。 

圖7

目前老的專案大部分還在使用的標準分層體現+流計算+批次計算的方案。未來大家可能都會遷移到標準分層體系+流計算+資料湖，和基於全場景MPP資料庫實現的方案上，我也會重點介紹這兩個方案，也希望大家能夠多花點時間加以理解。

首先我們們看下Kappa架構，Kappa架構將多源資料（使用者日誌，系統日誌，BinLog日誌）實時地傳送到Kafka。

然後透過Flink叢集，按照不同的業務構建不同的流式計算任務，對資料進行資料分析和處理，並將計算結果輸出到MySQL/ElasticSearch/HBase/Druid/KUDU等對應的資料來源中，最終提供應用進行資料查詢或者多維分析。

圖8

這種方案的好處有二，方案簡單；資料實時。不過有兩個缺點：

一個是使用者每產生一個新的報表需求，都需要開發一個Flink流式計算任務，資料開發的人力成本和時間成本都較高。

第二個是對於每天需要接入近百億的資料平臺，如果要分析近一個月的資料，則需要的Flink叢集規模要求很大，且需要將很多計算的中間資料儲存在記憶體中以便多流Join。

圖9

為了解決方案1中將所有資料放在一個層出現的開發維護成本高等問題，於是出現了基於標準分層+流計算的方案。

接下來我們們看下這種方案， 在傳統數倉的分層標準上構建實時數倉，將資料分為ODS、DWD、DWS、ADS層。首先將各種來源的資料接入ODS貼源資料層，再對ODS層的資料使用Flink的實時計算進行過濾、清洗、轉化、關聯等操作，形成針對不同業務主題的DWD資料明細層，並將資料傳送到Kafka叢集。

之後在DWD基礎上，再使用Flink實時計算進行輕度的彙總操作，形成一定程度上方便查詢的DWS輕度彙總層。最後再面向業務需求，在DWS層基礎上進一步對資料進行組織進入ADS資料應用層，業務在資料應用層的基礎上支援使用者畫像、使用者報表等業務場景。

圖10

這種方案的優點是：各層資料職責清晰。缺點是多個Flink叢集維護起來複雜，並且過多的資料駐留在Flink叢集內也會增大叢集的負載，不支援upset操作，同時Schema維護麻煩。

圖11

為了解決方案2不支援upset和schema維護複雜等問題。我們在方案2的基礎上加入基於HDFS加  Spark離線的方案。也就是離線數倉和實時數倉並行流轉的方案。

圖12

這種方案帶來的優點是：既支援實時的OLAP查詢，也支援離線的大規模資料分析。但是帶來了問題這樣的幾個問題。

資料質量管理複雜：需要構建一套相容離線資料和實時資料血緣關係的資料管理體系，本身就是一個複雜的工程問題。離線資料和實時資料Schema統一困難。架構不支援upset。

圖13

隨著技術的發展，為了解決資料質量管理和upset 問題。出現了流批一體架構，這種架構基於資料湖三劍客 Delta Lake  / Hudi / Iceberg 實現 + Spark 實現。

圖14

我們以Iceberg為例介紹下這種方案的架構，從下圖可以看到這方案和前面的方案2很相似，只是在資料儲存層將Kafka換為了Iceberg。

圖15

它有這樣的幾個特點，其中第2、3點，尤為重要，需要特別關注下，這也是這個方案和其他方案的重要差別。

1. 在程式設計上將流計算和批計算統一到同一個SQL引擎上，基於同一個Flink SQL既可以進行流計算，也可以進行批計算。

   
   

2. 將流計算和批計算的儲存進行了統一，也就是統一到Iceberg/HDFS上，這樣資料的血緣關係的和資料質量體系的建立也變得簡單了。

   
   

3. 由於儲存層統一，資料的Schema也自然統一起來了，這樣相對流批單獨兩條計算邏輯來說，處理邏輯和後設資料管理的邏輯都得到了統一。

   
   

4. 資料中間的各層（ODS、DWD、DWS、ADS）資料，都支援OLAP的實時查詢。

   

圖16

那麼為什麼 Iceberg 能承擔起實時數倉的方案呢，主要原因是它解決了長久以來流批統一時的這些難題：

1. 同時支援流式寫入和增量拉取。

   
   

2. 解決小檔案多的問題。資料湖實現了相關合並小檔案的介面，Spark / Flink上層引擎可以週期性地呼叫介面進行小檔案合併。

   
   

3. 支援批次以及流式的 Upsert(Delete) 功能。批次Upsert / Delete功能主要用於離線資料修正。流式upsert場景前面介紹了，主要是流處理場景下經過視窗時間聚合之後有延遲資料到來的話會有更新的需求。這類需求是需要一個可以支援更新的儲存系統的，而離線數倉做更新的話需要全量資料覆蓋，這也是離線數倉做不到實時的關鍵原因之一，資料湖是需要解決掉這個問題的。 

   
   

4. 同時 Iceberg 還支援比較完整的OLAP生態。比如支援Hive / Spark / Presto / Impala 等 OLAP 查詢引擎，提供高效的多維聚合查詢效能。

   
   

圖17

Iceberg 實戰

上面介紹了基於Iceberg的標準分層體系+流計算+資料湖的架構，下面我們們從實戰角度看下Iceberg如何使用。

iceberg寫入流式資料程式碼實現如下：

data.writeStream.format("iceberg")  .outputMode("append") .trigger(Trigger.ProcessingTime(1, TimeUnit.MINUTES)).option("data_path", tableIdentifier) .option("checkpointLocation", checkpointPath) .start()

code1

上述程式碼會將data_path下的資料以流的形式，實時加入到系統中進行計算。

iceberg資料過濾程式碼實現如下：

Table table = ... Actions.forTable(table).rewriteDataFiles() .filter(Expressions.equal("date", "2022-03-18")) .targetSizeInBytes(500 * 1024 * 1024) // 500 MB .execute();

code2

上述程式碼過濾出date為2022-03-18的資料。

前面的四種方案，是基於數倉方案的最佳化。方案仍然屬於比較複雜的，如果我能提供一個資料庫既能滿足海量資料的儲存，也能實現快速分析，那豈不是很方便。這時候便出現了以StartRocks和ClickHouse為代表的全場景MPP資料庫。

1. 基於Darios或者ClickHouse構建實時數倉。來看下具體的實現方式：將資料來源上的實時資料直接寫入消費服務。

2. 對於資料來源為離線檔案的情況有兩種處理方式，一種是將檔案轉為流式資料寫入Kafka，另外一種情況是直接將檔案透過SQL匯入ClickHouse叢集。

3. ClickHouse接入Kafka訊息並將資料寫入對應的原始表，基於原始表可以構建物化檢視、Project等實現資料聚合和統計分析。

4. 應用服務基於ClickHouse資料對外提供BI、統計報表、告警規則等服務。

   
   

圖18

對於這5種方案，在具體選型中，我們要根據具體業務需求、團隊規模等進行技術方案選型。

說到這兒，我有這樣的幾點具體建議，希望或多或少可以給你提供一些可供參考、借鑑的新視角或者新思路。

（1）對於業務簡單，且以流式資料為主資料流的大資料架構可以採用Kappa架構。

（2）如果業務以流計算為主，對資料分層，資料許可權，多主題資料要求比較高，建議使用方案2的基於標準分層+流計算。

（3）如果業務的流資料是批資料都比較多，且流資料和批資料直接的關聯性不大，建議使用方案3的標準分層體現+流計算+批次計算。這種情況下分別能發揮流式計算和批次計算各自的優勢。

圖19

（4）方案4是一個比較完善的數倉方案，要支援更大規模的和複雜的應用場景，建議大資料研發人員在20以上的團隊，可以重點考慮。

（5）對於大資料研發組團隊為10人左右，要維護像方案2、3、4那樣以ODS、DWD、DWS、ADS資料分層的方式進行實時數倉建設的話，就需要投入更多的資源。建議使用方案5一站式實現簡單的實時數倉。

介紹了這麼多實時數倉方案，那麼很多小夥伴會問了，大廠到底用的那種方案呢？其實每個大廠根據自己業務特點的不同，也會選擇不同的解決方案。下面為大家簡要分享下OPPO、滴滴和位元大陸的方案，以便大家能夠更好地理解這篇分享中五種架構的具體落地。

不過具體架構細節我不會進行過多的介紹，有了前面的內容基礎，相信大家再透過架構圖就能很快了解每個架構的特點。這裡只是希望大家能夠透過大廠的經驗，明白他們架構設計的初衷和要解決的具體問題，同時也給我們的架構設計提供一些思路。

舉例來說，OPPO的實時計算平臺架構，其方案其實類似於方案2的基於標準分層+流計算。

圖20

滴滴的大資料平臺架構是這樣的，它的方案其實類似於方案2的基於標準分層+流計算。

圖21

再結合位元大陸的方案看下，其方案型別方案3的標準分層體現+流計算+批次計算，同時也引入了ClickHouse，可以看到位元大陸的資料方案是很複雜的。

圖22

本文介紹了市面上常見實時數倉方案，並對不同方案的優缺點進行了介紹。在使用過程中我們需要根據自己的業務場景選擇合適的架構。

另外想說明的是實時數倉方案並不是“搬過來”，而是根據業務“演化來”的，具體設計的時候需要根據自身業務情況，找到最適合自己當下的實時數倉架構。

我們在實時數倉的構建過程中比較大的爭議是採用標準分層體系+流計算+資料湖的方案，還是試用基於全場景MPP資料庫實現。

在討論過程中大家比較大的分歧是基於全場景MPP資料庫實現到底算是一個數倉方案不，畢竟該方案沒有標準的數倉分層的思想，而是圍繞大規模資料統計的需求來實現的。

但是我的觀點是：一切方案都需要以實際需求為出發點，我們的80%的需求就是在一個180多個欄位的大寬表（每天80億條，3TB資料量）上可以靈活的統計分析，快速為業務決策提供依據。因此我們選擇了基於全場景MPP資料庫方案。

新的技術層出不窮，對我們技術人來說嚐鮮是很爽的一件事情，但是實際落地還是建議大家把需求收斂好後再做決策，保持冷靜的思維，有時候適當地“讓子彈飛一會”也是有好處的。

今天的分享到這裡就結束了，期待留言區裡的進一步交流，也可以把它分享給你的朋友。我們後續再會。