1991年，比爾·恩門（Bill Inmon）出版了他的第一本關于數據倉庫的書《Building the Data Warehouse》，標志著數據倉庫概念的確立。

我們所常說的企業數據倉庫Enterprise Data Warehouse (EDW) ，就是一個用于聚合不同來源的數據（比如事務系統、關系數據庫和操作數據庫），然后方便進行數據訪問、分析和報告的系統（例如銷售交易數據、移動應用數據和CRM數據），只要數據匯集到數倉中，整個企業都訪問和使用，從而方便大家來全面的了解業務。我們的數據工程師和業務分析師可以將這些不同來源的相關數據應用于商業智能（BI）和人工智能（AI）等方面，以便帶來更好的預測，并最終為我們作出更好的業務決策。

企業為什么需要實時數據倉庫

傳統意義上的數據倉庫主要處理T+1數據，即今天產生的數據分析結果明天才能看到，T+1的概念來源于股票交易，是一種股票交易制度，即當日買進的股票要到下一個交易日才能賣出。

隨著互聯網以及很多行業線上業務的快速發展，讓數據體量以前所未有的速度增長，數據時效性在企業運營中的重要性日益凸現，企業對海量數據的處理有了更高要求，如非結構化數據處理、快速批處理、實時數據處理、全量數據挖掘等。由于傳統數據倉庫側重結構化數據，建模路徑較長，面對大規模數據處理能力有限，企業急需提升大數據處理時效，以更經濟的方式發掘數據價值。

數據的實時處理能力也成為企業提升競爭力的一大因素。

數據處理流程

在了解數倉如何實時處理之前，我們先來了解數據的分層。每個企業根據自己的業務需求可以分成不同的層次，但是最基礎的分層思想，理論上數據分為三個層：貼源層（ODS)、數據倉庫層（DW）、數據服務層(APP/DWA)。基于這個基礎分層之上滿足不同的業務需求。

ODS：Operation Data Store，也稱為貼源層。數據倉庫源頭系統的數據表通常會原封不動的存儲一份，這稱為ODS層，是后續數據倉庫加工數據的來源。

DW數據分層，由下到上一般分為DWD，DWB，DWS。

DWD：Data Warehouse Details 細節數據層，是業務層與數據倉庫的隔離層。主要對ODS數據層做一些數據清洗(去除空值、臟數據、超過極限范)和規范化的操作。

DWB：Data Warehouse Base 數據基礎層，存儲的是客觀數據，一般用作中間層，可以認為是大量指標的數據層。

DWS：Data Warehouse Service 數據服務層，基于DWB上的基礎數據，主要是對用戶行為進行輕度聚合，整合匯總成分析某一個主題域的服務數據層，一般是寬表。用于提供后續的業務查詢，OLAP分析，數據分發等。

數據服務層/應用層(APP/DWA)：該層主要是提供數據產品和數據分析使用的數據，我們通過說的報表數據，或者說那種大寬表，一般就放在這里。

實時數倉的常見方案

當前，數據倉庫被分為離線數倉和實時數倉，離線數倉一般是傳統的T+1型數據ETL方案，而實時數倉一般是分鐘級甚至是秒級ETL方案。并且，離線數倉和實時數倉的底層架構也不一樣，離線數倉一般采用傳統大數據架構模式搭建，而實時數倉則采用Lambda、Kappa等架構搭建。

LAMBDA & KAPPA 實時架構

目前，實時處理有兩種典型的架構：Lambda 和 Kappa 架構。出于歷史原因，這兩種架構的產生和發展都具有一定局限性。

Lambda架構：在離線大數據架構的基礎上增加新鏈路用于實時數據處理，需要維護離線處理和實時處理兩套代碼；

Lambda 架構通過把數據分解為服務層（Serving Layer）、速度層（Speed Layer，亦即流處理層）、批處理層（Batch Layer）三層來解決不同數據集的數據需求。在批處理層主要對離線數據進行處理，將接入的數據進行預處理和存儲，查詢直接在預處理結果上進行，不需再進行完整的計算，最后以批視圖的形式提供給業務應用。

