離線數(shù)倉(cāng)和實(shí)時(shí)數(shù)倉(cāng)的區(qū)別

01

數(shù)倉(cāng)架構(gòu)演變

20世紀(jì)70年代，MIT(麻省理工)的研究員致力于研究一種優(yōu)化的技術(shù)架構(gòu)，該架構(gòu)試圖將業(yè)務(wù)處理系統(tǒng)和分析系統(tǒng)分開，即將業(yè)務(wù)處理和分析處理分為不同層次，針對(duì)各自的特點(diǎn)采取不同的架構(gòu)設(shè)計(jì)原則，MIT的研究員認(rèn)為這兩種信息處理的方式具有顯著差別，以至于必須采取完全不同的架構(gòu)和設(shè)計(jì)方法。但受限于當(dāng)時(shí)的信息處理能力，這個(gè)研究?jī)H僅停留在理論層面。

1991年，比爾·恩門（Bill Inmon）出版了他的第一本關(guān)于數(shù)據(jù)倉(cāng)庫(kù)的書《Building the Data Warehouse》，標(biāo)志著數(shù)據(jù)倉(cāng)庫(kù)概念的確立。該書定義了數(shù)據(jù)倉(cāng)庫(kù)非常具體的原則，這些原則到現(xiàn)在仍然是指導(dǎo)數(shù)據(jù)倉(cāng)庫(kù)建設(shè)的最基本原則。比爾·恩門（Bill Inmon）主張自上而下的建設(shè)企業(yè)級(jí)數(shù)據(jù)倉(cāng)庫(kù)EDW （Enterprise Data Warehouse），這個(gè)過程中信息存儲(chǔ)符合第三范式，結(jié)構(gòu)如下：

由于企業(yè)級(jí)數(shù)據(jù)倉(cāng)庫(kù)的設(shè)計(jì)、實(shí)施很困難，很重要的原因是因?yàn)槠鋽?shù)據(jù)模型設(shè)計(jì)，在企業(yè)級(jí)數(shù)據(jù)倉(cāng)庫(kù)中，Inmon推薦采用3范式進(jìn)行數(shù)據(jù)建模，從而無(wú)法支持決策支持（DSS -Decision Suport System ）系統(tǒng)的性能和數(shù)據(jù)易訪問性的要求，即：數(shù)據(jù)存儲(chǔ)方式嚴(yán)格按照范式建模方式，導(dǎo)致數(shù)據(jù)分析效率低下。很多公司按照這種方式構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)遭到失敗。

同時(shí)期，拉爾夫·金博爾（Ralph Kimball）提出自下而上的建立數(shù)據(jù)倉(cāng)庫(kù)，整個(gè)過程中信息存儲(chǔ)采用維度建模而非三范式，思路如下：

維度建模方式?jīng)]有采用三范式方式設(shè)計(jì)存儲(chǔ)數(shù)據(jù)，適用于數(shù)據(jù)分析場(chǎng)景，以上設(shè)計(jì)方式構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)實(shí)施難度大大降低，并且能夠滿足公司內(nèi)部部分業(yè)務(wù)部門的迫切需求，在初期獲得了較大成功。

但是很快，他們也發(fā)現(xiàn)自己陷入了某種困境：隨著數(shù)據(jù)集市的不斷增多，這種架構(gòu)的缺陷也逐步顯現(xiàn)，公司內(nèi)部獨(dú)立建設(shè)的數(shù)據(jù)集市由于遵循不同的標(biāo)準(zhǔn)和建設(shè)原則，以致多個(gè)數(shù)據(jù)集市的數(shù)據(jù)混亂和不一致，解決以上問題，還需回歸到范式建模。

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

01

傳統(tǒng)離線大數(shù)據(jù)架構(gòu)

21世紀(jì)初隨著互聯(lián)網(wǎng)時(shí)代的到來，數(shù)據(jù)量暴增，大數(shù)據(jù)時(shí)代到來。Hadoop生態(tài)群及衍生技術(shù)慢慢走向“舞臺(tái)”，Hadoop是以HDFS為核心存儲(chǔ)，以MapReduce（簡(jiǎn)稱MR）為基本計(jì)算模型的批量數(shù)據(jù)處理基礎(chǔ)設(shè)施，圍繞HDFS和MR，產(chǎn)生了一系列的組件，不斷完善整個(gè)大數(shù)據(jù)平臺(tái)的數(shù)據(jù)處理能力，

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

