離線數倉和實時數倉的區別

01

數倉架構演變

20世紀70年代，MIT(麻省理工)的研究員致力于研究一種優化的技術架構，該架構試圖將業務處理系統和分析系統分開，即將業務處理和分析處理分為不同層次，針對各自的特點采取不同的架構設計原則，MIT的研究員認為這兩種信息處理的方式具有顯著差別，以至于必須采取完全不同的架構和設計方法。但受限于當時的信息處理能力，這個研究僅僅停留在理論層面。

1991年，比爾·恩門（Bill Inmon）出版了他的第一本關于數據倉庫的書《Building the Data Warehouse》，標志著數據倉庫概念的確立。該書定義了數據倉庫非常具體的原則，這些原則到現在仍然是指導數據倉庫建設的最基本原則。比爾·恩門（Bill Inmon）主張自上而下的建設企業級數據倉庫EDW （Enterprise Data Warehouse），這個過程中信息存儲符合第三范式，結構如下：

由于企業級數據倉庫的設計、實施很困難，很重要的原因是因為其數據模型設計，在企業級數據倉庫中，Inmon推薦采用3范式進行數據建模，從而無法支持決策支持（DSS -Decision Suport System ）系統的性能和數據易訪問性的要求，即：數據存儲方式嚴格按照范式建模方式，導致數據分析效率低下。很多公司按照這種方式構建數據倉庫遭到失敗。

同時期，拉爾夫·金博爾（Ralph Kimball）提出自下而上的建立數據倉庫，整個過程中信息存儲采用維度建模而非三范式，思路如下：

維度建模方式沒有采用三范式方式設計存儲數據，適用于數據分析場景，以上設計方式構建數據倉庫實施難度大大降低，并且能夠滿足公司內部部分業務部門的迫切需求，在初期獲得了較大成功。

但是很快，他們也發現自己陷入了某種困境：隨著數據集市的不斷增多，這種架構的缺陷也逐步顯現，公司內部獨立建設的數據集市由于遵循不同的標準和建設原則，以致多個數據集市的數據混亂和不一致，解決以上問題，還需回歸到范式建模。

1998年，Bill Inmon提出了新的BI架構CIF(Corporation information factory)，CIF的核心是將數倉架構劃分為不同的層次以滿足不同場景的需求，比如常見的ODS、DW、DM等，每層根據實際場景采用不同的建設方案，現在CIF已經成為建設數據倉庫的框架指南。 隨著時代的發展，到今天數據倉庫建設理論也是基于CIF架構建設方案演化而來。同時數據倉庫的概念越來越精確，數據倉庫定義如下： 數據倉庫，Data Warehouse，可簡寫為DW或DWH。數據倉庫是面向主題的、集成的（非簡單的數據堆積）、相對穩定的、反應歷史變化的數據集合，數倉中的數據是有組織有結構的存儲數據集合，用于對管理決策過程的支持。

01

傳統離線大數據架構

21世紀初隨著互聯網時代的到來，數據量暴增，大數據時代到來。Hadoop生態群及衍生技術慢慢走向“舞臺”，Hadoop是以HDFS為核心存儲，以MapReduce（簡稱MR）為基本計算模型的批量數據處理基礎設施，圍繞HDFS和MR，產生了一系列的組件，不斷完善整個大數據平臺的數據處理能力，

例如面向KV操作的HBase、面向SQL分析的Hive、面向工作流的PIG等。以Hadoop為核心的數據存儲及數據處理技術逐漸成為數據處理中的“中流砥柱”，部分技術棧如下圖所示：

這個時期，在企業信息化的過程中，隨著信息化工具的升級和新工具的應用，數據量變的越來越大，數據格式越來越多，決策要求越來越苛刻，數據倉庫技術在大數據場景中被廣泛使用。大數據中的數據倉庫構建就是基于經典數倉架構而來，使用大數據中的工具來替代經典數倉中的傳統工具，架構建設上沒有根本區別。在離線大數據架構中離線數倉結構如下:

隨著數據處理能力和處理需求的不斷變化，越來越多的用戶發現，批處理模式無論如何提升性能，也無法滿足一些實時性要求高的處理場景，流式計算引擎應運而生，例如Storm、Spark Streaming、Flink等。 以上離線大數據架構不能夠處理實時性業務，早期，很過公司都是基于Storm來處理處理實時性比較強的業務場景，隨著越來越多的應用上線，大家發現，其實批處理和流計算配合使用，才能滿足大部分應用需求。而對于用戶而言，其實他們并不關心底層的計算模型是什么，用戶希望無論是批處理還是流計算，都能基于統一的數據模型來返回處理結果，于是Lambda架構被提出。