在實際生產環境中的部署通常可以參見下圖，一般要通過一系列不同的存儲和計算引擎 (HBase、Druid、Hive、Presto、Redis 等) 復雜協同才能滿足業務的實時需求，此外多個存儲之間需要通過數據同步任務保持大致的同步。Lambda 架構在實際落地過程中極其復雜，使整個業務的開發耗費了大量的時間。

缺點：

(1) 由多個引擎和系統組合而成，批處理 (Batch)、流處理 (Streaming) 以及合并查詢 (Merged Query) 的實現需要使用不同的開發語言，造成開發、維護和學習成本較高；(2) 數據在不同的視圖 (View) 中存儲多份，浪費存儲空間，數據一致性的問題難以解決。

Kappa架構：希望做到批流合一，離線處理和實時處理整合成一套代碼，減小運維成本。Kappa 架構在 Lambda 架構的基礎上移除了批處理層，利用流計算的分布式特征，加大流數據的時間窗口，統一批處理和流處理，處理后的數據可以直接給到業務層使用。因為在 Kappa 架構下，作業處理的是所有歷史數據和當前數據，其產生的結果我們稱之為實時批視圖（Realtime_Batch_View）。

Kappa 架構的流處理系統通常使用 Spark Streaming 或者 Flink 等實現，服務層通常使用MySQL 或 HBase 等實現。

Kappa 架構部署圖

缺點：(1) 依賴 Kafka 等消息隊列來保存所有歷史，而Kafka 難以實現數據的更新和糾錯，發生故障或者升級時需要重做所有歷史，周期較長；(2) Kappa 依然是針對不可變更數據，無法實時匯集多個可變數據源形成的數據集快照，不適合即席查詢。

因為上述的缺點，Kappa架構在現實中很少被應用。

湖倉一體能否解決實時問題？

時下熱門的湖倉一體能否解決實時問題呢？湖倉一體有何標準？Gartner 認為湖倉一體是將數據湖的靈活性和數倉的易用性、規范性、高性能結合起來的融合架構，無數據孤島。

作為數據湖和數據倉庫的完美結合，新一代的湖倉一體架構重點關注和解決了近年來數字化轉型帶來的業務需求和技術難點，具體包括如下以下方面：

1.實時性成為了提升企業競爭力的核心手段。目前的湖、倉、或者湖倉分體都是基于 T+1 設計的，面對 T+0 的實時按需分析，用戶的需求無法滿足。

2.所有用戶（BI 用戶、數據科學家等）可以共享同一份數據，避免數據孤島。

3.超高并發能力，支持數十萬用戶使用復雜分析查詢并發訪問同一份數據。

4.傳統 Hadoop 在事務支持等方面的不足被大家詬病，在高速發展之后未能延續熱度，持續引領數據管理，因此事務支持在湖倉一體架構中應得到改善和提升。

5.云原生數據庫已經逐漸成熟，基于存算分離技術，可以給用戶帶來多種價值：降低技術門檻、減少維護成本、提升用戶體驗、節省資源費用，已成為了湖倉一體落地的重要法門。

6.為釋放數據價值提升企業智能化水平，數據科學家等用戶角色必須通過多種類型數據進行全域數據挖掘，包括但不限于歷史的、實時的、在線的、離線的、內部的、外部的、結構化的、非結構化數據。

云原生數據倉庫 + Omega實時架構 實現實時湖倉

云原生數據庫實現完全的存算分離

云原生數據庫如 OushuDB 和 Snowflake 突破了傳統 MPP 和 Hadoop 的局限性，實現了存算完全分離，計算和存儲可部署在不同物理集群，并通過虛擬計算集群技術實現了高并發，同時保障事務支持，成為湖倉一體實現的關鍵技術。以 OushuDB 為例，實現了存算分離的云原生架構，并通過虛擬計算集群技術在數十萬節點的超大規模集群上實現了高并發，保障事務支持，提供實時能力，一份數據再無數據孤島。