這個(gè)時(shí)期，在企業(yè)信息化的過程中，隨著信息化工具的升級(jí)和新工具的應(yīng)用，數(shù)據(jù)量變的越來越大，數(shù)據(jù)格式越來越多，決策要求越來越苛刻，數(shù)據(jù)倉(cāng)庫(kù)技術(shù)在大數(shù)據(jù)場(chǎng)景中被廣泛使用。大數(shù)據(jù)中的數(shù)據(jù)倉(cāng)庫(kù)構(gòu)建就是基于經(jīng)典數(shù)倉(cāng)架構(gòu)而來，使用大數(shù)據(jù)中的工具來替代經(jīng)典數(shù)倉(cāng)中的傳統(tǒng)工具，架構(gòu)建設(shè)上沒有根本區(qū)別。在離線大數(shù)據(jù)架構(gòu)中離線數(shù)倉(cāng)結(jié)構(gòu)如下:

隨著數(shù)據(jù)處理能力和處理需求的不斷變化，越來越多的用戶發(fā)現(xiàn)，批處理模式無(wú)論如何提升性能，也無(wú)法滿足一些實(shí)時(shí)性要求高的處理場(chǎng)景，流式計(jì)算引擎應(yīng)運(yùn)而生，例如Storm、Spark Streaming、Flink等。 以上離線大數(shù)據(jù)架構(gòu)不能夠處理實(shí)時(shí)性業(yè)務(wù)，早期，很過公司都是基于Storm來處理處理實(shí)時(shí)性比較強(qiáng)的業(yè)務(wù)場(chǎng)景，隨著越來越多的應(yīng)用上線，大家發(fā)現(xiàn)，其實(shí)批處理和流計(jì)算配合使用，才能滿足大部分應(yīng)用需求。而對(duì)于用戶而言，其實(shí)他們并不關(guān)心底層的計(jì)算模型是什么，用戶希望無(wú)論是批處理還是流計(jì)算，都能基于統(tǒng)一的數(shù)據(jù)模型來返回處理結(jié)果，于是Lambda架構(gòu)被提出。

02

Lambda架構(gòu)

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

根據(jù)實(shí)時(shí)業(yè)務(wù)統(tǒng)計(jì)的復(fù)雜程度Lambda架構(gòu)也分為以下兩種情況。

離線數(shù)據(jù)+實(shí)時(shí)處理鏈路(傳統(tǒng)實(shí)時(shí)開發(fā))

根據(jù)實(shí)時(shí)鏈路中實(shí)時(shí)指標(biāo)計(jì)算的復(fù)雜程度，開始實(shí)時(shí)業(yè)務(wù)不復(fù)雜，都是“煙囪（cong）式”開發(fā)設(shè)計(jì)，不需要構(gòu)建實(shí)時(shí)數(shù)倉(cāng)，我們可以選擇不分層，這種場(chǎng)景下Lambda架構(gòu)中是由離線數(shù)倉(cāng)和實(shí)時(shí)業(yè)務(wù)處理部分組成，這部分實(shí)時(shí)還達(dá)不到叫做實(shí)時(shí)數(shù)倉(cāng)階段，只能叫做實(shí)時(shí)處理鏈路，其結(jié)構(gòu)如下：

注意：“煙囪式”開發(fā)：在一個(gè)有一定規(guī)模的企業(yè)中，通常都會(huì)存在各種各樣的應(yīng)用系統(tǒng)，它們分別由企業(yè)的各個(gè)不同部門、在各種不同歷史時(shí)期、為滿足各種不同業(yè)務(wù)目的而開發(fā)。由于數(shù)據(jù)格式?jīng)]有統(tǒng)一規(guī)范，相互之間沒有聯(lián)通、數(shù)據(jù)更沒有整合，像一個(gè)個(gè)煙囪，因此稱其為“煙囪式系統(tǒng)”。同樣，在數(shù)據(jù)處理過程中，各個(gè)數(shù)據(jù)處理程序之間不能很好做到數(shù)據(jù)規(guī)范統(tǒng)一、處理數(shù)據(jù)流程統(tǒng)一、數(shù)據(jù)復(fù)用，各自獨(dú)立，叫做“煙囪式”開發(fā)。