02

Lambda架構

在Lambda架構中，為了計算一些實時指標，就在原來的離線數倉基礎之上增加了一個實時計算的鏈路，并對數據源做流式改造：把消息發送到消息隊列中（大數據中常用Kafka），實時計算去消費消息隊列中的數據，完成實時指標計算，推送到下游的數據服務中去，由數據服務層完成離線與實時結果的合并。 Lambda架構中數據從底層的數據源開始，經過各種各樣的格式進入大數據平臺，在大數據平臺中經過Kafka、Flume等數據組件進行收集，然后分成兩條線進行計算。一條線是進入流式計算平臺（例如 Storm、Flink或者Spark Streaming），去計算實時的一些指標，保證數據實時性；另一條線進入批量數據處理離線計算平臺（例如Mapreduce、Hive，Spark SQL），去計算T+1的相關業務指標，這些指標需要隔日才能看見，保證數據有效、準確性。

根據實時業務統計的復雜程度Lambda架構也分為以下兩種情況。

離線數據+實時處理鏈路(傳統實時開發)

根據實時鏈路中實時指標計算的復雜程度，開始實時業務不復雜，都是“煙囪（cong）式”開發設計，不需要構建實時數倉，我們可以選擇不分層，這種場景下Lambda架構中是由離線數倉和實時業務處理部分組成，這部分實時還達不到叫做實時數倉階段，只能叫做實時處理鏈路，其結構如下：

注意：“煙囪式”開發：在一個有一定規模的企業中，通常都會存在各種各樣的應用系統，它們分別由企業的各個不同部門、在各種不同歷史時期、為滿足各種不同業務目的而開發。由于數據格式沒有統一規范，相互之間沒有聯通、數據更沒有整合，像一個個煙囪，因此稱其為“煙囪式系統”。同樣，在數據處理過程中，各個數據處理程序之間不能很好做到數據規范統一、處理數據流程統一、數據復用，各自獨立，叫做“煙囪式”開發。

離線數倉+實時數倉

隨著企業實時業務增多，統計的實時指標越來越多，復雜程度也越來越高，為了在實時鏈路中更好的復用數據，這是就有必要在實時鏈路中加入數據分層設計，構建真正的實時數倉。這種場景下Lambda架構中是由離線數倉和實時數倉兩部分組成，其結構如下：

以上Lambda架構中“實時處理鏈路”這種傳統實時與“實時數倉”區別在于，傳統實時“煙囪式”開發導致代碼耦合問題嚴重，當需求越來越多，有時需要明細數據，有時需要OLAP分析，這種模式難以應付這些需求，缺少完善的規范?！皩崟r數倉”在保證數據實時性的前提下，實現了數據基于數據倉庫管理，更加統一規范化，穩定性和業務性更強。 在Lambda架構中流處理計算的指標批處理依然計算，最終以批處理結果為準，即每次批處理計算后會覆蓋流處理的結果，這是由于流處理過程中不完善做的折中辦法，由數據服務處理，其功能主要是合并離線計算和實時計算結果。 例如：在統計實時交易訂單時，可能實時統計的結果需要當日分鐘級別向外展示，T+1后才能展示昨日總的交易訂單數，顯然，后者是T+1每日離線批處理統計結果，那么假設當日有些用戶進行了訂單取消有可能T+1后統計統計結果與當日實時展示數據出現不一致問題，那么這里就需要使用數據服務來進行處理，統一數據，決定如何使用數據。

