實時數倉和離線數倉都是數據倉庫的不同類型，用于存儲和管理企業的數據，但它們在數據處理和使用的時間、速度以及用途方面有明顯的區別。

在介紹實時數倉之前，我們理應先來了解一下傳統的離線數倉。畢竟在企業早期的數據建設規劃中，在數據實時性要求不高的前提下，基本一開始都會選擇建設離線數倉。

一、離線數倉

1. 離線數倉是什么？

離線數倉（Offline Data Warehouse）是一個用于存儲和處理批處理數據的系統。它的特點是數據的處理和分析是基于批處理作業進行的，通常以較長的時間周期為單位。傳統離線數倉的數據時效性是 T+1，調度頻率以天為單位，無法支撐實時場景的數據需求。即使能將調度頻率設置成小時，也只能解決部分時效性要求不高的場景，對于實效性要求很高的場景還是無法優雅的支撐。

2. 離線數倉的特點

• 批處理：離線數倉通過批處理作業處理數據，這意味著數據在一定時間周期內收集、存儲，然后一次性處理。
• 高容量：離線數倉通常設計用于存儲大量歷史數據。
• 延遲較高：由于數據處理是批處理的，因此離線數倉不適合需要實時或近實時數據的應用。

3. 離線數倉的適用場景

• 需要進行歷史數據分析、報告生成的應用，如銷售報告、月度財務報表等。
• 數據量較大且處理時間不是關鍵問題的應用。

但是隨著企業的發展，數據量日益增大，傳統數據的方案在時效性上和數據維護上變得越來越困難。這時，實時數倉應運而生。

二、實時數倉

1. 實時數倉是什么？

實時數倉（Real-time Data Warehouse）是一個用于存儲和處理實時數據的系統。它的主要特點是數據的處理和分析是即時進行的，數據幾乎立即進入數倉并可以立即用于分析和決策。

2. 實時數倉的特點

• 低延遲：實時數倉能夠在數據產生后迅速將其捕捉和處理，通常以秒或亞秒級的速度。
• 數據流處理：實時數倉通常使用流式處理技術來處理數據，這允許數據在進入倉庫時立即進行轉換和計算。
• 實時分析：數據可以用于實時監控、儀表板、預測和決策支持。
• 高吞吐量：實時數倉需要處理大量的數據流，因此需要具備高吞吐量的性能。
• 復雜性：由于需要處理實時數據流，實時數倉的架構和技術通常比較復雜。

3. 實時數倉的適用場景

• 需要實時監控業務指標的應用，如金融交易看板、實時銷售報表、在線廣告投放分析等。
• 需要立即采取行動以應對實時事件的應用，如異常監測大屏、欺詐實時檢測等。

三、由數倉需求變化帶來的數據倉庫架構的演變

從1990年 Inmon 提出數據倉庫概念到今天，數倉架構經歷了最初的傳統數倉架構、離線大數據架構、Lambda 架構、Kappa 架構以及由Flink 的火熱帶出的流批一體架構，數據架構技術不斷演進，本質是在往流批一體的方向發展，讓用戶能以最自然、最小的成本完成實時計算。

1. 傳統數倉架構

這是比較傳統的一種方式，結構或半結構化數據通過離線ETL定期加載到離線數倉，之后通過計算引擎取得結果，供前端使用。這里的離線數倉+計算引擎，通常是使用大型商業數據庫來承擔，例如Oracle、DB2、Teradata等。

2. 離線大數據架構

隨著數據規模的不斷增大，傳統數倉方式難以承載海量數據。隨著大數據技術的普及，采用大數據技術來承載存儲與計算任務。數據源通過離線的方式導入到離線數倉中。下游應用根據業務需求選擇直接讀取 DM 或加一層數據服務，比如 MySQL 或 Redis。

數據倉庫從模型層面分為三層：

• ODS，操作數據層，保存原始數據；
• DWD，數據倉庫明細層，根據主題定義好事實與維度表，保存最細粒度的事實數據；
• DM，數據集市/輕度匯總層，在 DWD 層的基礎之上根據不同的業務需求做輕度匯總；

當然，也可以使用傳傳統數據庫集群或MPP架構數據庫來完成。例如Hadoop+Hive/Spark、Oracle RAC、GreenPlum等。

3. Lambda架構

隨著業務的發展，隨著業務的發展，人們對數據實時性提出了更高的要求。此時，出現了Lambda架構，其將對實時性要求高的部分拆分出來，增加條實時計算鏈路。從源頭開始做流式改造，將數據發送到消息隊列中，實時計算引擎消費隊列數據，完成實時數據的增量計算。與此同時，批量處理部分依然存在，實時與批量并行運行。最終由統一的數據服務層合并結果給于前端。一般是以批量處理結果為準，實時結果主要為快速響應。

4. Kappa架構

而Lambda架構，一個比較嚴重的問題就是需要維護兩套邏輯。一部分在批量引擎實現，一部分在流式引擎實現，維護成本很高。此外，對資源消耗也較大。隨后誕生的Kappa架構，正是為了解決上述問題。其在數據需要重新處理或數據變更時，可通過歷史數據重新處理來完成。方式是通過上游重放完成(從數據源拉取數據重新計算)。

可Kappa架構最大的問題是流式重新處理歷史的吞吐能力會低于批處理，但這個可以通過增加計算資源來彌補。

5. 混合架構

上述架構各有其適應場景，有時需要綜合使用上述架構組合滿足實際需求。當然這也必將帶來架構的復雜度。用戶應根據自身需求，有所取舍。在一般大多數場景下，是可以使用單一架構解決問題。現在很多產品在流批一體、海量、實時性方面也有非常好的表現，可以考慮這種“全能手”解決問題。

四、實時數倉和離線數倉的思考與總結

通常，企業可能會同時使用實時數倉和離線數倉來滿足不同的需求，以確保能夠有效地處理各種類型的數據。這種情況下，這兩者可能會集成，以充分利用它們的優勢。

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

了解更多數據倉庫與數據集成關干貨內容請關注>>>FineDataLink官網

免費試用、獲取更多信息，點擊了解更多>>>體驗FDL功能

往期推薦：

【大數據】什么是數據湖？一文揭示數據湖的本質-CSDN博客

金蝶API取數+JSON解析，FDL助力高效數據處理-CSDN博客

業務場景中的數倉調度-CSDN博客