離線數(shù)倉(cāng)+實(shí)時(shí)數(shù)倉(cāng)

隨著企業(yè)實(shí)時(shí)業(yè)務(wù)增多，統(tǒng)計(jì)的實(shí)時(shí)指標(biāo)越來越多，復(fù)雜程度也越來越高，為了在實(shí)時(shí)鏈路中更好的復(fù)用數(shù)據(jù)，這是就有必要在實(shí)時(shí)鏈路中加入數(shù)據(jù)分層設(shè)計(jì)，構(gòu)建真正的實(shí)時(shí)數(shù)倉(cāng)。這種場(chǎng)景下Lambda架構(gòu)中是由離線數(shù)倉(cāng)和實(shí)時(shí)數(shù)倉(cāng)兩部分組成，其結(jié)構(gòu)如下：

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

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

03

Kappa架構(gòu)

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

Kappa架構(gòu)構(gòu)建的數(shù)倉(cāng)當(dāng)之無(wú)愧稱為實(shí)時(shí)數(shù)倉(cāng)，Kappa架構(gòu)最大的問題是流式重新處理歷史的吞吐能力會(huì)低于批處理，但這個(gè)可以通過增加計(jì)算資源來彌補(bǔ)。重新處理數(shù)據(jù)看似比較麻煩，但在Kappa架構(gòu)中并不復(fù)雜，其步驟如下：

選擇一個(gè)具有重放功能，能夠保存歷史數(shù)據(jù)的消息隊(duì)列，根據(jù)要求設(shè)置歷史數(shù)據(jù)保存時(shí)長(zhǎng)，例如:Kafka，可以設(shè)置保存全部歷史數(shù)據(jù)。

當(dāng)某個(gè)或某些指標(biāo)有重新處理的需求時(shí)，按照新邏輯編寫新的作業(yè)，然后從上游消息隊(duì)列最開始地方重新消費(fèi)數(shù)據(jù)，把結(jié)果寫往一個(gè)新的下游結(jié)果表。

當(dāng)新作業(yè)趕上進(jìn)度后，切換數(shù)據(jù)源，讀取新作業(yè)產(chǎn)生的結(jié)果表。

停止老的作業(yè)，刪除老的結(jié)果表。

另外，Kappa 架構(gòu)并不是中間結(jié)果完全不落地，現(xiàn)在很多大數(shù)據(jù)系統(tǒng)都需要支持機(jī)器學(xué)習(xí)（離線訓(xùn)練），所以實(shí)時(shí)中間結(jié)果需要落地對(duì)應(yīng)的存儲(chǔ)引擎供機(jī)器學(xué)習(xí)使用，另外有時(shí)候還需要對(duì)明細(xì)數(shù)據(jù)查詢，這種場(chǎng)景也需要把實(shí)時(shí)明細(xì)層寫出到對(duì)應(yīng)的引擎中。

Kappa架構(gòu)也有一定的缺點(diǎn)，其缺點(diǎn)例如：Kappa架構(gòu)由于采集的數(shù)據(jù)格式不統(tǒng)一，每次都需要開發(fā)不同的Streaming程序，導(dǎo)致開發(fā)周期長(zhǎng)。更多Kappa架構(gòu)的問題在實(shí)時(shí)數(shù)倉(cāng)發(fā)展趨勢(shì)中討論。

04

混合結(jié)構(gòu)

傳統(tǒng)離線大數(shù)據(jù)架構(gòu)已經(jīng)不能滿足一些公司中實(shí)時(shí)業(yè)務(wù)需求，因?yàn)殡S著互聯(lián)網(wǎng)及物聯(lián)網(wǎng)發(fā)展，越來越多的公司多多少少涉及一些流式業(yè)務(wù)處理場(chǎng)景。由Lambda離線數(shù)倉(cāng)+實(shí)時(shí)數(shù)倉(cāng)架構(gòu)到Kappa實(shí)時(shí)數(shù)倉(cāng)架構(gòu)，都涉及到實(shí)時(shí)數(shù)倉(cāng)開發(fā)，那么現(xiàn)實(shí)業(yè)務(wù)開發(fā)中到底使用Lambda架構(gòu)還是Kappa架構(gòu)？ 我們可以先看下以上三個(gè)架構(gòu)之間的區(qū)別：

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