Lambda數據架構成為每一個公司大數據平臺必備的架構，它解決了一個公司大數據批量離線處理和實時數據處理的需求。Lambda架構的核心理念是“流批一體”，如上圖所示，整個數據流向自左向右流入平臺。進入平臺后一分為二，一部分走批處理模式，一部分走流式計算模式。 無論哪種計算模式，最終的處理結果都通過統一服務層對應用提供，確保訪問的一致性，底層到底是批或流對用戶透明。經歷多年的發展，Lambda架構優點是穩定，對于實時計算部分的計算成本可控，批量處理可以用晚上的時間來整體批量計算，這樣把實時計算和離線計算高峰分開，但是它也有一些致命缺點：1)同樣的需求需要開發兩套一樣的代碼這是Lambda架構最大的問題，針對同一個需求需要開發兩套代碼，一個在批處理引擎上實現，一個在流處理引擎上實現，在寫好代碼后還需構造數據測試保證兩者結果一致，另外，兩套代碼對于后期維護也非常麻煩，一旦需求變更，兩套代碼都需要修改，并且兩套代碼也需同時上線。2)集群資源使用增多同樣的邏輯需要計算兩次，整體占用資源會增多。雖然離線部分是在凌晨運行，但是有可能任務多，在凌晨時造成集群資源使用暴增，報表產出效率就有可能下降，報表延遲對后續展示也有影響。3)離線結果和實時結果不一致在此架構中經常我們看到次日統計的結果比昨晚的結果要少，原因就在于次日統計結果和昨日統計結果走了兩條線的計算方式：次日統計結果是按照批處理得到了更為準確的批量處理結果。昨晚看的結果是通過流式運行的結果，依靠實時鏈路統計出的實時結果（實時結果統計累加），犧牲了部分準確性。對于這種來自批量和實時的數據結果對不上的問題，無解。4)批量計算T+1可能計算不完隨著物聯網時代的到來，一些企業中數據量級越來越大，經常發現夜間運行批量任務已經無法完成白天20多個小時累計的數據，保證早上上班前準時出現數據已成為部分大數據團隊頭疼的問題。5)服務器存儲大由于批流兩個過程都需要將數據存儲在集群中，并且中間也會產生大量臨時數據，會造成數據急速膨脹，加大服務器存儲壓力。

03

Kappa架構

隨著Flink等流式處理引擎的不斷完善，流處理技術相關的技術成熟發展（例如：Kafka、ClickHouse），針對Lambda架構的需要維護兩套程序等以上缺點，LinkedIn的Jay Kreps結合實際經驗和個人體會提出了Kappa架構。 Kappa架構的核心思想是通過改進流計算系統來解決數據全量處理的問題，使得實時計算和批處理過程使用同一套代碼。此外Kappa架構認為只有在有必要的時候才會對歷史數據進行重復計算，而如果需要重復計算時，Kappa架構下可以啟動很多個實例進行重復計算,方式是通過上游重放完成(從數據源拉取數據重新計算)。 Kappa架構就是基于流來處理所有數據，流計算天然的分布式特征，注定了他的擴展性更好，通過加大流計算的并發性，加大流式數據的“時間窗口”，來統一批處理與流式處理兩種計算模式。其架構如下：

Kappa架構構建的數倉當之無愧稱為實時數倉，Kappa架構最大的問題是流式重新處理歷史的吞吐能力會低于批處理，但這個可以通過增加計算資源來彌補。重新處理數據看似比較麻煩，但在Kappa架構中并不復雜，其步驟如下：

選擇一個具有重放功能，能夠保存歷史數據的消息隊列，根據要求設置歷史數據保存時長，例如:Kafka，可以設置保存全部歷史數據。

當某個或某些指標有重新處理的需求時，按照新邏輯編寫新的作業，然后從上游消息隊列最開始地方重新消費數據，把結果寫往一個新的下游結果表。

當新作業趕上進度后，切換數據源，讀取新作業產生的結果表。

停止老的作業，刪除老的結果表。

另外，Kappa 架構并不是中間結果完全不落地，現在很多大數據系統都需要支持機器學習（離線訓練），所以實時中間結果需要落地對應的存儲引擎供機器學習使用，另外有時候還需要對明細數據查詢，這種場景也需要把實時明細層寫出到對應的引擎中。

Kappa架構也有一定的缺點，其缺點例如：Kappa架構由于采集的數據格式不統一，每次都需要開發不同的Streaming程序，導致開發周期長。更多Kappa架構的問題在實時數倉發展趨勢中討論。

04

混合結構

傳統離線大數據架構已經不能滿足一些公司中實時業務需求，因為隨著互聯網及物聯網發展，越來越多的公司多多少少涉及一些流式業務處理場景。由Lambda離線數倉+實時數倉架構到Kappa實時數倉架構，都涉及到實時數倉開發，那么現實業務開發中到底使用Lambda架構還是Kappa架構？ 我們可以先看下以上三個架構之間的區別：

