揭秘 | 實時數倉你不知道的那些事

來源：3分鐘秒懂大資料

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. 滿足更高的使用者體驗。從使用者角度來看，在技術條件具備的前提下，比如高效能、高併發、實時性更強，便具備了更強的資訊加工能力，能夠在很短的時間內滿足使用者各種各樣的資料服務需求，提升使用者體驗。

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