02

離線數(shù)倉(cāng)與實(shí)時(shí)數(shù)倉(cāng)區(qū)別

離線數(shù)據(jù)與實(shí)時(shí)數(shù)倉(cāng)區(qū)別如下：

03

實(shí)時(shí)數(shù)倉(cāng)建設(shè)思路

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

04

實(shí)時(shí)數(shù)倉(cāng)發(fā)展趨勢(shì)

01

實(shí)時(shí)數(shù)倉(cāng)現(xiàn)狀

當(dāng)前基于Hive的離線數(shù)據(jù)倉(cāng)庫(kù)已經(jīng)非常成熟，隨著實(shí)時(shí)計(jì)算引擎的不斷發(fā)展以及業(yè)務(wù)對(duì)于實(shí)時(shí)報(bào)表的產(chǎn)出需求不斷膨脹，業(yè)界最近幾年就一直聚焦并探索于實(shí)時(shí)數(shù)倉(cāng)建設(shè)。根據(jù)數(shù)倉(cāng)架構(gòu)演變過程，在Lambda架構(gòu)中含有離線處理與實(shí)時(shí)處理兩條鏈路，其架構(gòu)圖如下：

正是由于兩條鏈路處理數(shù)據(jù)導(dǎo)致數(shù)據(jù)不一致等一些列問題所以才有了Kappa架構(gòu)，Kappa架構(gòu)如下：

Kappa架構(gòu)可以稱為真正的實(shí)時(shí)數(shù)倉(cāng)，目前在業(yè)界最常用實(shí)現(xiàn)就是Flink + Kafka，然而基于Kafka+Flink的實(shí)時(shí)數(shù)倉(cāng)方案也有幾個(gè)非常明顯的缺陷，所以在目前很多企業(yè)中實(shí)時(shí)數(shù)倉(cāng)構(gòu)建中經(jīng)常使用混合架構(gòu)，沒有實(shí)現(xiàn)所有業(yè)務(wù)都采用Kappa架構(gòu)中實(shí)時(shí)處理實(shí)現(xiàn)。Kappa架構(gòu)缺陷如下：

Kafka無(wú)法支持海量數(shù)據(jù)存儲(chǔ)。

對(duì)于海量數(shù)據(jù)量的業(yè)務(wù)線來說，Kafka一般只能存儲(chǔ)非常短時(shí)間的數(shù)據(jù)，比如最近一周，甚至最近一天。

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

無(wú)法復(fù)用目前已經(jīng)非常成熟的基于離線數(shù)倉(cāng)的數(shù)據(jù)血緣、數(shù)據(jù)質(zhì)量管理體系。

需要重新實(shí)現(xiàn)一套數(shù)據(jù)血緣、數(shù)據(jù)質(zhì)量管理體系。

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

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

假如原始數(shù)據(jù)是秒級(jí)數(shù)據(jù)，聚合窗口是1分鐘，那就有可能產(chǎn)生某些延遲的數(shù)據(jù)經(jīng)過時(shí)間窗口聚合之后需要更新之前數(shù)據(jù)的需求。

這部分更新需求無(wú)法使用Kafka實(shí)現(xiàn)。

所以實(shí)時(shí)數(shù)倉(cāng)發(fā)展到現(xiàn)在的架構(gòu)，一定程度上解決了數(shù)據(jù)報(bào)表時(shí)效性問題，但是這樣的架構(gòu)依然存在不少問題，隨著技術(shù)的發(fā)展，相信基于Kafka+Flink的實(shí)時(shí)數(shù)倉(cāng)架構(gòu)也會(huì)進(jìn)一步往前發(fā)展，那么到底往哪些方向發(fā)展，我們可以結(jié)合大公司中技術(shù)選型可以推測(cè)實(shí)時(shí)數(shù)倉(cāng)的發(fā)展大致會(huì)走向“批流一體”。

02

批流一體