通過以上對比來看，三者對比結果如下：從架構上來看，三套架構有比較明顯區別，真正的實時數倉以Kappa架構為主，而離線數倉以傳統離線大數據架構為主，Lambda架構可以認為是兩者的中間態。目前在業界中所說的實時數倉大多是Lambda架構，這是由需求決定的。從建設方法上來看，實時數倉和離線數倉基本還是沿用傳統的數倉主題建模理論，產出事實寬表。另外實時數倉中實時流數據的join有隱藏時間語義，在建設中需注意。從數據保障上來看，實時數倉因為要保證實時性，所以對數據量的變化較為敏感，在大促等場景下需要提前做好壓測和主備保障工作，這是與離線數倉較為明顯的一個區別。 目前在一些沒有實時數據處理場景公司中，使用傳統離線大數據架構居多，在這些公司中離線大數據架構性價比高，比較實用。 在一些涉及到實時業務場景的公司，在實際工作中到底選擇哪種架構，需要根據具體業務需求來決定。很多時候并不是完全規范的Lambda架構或者Kappa架構，可以是兩者的混合，比如大部分實時指標統計使用Kappa架構完成計算，少量關鍵指標使用Lambda架構用批處理重新計算，增加一次校對過程。 為了應對更廣泛的場景，大多數公司采用這種混合架構，離線和實時數據鏈路都存在，根據每個業務需求選擇在合適的鏈路上來實現。注意：這種方式并不是Lambda架構，例如：某企業有多個業務模塊，某些業務模塊需要運行在Lambda架構中，某些業務模塊需要運行在Kappa架構中。

02

離線數倉與實時數倉區別

離線數據與實時數倉區別如下：

03

實時數倉建設思路

在實時數倉中計算框架選型建議優先選擇Flink，其具有“流批一體”特性，并且在處理復雜業務場景上性能優異，在實時處理中有逐漸替代spark的趨勢。 在實時數倉分層方面，實時數倉可采用離線數倉的數據模型進行分層處理，目前建議選擇Kafka，實時數倉的數據來源可以為kafka消息隊列，這樣可以做到隊列中的數據既可以寫入HDFS用于批量分析，也可以實時處理，下游可以寫入數據集市供業務使用。如果實時數據量不大也可以將實時明細層寫入ClickHouse、Druid等查詢效率高的存儲方便下游使用，輕度匯總層對數據進行匯總分析后供下游使用。 在數據存儲選型中首要考慮查詢效率，其次是插入、更新等問題，這里說的存儲時最終計算數據結果的存儲，可選擇ClickHouse、Hbase、apache Druid、Redis等，頻繁更新的數據建議不要采用ClickHouse與Druid。當然存儲這塊需要具體問題具體分析，不同場景下hbase、redis等都是可選項。

04

實時數倉發展趨勢

01

實時數倉現狀

當前基于Hive的離線數據倉庫已經非常成熟，隨著實時計算引擎的不斷發展以及業務對于實時報表的產出需求不斷膨脹，業界最近幾年就一直聚焦并探索于實時數倉建設。根據數倉架構演變過程，在Lambda架構中含有離線處理與實時處理兩條鏈路，其架構圖如下：

正是由于兩條鏈路處理數據導致數據不一致等一些列問題所以才有了Kappa架構，Kappa架構如下：

Kappa架構可以稱為真正的實時數倉，目前在業界最常用實現就是Flink + Kafka，然而基于Kafka+Flink的實時數倉方案也有幾個非常明顯的缺陷，所以在目前很多企業中實時數倉構建中經常使用混合架構，沒有實現所有業務都采用Kappa架構中實時處理實現。Kappa架構缺陷如下：

Kafka無法支持海量數據存儲。

對于海量數據量的業務線來說，Kafka一般只能存儲非常短時間的數據，比如最近一周，甚至最近一天。

Kafka無法支持高效的OLAP查詢，大多數業務都希望能在DWDDWS層支持即席查詢的，但是Kafka無法非常友好地支持這樣的需求。

無法復用目前已經非常成熟的基于離線數倉的數據血緣、數據質量管理體系。

需要重新實現一套數據血緣、數據質量管理體系。

Kafka不支持update/upsert，目前Kafka僅支持append。

實際場景中在DWS輕度匯聚層很多時候是需要更新的，DWD明細層到DWS輕度匯聚層一般會根據時間粒度以及維度進行一定的聚合，用于減少數據量，提升查詢性能。

假如原始數據是秒級數據，聚合窗口是1分鐘，那就有可能產生某些延遲的數據經過時間窗口聚合之后需要更新之前數據的需求。

這部分更新需求無法使用Kafka實現。