基于Omega實時框架的湖倉方案

我們前面提到，既然 Kappa 架構實際落地困難，Lambda 架構又很難保障數據的一致性，兩個架構又都很難處理可變更數據（如關系數據庫中不停變化的實時數據），那么自然需要一種新的架構滿足企業實時分析的全部需求，這就是 Omega 全實時架構，Omega 架構由偶數科技根據其在各行業的實踐提出，同時滿足實時流處理、實時按需分析和離線分析。

Omega 架構由流數據處理系統和實時數倉構成。相比 Lambda 和 Kappa，Omega 架構新引入了實時數倉和快照視圖 (Snapshot View) 的概念，快照視圖是歸集了可變更數據源和不可變更數據源后形成的 T+0 實時快照，可以理解為所有數據源在實時數倉中的鏡像和歷史，隨著源庫的變化實時變化。

因此，實時查詢可以通過存儲于實時數倉的快照視圖得以實現。實時快照提供的場景可以分為兩大類：一類是多個源庫匯集后的跨庫查詢，比如一個保險用戶的權益視圖；另一類是任意時間粒度的分析查詢，比如最近 5 分鐘的交易量、最近 10 分鐘的信用卡開卡量等等。

另外，任意時間點的歷史數據都可以通過 T+0 快照得到（為了節省存儲，T+0 快照可以拉鏈形式存儲在實時數倉 ODS 中，所以快照視圖可以理解為實時拉鏈），這樣離線查詢可以在實時數倉中完成，離線查詢結果可以包含最新的實時數據，完全不再需要通過傳統MPP+Hadoop湖倉分體組合來處理離線跑批及分析查詢。

Omega 架構邏輯圖

流處理系統既可以實現實時連續的流處理，也可以實現 Kappa 架構中的批流一體，但與Kappa 架構不同的是，OushuDB 實時數倉存儲來自 Kafka 的全部歷史數據（詳見下圖），而在 Kappa 架構中源端采集后通常存儲在 Kafka 中。

Omega 架構部署圖

因此，當需要流處理版本變更的時候，流處理引擎不再需要訪問 Kafka，而是訪問實時數倉 OushuDB 獲得所有歷史數據，規避了 Kafka 難以實現數據更新和糾錯的問題，大幅提高效率。此外，整個服務層也可以在實時數倉中實現，而無需額外引入 MySQL、HBase 等組件，極大簡化了數據架構，實現了湖倉市一體（數據湖、數倉、集市一體）。實現了全實時 Omega 架構的湖倉一體，我們也稱之為實時湖倉一體。

Omega vs. Lambda vs. Kappa

結語：

面對復雜多變的新業務場景，隨著數據技術不斷成熟，新的實時技術棧會出現，數據技術也會經歷分離與融合。目前，融合的趨勢比較明顯，如實時湖倉一體，將實時處理能力融入數據倉庫中。不論企業如何選型實時數倉，數據平臺技術棧的建設一般都應該遵循三條基本原則：

1.架構層面要保持靈活開放，支持多種技術兼容性并存。目前，企業已經部署了多個系統，有自己的一套架構體系，技術融合落地時需要最大化利用企業原有IT資產，保護客戶投資。

2.有效利用資源，降本增效。原來傳統的技術棧，所有資源參與計算，造成IT資源浪費。比如，云原生資源池化，可以實現資源隔離與動態管理，便于最大化利用資源。

3.滿足更高的用戶體驗。從用戶角度來看，在技術條件具備的前提下，比如高性能、高并發、實時性更強，便具備了更強的信息加工能力，能夠在很短的時間內滿足用戶各種各樣的數據服務需求，提升用戶體驗。

隨著實時分析場景日益增多，實時數倉等具備實時處理能力的產品與解決方案將會得到更廣泛的應用。