01

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

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

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

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

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

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

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

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

01

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

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

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

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

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

02

Lambda架構(gòu)

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

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

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

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

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

離線數(shù)倉+實時數(shù)倉

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

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

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

03

Kappa架構(gòu)

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

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

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

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

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

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

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

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

04

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

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

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

02

離線數(shù)倉與實時數(shù)倉區(qū)別

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

03

實時數(shù)倉建設(shè)思路

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

04

實時數(shù)倉發(fā)展趨勢

01

實時數(shù)倉現(xiàn)狀

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

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

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

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

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

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

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

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

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

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

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

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

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

02

批流一體

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

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

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

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

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

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

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

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

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

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

支持流式寫入-增量拉取

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

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

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

解決小文件多的問題

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

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

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

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

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

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

審核編輯 ：李倩