最近一兩年中和實(shí)時(shí)數(shù)倉(cāng)一樣火的概念是“批流一體”，那么到底什么是“批流一體”？在業(yè)界中很多人認(rèn)為批和流在開發(fā)層面上都統(tǒng)一到相同的SQL上處理是批流一體，也有一些人認(rèn)為在計(jì)算引擎層面上批和流可以集成在同一個(gè)計(jì)算引擎是批流一體，比如：Spark/SparkStreaming/Structured Streaming/Flink框架在計(jì)算引擎層面上實(shí)現(xiàn)了批處理和流處理集成。

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

這條架構(gòu)中無(wú)論是流處理還是批處理，數(shù)據(jù)存儲(chǔ)都統(tǒng)一到數(shù)據(jù)湖Iceberg上，這一套結(jié)構(gòu)將存儲(chǔ)統(tǒng)一后，解決了Kappa架構(gòu)很多痛點(diǎn)，解決方面如下：

可以解決Kafka存儲(chǔ)數(shù)據(jù)量少的問題。

目前所有數(shù)據(jù)湖基本思路都是基于HDFS之上實(shí)現(xiàn)的一個(gè)文件管理系統(tǒng)，所以數(shù)據(jù)體量可以很大。

DW層數(shù)據(jù)依然可以支持OLAP查詢。

同樣數(shù)據(jù)湖基于HDFS之上實(shí)現(xiàn)，只需要當(dāng)前的OLAP查詢引擎做一些適配就可以進(jìn)行OLAP查詢。

批流存儲(chǔ)都基于Iceberg/HDFS存儲(chǔ)之后，就完全可以復(fù)用一套相同的數(shù)據(jù)血緣、數(shù)據(jù)質(zhì)量管理體系。

實(shí)時(shí)數(shù)據(jù)的更新。

上述架構(gòu)也可以認(rèn)為是Kappa架構(gòu)的變種，也有兩條數(shù)據(jù)鏈路，一條是基于Spark的離線數(shù)據(jù)鏈路，一條是基于Flink的實(shí)時(shí)數(shù)據(jù)鏈路，通常數(shù)據(jù)都是直接走實(shí)時(shí)鏈路處理，而離線鏈路則更多的應(yīng)用于數(shù)據(jù)修正等非常規(guī)場(chǎng)景。這樣的架構(gòu)要成為一個(gè)可以落地的實(shí)時(shí)數(shù)倉(cāng)方案、可以做到實(shí)時(shí)報(bào)表產(chǎn)生，這得益于Iceberg技術(shù)：

支持流式寫入-增量拉取

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

這個(gè)問題才是離線數(shù)倉(cāng)做不到實(shí)時(shí)的最關(guān)鍵原因之一，離線數(shù)倉(cāng)的玩法是說上游將數(shù)據(jù)全部導(dǎo)入完成了，告訴下游說這波數(shù)據(jù)全部導(dǎo)完了，你可以消費(fèi)處理了，這樣的話就做不到實(shí)時(shí)處理。

數(shù)據(jù)湖就解決了這個(gè)問題。實(shí)時(shí)數(shù)據(jù)鏈路處理的時(shí)候上游Flink寫入的文件進(jìn)來之后，下游就可以將數(shù)據(jù)文件一致性地讀走。這里強(qiáng)調(diào)一致性地讀，就是不能多讀一個(gè)文件也不能少讀一個(gè)文件。上游這段時(shí)間寫了多少文件，下游就要讀走多少文件。我們稱這樣的讀取叫增量拉取。

解決小文件多的問題

數(shù)據(jù)湖實(shí)現(xiàn)了相關(guān)合并小文件的接口，Spark/Flink上層引擎可以周期性地調(diào)用接口進(jìn)行小文件合并。

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

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

支持比較完整的OLAP生態(tài)

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

目前Iceberg部分功能還在開發(fā)中，有一些功能還不完善，但是整體實(shí)時(shí)數(shù)倉(cāng)的發(fā)展會(huì)大致朝著這個(gè)方向行進(jìn)。目前業(yè)界大多數(shù)公司還是處于Lambda架構(gòu)，使用Kappa架構(gòu)的公司一般都是實(shí)時(shí)業(yè)務(wù)居多的公司，隨著數(shù)據(jù)湖技術(shù)的發(fā)展，這些公司實(shí)時(shí)數(shù)倉(cāng)的構(gòu)建慢慢會(huì)走向最終的“批流一體”。

審核編輯 ：李倩