1991年，比爾·恩門（Bill Inmon）出版了他的第一本關(guān)于數(shù)據(jù)倉庫的書《Building the Data Warehouse》，標志著數(shù)據(jù)倉庫概念的確立。
我們所常說的企業(yè)數(shù)據(jù)倉庫Enterprise Data Warehouse (EDW) ，就是一個用于聚合不同來源的數(shù)據(jù)（比如事務系統(tǒng)、關(guān)系數(shù)據(jù)庫和操作數(shù)據(jù)庫），然后方便進行數(shù)據(jù)訪問、分析和報告的系統(tǒng)（例如銷售交易數(shù)據(jù)、移動應用數(shù)據(jù)和CRM數(shù)據(jù)），只要數(shù)據(jù)匯集到數(shù)倉中，整個企業(yè)都訪問和使用，從而方便大家來全面的了解業(yè)務。我們的數(shù)據(jù)工程師和業(yè)務分析師可以將這些不同來源的相關(guān)數(shù)據(jù)應用于商業(yè)智能（BI）和人工智能（AI）等方面，以便帶來更好的預測，并最終為我們作出更好的業(yè)務決策。
企業(yè)為什么需要實時數(shù)據(jù)倉庫
傳統(tǒng)意義上的數(shù)據(jù)倉庫主要處理T+1數(shù)據(jù)，即今天產(chǎn)生的數(shù)據(jù)分析結(jié)果明天才能看到，T+1的概念來源于股票交易，是一種股票交易制度，即當日買進的股票要到下一個交易日才能賣出。
隨著互聯(lián)網(wǎng)以及很多行業(yè)線上業(yè)務的快速發(fā)展，讓數(shù)據(jù)體量以前所未有的速度增長，數(shù)據(jù)時效性在企業(yè)運營中的重要性日益凸現(xiàn)，企業(yè)對海量數(shù)據(jù)的處理有了更高要求，如非結(jié)構(gòu)化數(shù)據(jù)處理、快速批處理、實時數(shù)據(jù)處理、全量數(shù)據(jù)挖掘等。由于傳統(tǒng)數(shù)據(jù)倉庫側(cè)重結(jié)構(gòu)化數(shù)據(jù)，建模路徑較長，面對大規(guī)模數(shù)據(jù)處理能力有限，企業(yè)急需提升大數(shù)據(jù)處理時效，以更經(jīng)濟的方式發(fā)掘數(shù)據(jù)價值。
數(shù)據(jù)的實時處理能力也成為企業(yè)提升競爭力的一大因素。
數(shù)據(jù)處理流程
在了解數(shù)倉如何實時處理之前，我們先來了解數(shù)據(jù)的分層。每個企業(yè)根據(jù)自己的業(yè)務需求可以分成不同的層次，但是最基礎的分層思想，理論上數(shù)據(jù)分為三個層：貼源層（ODS)、數(shù)據(jù)倉庫層（DW）、數(shù)據(jù)服務層(APP/DWA)?；谶@個基礎分層之上滿足不同的業(yè)務需求。
ODS：Operation Data Store，也稱為貼源層。數(shù)據(jù)倉庫源頭系統(tǒng)的數(shù)據(jù)表通常會原封不動的存儲一份，這稱為ODS層，是后續(xù)數(shù)據(jù)倉庫加工數(shù)據(jù)的來源。
DW數(shù)據(jù)分層，由下到上一般分為DWD，DWB，DWS。
DWD：Data Warehouse Details 細節(jié)數(shù)據(jù)層，是業(yè)務層與數(shù)據(jù)倉庫的隔離層。主要對ODS數(shù)據(jù)層做一些數(shù)據(jù)清洗(去除空值、臟數(shù)據(jù)、超過極限范)和規(guī)范化的操作。
DWB：Data Warehouse Base 數(shù)據(jù)基礎層，存儲的是客觀數(shù)據(jù)，一般用作中間層，可以認為是大量指標的數(shù)據(jù)層。
DWS：Data Warehouse Service 數(shù)據(jù)服務層，基于DWB上的基礎數(shù)據(jù)，主要是對用戶行為進行輕度聚合，整合匯總成分析某一個主題域的服務數(shù)據(jù)層，一般是寬表。用于提供后續(xù)的業(yè)務查詢，OLAP分析，數(shù)據(jù)分發(fā)等。
數(shù)據(jù)服務層/應用層(APP/DWA)：該層主要是提供數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析使用的數(shù)據(jù)，我們通過說的報表數(shù)據(jù)，或者說那種大寬表，一般就放在這里。
實時數(shù)倉的常見方案
當前，數(shù)據(jù)倉庫被分為離線數(shù)倉和實時數(shù)倉，離線數(shù)倉一般是傳統(tǒng)的T+1型數(shù)據(jù)ETL方案，而實時數(shù)倉一般是分鐘級甚至是秒級ETL方案。并且，離線數(shù)倉和實時數(shù)倉的底層架構(gòu)也不一樣，離線數(shù)倉一般采用傳統(tǒng)大數(shù)據(jù)架構(gòu)模式搭建，而實時數(shù)倉則采用Lambda、Kappa等架構(gòu)搭建。
LAMBDA & KAPPA 實時架構(gòu)
目前，實時處理有兩種典型的架構(gòu)：Lambda 和 Kappa 架構(gòu)。出于歷史原因，這兩種架構(gòu)的產(chǎn)生和發(fā)展都具有一定局限性。
Lambda架構(gòu)：在離線大數(shù)據(jù)架構(gòu)的基礎上增加新鏈路用于實時數(shù)據(jù)處理，需要維護離線處理和實時處理兩套代碼；
Lambda 架構(gòu)通過把數(shù)據(jù)分解為服務層（Serving Layer）、速度層（Speed Layer，亦即流處理層）、批處理層（Batch Layer）三層來解決不同數(shù)據(jù)集的數(shù)據(jù)需求。在批處理層主要對離線數(shù)據(jù)進行處理，將接入的數(shù)據(jù)進行預處理和存儲，查詢直接在預處理結(jié)果上進行，不需再進行完整的計算，最后以批視圖的形式提供給業(yè)務應用。
在實際生產(chǎn)環(huán)境中的部署通?？梢詤⒁娤聢D，一般要通過一系列不同的存儲和計算引擎 (HBase、Druid、Hive、Presto、Redis 等) 復雜協(xié)同才能滿足業(yè)務的實時需求，此外多個存儲之間需要通過數(shù)據(jù)同步任務保持大致的同步。Lambda 架構(gòu)在實際落地過程中極其復雜，使整個業(yè)務的開發(fā)耗費了大量的時間。
缺點：
(1) 由多個引擎和系統(tǒng)組合而成，批處理 (Batch)、流處理 (Streaming) 以及合并查詢 (Merged Query) 的實現(xiàn)需要使用不同的開發(fā)語言，造成開發(fā)、維護和學習成本較高；(2) 數(shù)據(jù)在不同的視圖 (View) 中存儲多份，浪費存儲空間，數(shù)據(jù)一致性的問題難以解決。
Kappa架構(gòu)：希望做到批流合一，離線處理和實時處理整合成一套代碼，減小運維成本。Kappa 架構(gòu)在 Lambda 架構(gòu)的基礎上移除了批處理層，利用流計算的分布式特征，加大流數(shù)據(jù)的時間窗口，統(tǒng)一批處理和流處理，處理后的數(shù)據(jù)可以直接給到業(yè)務層使用。因為在 Kappa 架構(gòu)下，作業(yè)處理的是所有歷史數(shù)據(jù)和當前數(shù)據(jù)，其產(chǎn)生的結(jié)果我們稱之為實時批視圖（Realtime_Batch_View）。
Kappa 架構(gòu)的流處理系統(tǒng)通常使用 Spark Streaming 或者 Flink 等實現(xiàn)，服務層通常使用MySQL 或 HBase 等實現(xiàn)。
Kappa 架構(gòu)部署圖
缺點：(1) 依賴 Kafka 等消息隊列來保存所有歷史，而Kafka 難以實現(xiàn)數(shù)據(jù)的更新和糾錯，發(fā)生故障或者升級時需要重做所有歷史，周期較長；(2) Kappa 依然是針對不可變更數(shù)據(jù)，無法實時匯集多個可變數(shù)據(jù)源形成的數(shù)據(jù)集快照，不適合即席查詢。
因為上述的缺點，Kappa架構(gòu)在現(xiàn)實中很少被應用。
湖倉一體能否解決實時問題？
時下熱門的湖倉一體能否解決實時問題呢？湖倉一體有何標準？Gartner 認為湖倉一體是將數(shù)據(jù)湖的靈活性和數(shù)倉的易用性、規(guī)范性、高性能結(jié)合起來的融合架構(gòu)，無數(shù)據(jù)孤島。
作為數(shù)據(jù)湖和數(shù)據(jù)倉庫的完美結(jié)合，新一代的湖倉一體架構(gòu)重點關(guān)注和解決了近年來數(shù)字化轉(zhuǎn)型帶來的業(yè)務需求和技術(shù)難點，具體包括如下以下方面：
1.實時性成為了提升企業(yè)競爭力的核心手段。目前的湖、倉、或者湖倉分體都是基于 T+1 設計的，面對 T+0 的實時按需分析，用戶的需求無法滿足。
2.所有用戶（BI 用戶、數(shù)據(jù)科學家等）可以共享同一份數(shù)據(jù)，避免數(shù)據(jù)孤島。
3.超高并發(fā)能力，支持數(shù)十萬用戶使用復雜分析查詢并發(fā)訪問同一份數(shù)據(jù)。
4.傳統(tǒng) Hadoop 在事務支持等方面的不足被大家詬病，在高速發(fā)展之后未能延續(xù)熱度，持續(xù)引領數(shù)據(jù)管理，因此事務支持在湖倉一體架構(gòu)中應得到改善和提升。
5.云原生數(shù)據(jù)庫已經(jīng)逐漸成熟，基于存算分離技術(shù)，可以給用戶帶來多種價值：降低技術(shù)門檻、減少維護成本、提升用戶體驗、節(jié)省資源費用，已成為了湖倉一體落地的重要法門。
6.為釋放數(shù)據(jù)價值提升企業(yè)智能化水平，數(shù)據(jù)科學家等用戶角色必須通過多種類型數(shù)據(jù)進行全域數(shù)據(jù)挖掘，包括但不限于歷史的、實時的、在線的、離線的、內(nèi)部的、外部的、結(jié)構(gòu)化的、非結(jié)構(gòu)化數(shù)據(jù)。
云原生數(shù)據(jù)倉庫 + Omega實時架構(gòu) 實現(xiàn)實時湖倉
云原生數(shù)據(jù)庫實現(xiàn)完全的存算分離
云原生數(shù)據(jù)庫如 OushuDB 和 Snowflake 突破了傳統(tǒng) MPP 和 Hadoop 的局限性，實現(xiàn)了存算完全分離，計算和存儲可部署在不同物理集群，并通過虛擬計算集群技術(shù)實現(xiàn)了高并發(fā)，同時保障事務支持，成為湖倉一體實現(xiàn)的關(guān)鍵技術(shù)。以 OushuDB 為例，實現(xiàn)了存算分離的云原生架構(gòu)，并通過虛擬計算集群技術(shù)在數(shù)十萬節(jié)點的超大規(guī)模集群上實現(xiàn)了高并發(fā)，保障事務支持，提供實時能力，一份數(shù)據(jù)再無數(shù)據(jù)孤島。
基于Omega實時框架的湖倉方案
我們前面提到，既然 Kappa 架構(gòu)實際落地困難，Lambda 架構(gòu)又很難保障數(shù)據(jù)的一致性，兩個架構(gòu)又都很難處理可變更數(shù)據(jù)（如關(guān)系數(shù)據(jù)庫中不停變化的實時數(shù)據(jù)），那么自然需要一種新的架構(gòu)滿足企業(yè)實時分析的全部需求，這就是 Omega 全實時架構(gòu)，Omega 架構(gòu)由偶數(shù)科技根據(jù)其在各行業(yè)的實踐提出，同時滿足實時流處理、實時按需分析和離線分析。
Omega 架構(gòu)由流數(shù)據(jù)處理系統(tǒng)和實時數(shù)倉構(gòu)成。相比 Lambda 和 Kappa，Omega 架構(gòu)新引入了實時數(shù)倉和快照視圖 (Snapshot View) 的概念，快照視圖是歸集了可變更數(shù)據(jù)源和不可變更數(shù)據(jù)源后形成的 T+0 實時快照，可以理解為所有數(shù)據(jù)源在實時數(shù)倉中的鏡像和歷史，隨著源庫的變化實時變化。
因此，實時查詢可以通過存儲于實時數(shù)倉的快照視圖得以實現(xiàn)。實時快照提供的場景可以分為兩大類：一類是多個源庫匯集后的跨庫查詢，比如一個保險用戶的權(quán)益視圖；另一類是任意時間粒度的分析查詢，比如最近 5 分鐘的交易量、最近 10 分鐘的信用卡開卡量等等。
另外，任意時間點的歷史數(shù)據(jù)都可以通過 T+0 快照得到（為了節(jié)省存儲，T+0 快照可以拉鏈形式存儲在實時數(shù)倉 ODS 中，所以快照視圖可以理解為實時拉鏈），這樣離線查詢可以在實時數(shù)倉中完成，離線查詢結(jié)果可以包含最新的實時數(shù)據(jù)，完全不再需要通過傳統(tǒng)MPP+Hadoop湖倉分體組合來處理離線跑批及分析查詢。
Omega 架構(gòu)邏輯圖
流處理系統(tǒng)既可以實現(xiàn)實時連續(xù)的流處理，也可以實現(xiàn) Kappa 架構(gòu)中的批流一體，但與Kappa 架構(gòu)不同的是，OushuDB 實時數(shù)倉存儲來自 Kafka 的全部歷史數(shù)據(jù)（詳見下圖），而在 Kappa 架構(gòu)中源端采集后通常存儲在 Kafka 中。
Omega 架構(gòu)部署圖
因此，當需要流處理版本變更的時候，流處理引擎不再需要訪問 Kafka，而是訪問實時數(shù)倉 OushuDB 獲得所有歷史數(shù)據(jù)，規(guī)避了 Kafka 難以實現(xiàn)數(shù)據(jù)更新和糾錯的問題，大幅提高效率。此外，整個服務層也可以在實時數(shù)倉中實現(xiàn)，而無需額外引入 MySQL、HBase 等組件，極大簡化了數(shù)據(jù)架構(gòu)，實現(xiàn)了湖倉市一體（數(shù)據(jù)湖、數(shù)倉、集市一體）。實現(xiàn)了全實時 Omega 架構(gòu)的湖倉一體，我們也稱之為實時湖倉一體。
Omega vs. Lambda vs. Kappa
結(jié)語：
面對復雜多變的新業(yè)務場景，隨著數(shù)據(jù)技術(shù)不斷成熟，新的實時技術(shù)棧會出現(xiàn)，數(shù)據(jù)技術(shù)也會經(jīng)歷分離與融合。目前，融合的趨勢比較明顯，如實時湖倉一體，將實時處理能力融入數(shù)據(jù)倉庫中。不論企業(yè)如何選型實時數(shù)倉，數(shù)據(jù)平臺技術(shù)棧的建設一般都應該遵循三條基本原則：
1.架構(gòu)層面要保持靈活開放，支持多種技術(shù)兼容性并存。目前，企業(yè)已經(jīng)部署了多個系統(tǒng)，有自己的一套架構(gòu)體系，技術(shù)融合落地時需要最大化利用企業(yè)原有IT資產(chǎn)，保護客戶投資。
2.有效利用資源，降本增效。原來傳統(tǒng)的技術(shù)棧，所有資源參與計算，造成IT資源浪費。比如，云原生資源池化，可以實現(xiàn)資源隔離與動態(tài)管理，便于最大化利用資源。
3.滿足更高的用戶體驗。從用戶角度來看，在技術(shù)條件具備的前提下，比如高性能、高并發(fā)、實時性更強，便具備了更強的信息加工能力，能夠在很短的時間內(nèi)滿足用戶各種各樣的數(shù)據(jù)服務需求，提升用戶體驗。
隨著實時分析場景日益增多，實時數(shù)倉等具備實時處理能力的產(chǎn)品與解決方案將會得到更廣泛的應用。
（本內(nèi)容屬于網(wǎng)絡轉(zhuǎn)載，文中涉及圖片等內(nèi)容如有侵權(quán)，請聯(lián)系編輯刪除。市場有風險，選擇需謹慎！此文僅供參考，不作買賣及投資依據(jù)。）
原創(chuàng)文章，作者：陳晨，如若轉(zhuǎn)載，請注明出處：http://m.2079x.cn/article/561808.html