所以實時數倉發展到現在的架構，一定程度上解決了數據報表時效性問題，但是這樣的架構依然存在不少問題，隨著技術的發展，相信基于Kafka+Flink的實時數倉架構也會進一步往前發展，那么到底往哪些方向發展，我們可以結合大公司中技術選型可以推測實時數倉的發展大致會走向“批流一體”。

02

批流一體

最近一兩年中和實時數倉一樣火的概念是“批流一體”，那么到底什么是“批流一體”？在業界中很多人認為批和流在開發層面上都統一到相同的SQL上處理是批流一體，也有一些人認為在計算引擎層面上批和流可以集成在同一個計算引擎是批流一體，比如：Spark/SparkStreaming/Structured Streaming/Flink框架在計算引擎層面上實現了批處理和流處理集成。

以上無論是在業務SQL使用上統一還是計算引擎上的統一，都是批流一體的一個方面，除此之外，批流一體還有一個最核心的方面就是存儲層面上的統一。這個方面上也有一些流行的技術：delta/hudi/iceberg,存儲一旦能夠做到統一，例如：一些大型公司使用Iceberg作為存儲，那么Kappa架構中很多問題都可以得到解決，Kappa架構將變成個如下模樣：

這條架構中無論是流處理還是批處理，數據存儲都統一到數據湖Iceberg上，這一套結構將存儲統一后，解決了Kappa架構很多痛點，解決方面如下：

可以解決Kafka存儲數據量少的問題。

目前所有數據湖基本思路都是基于HDFS之上實現的一個文件管理系統，所以數據體量可以很大。

DW層數據依然可以支持OLAP查詢。

同樣數據湖基于HDFS之上實現，只需要當前的OLAP查詢引擎做一些適配就可以進行OLAP查詢。

批流存儲都基于Iceberg/HDFS存儲之后，就完全可以復用一套相同的數據血緣、數據質量管理體系。

實時數據的更新。

上述架構也可以認為是Kappa架構的變種，也有兩條數據鏈路，一條是基于Spark的離線數據鏈路，一條是基于Flink的實時數據鏈路，通常數據都是直接走實時鏈路處理，而離線鏈路則更多的應用于數據修正等非常規場景。這樣的架構要成為一個可以落地的實時數倉方案、可以做到實時報表產生，這得益于Iceberg技術：

支持流式寫入-增量拉取

流式寫入其實現在基于Flink就可以實現，無非是將checkpoint間隔設置的短一點，比如1分鐘，就意味每分鐘生成的文件就可以寫入到HDFS，這就是流式寫入。但是這里有兩個問題，第一個問題是小文件很多，但這不是最關鍵的，第二個問題才是最致命的，就是上游每分鐘提交了很多文件到HDFS上，下游消費的Flink是不知道哪些文件是最新提交的，因此下游Flink就不知道應該去消費處理哪些文件。

這個問題才是離線數倉做不到實時的最關鍵原因之一，離線數倉的玩法是說上游將數據全部導入完成了，告訴下游說這波數據全部導完了，你可以消費處理了，這樣的話就做不到實時處理。

數據湖就解決了這個問題。實時數據鏈路處理的時候上游Flink寫入的文件進來之后，下游就可以將數據文件一致性地讀走。這里強調一致性地讀，就是不能多讀一個文件也不能少讀一個文件。上游這段時間寫了多少文件，下游就要讀走多少文件。我們稱這樣的讀取叫增量拉取。

解決小文件多的問題

數據湖實現了相關合并小文件的接口，Spark/Flink上層引擎可以周期性地調用接口進行小文件合并。

支持批量以及流式的Upsert(Delete)功能

批量Upsert/Delete功能主要用于離線數據修正。流式upsert場景上文介紹了，主要是流處理場景下經過窗口時間聚合之后有延遲數據到來的話會有更新的需求。這類需求是需要一個可以支持更新的存儲系統的，而離線數倉做更新的話需要全量數據覆蓋，這也是離線數倉做不到實時的關鍵原因之一，數據湖是需要解決掉這個問題的。

支持比較完整的OLAP生態

比如支持Hive/Spark/Presto/Impala等OLAP查詢引擎，提供高效的多維聚合查詢性能。

目前Iceberg部分功能還在開發中，有一些功能還不完善，但是整體實時數倉的發展會大致朝著這個方向行進。目前業界大多數公司還是處于Lambda架構，使用Kappa架構的公司一般都是實時業務居多的公司，隨著數據湖技術的發展，這些公司實時數倉的構建慢慢會走向最終的“批流一體”。

審核編輯 ：李倩