透過數(shù)字化轉型再談數(shù)據(jù)中臺（三）：一文遍歷大數(shù)據(jù)架構變遷史

透過數(shù)字化轉型再談數(shù)據(jù)中臺（三）：一文遍歷大數(shù)據(jù)架構變遷史/>

在前面兩篇“關于數(shù)字化轉型的幾個見解”、“唯一性定理中的數(shù)據(jù)中臺”提

到了數(shù)據(jù)中臺發(fā)展問題。比如概念發(fā)展太快，信息量過載，以及存在廣義、狹

義的數(shù)據(jù)中臺定義的差別等，涉及到的這些知識都離不開數(shù)據(jù)架構的范疇，所

以這一篇我會通過大數(shù)據(jù)架構發(fā)展的視角來總結與分享。（一些知識繼承自己

在2015年寫的《從數(shù)據(jù)倉庫到大數(shù)據(jù)，數(shù)據(jù)平臺這25年是怎樣進化的？》，

又名我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史系列），主要涉及三個方面：

?從數(shù)倉架構到大數(shù)據(jù)架構總共三個時代九種架構的演進

?自己整理的大數(shù)據(jù)技術棧

?最新一代的DataMesh架構的數(shù)據(jù)平臺

一、數(shù)據(jù)平臺的發(fā)展在悄然發(fā)生變化

從現(xiàn)在的企業(yè)發(fā)展來看，大家的訴求重點已經(jīng)從經(jīng)營與分析轉為數(shù)據(jù)化的精細

運營。在如何做好精細化運營過程中，企業(yè)也面臨著來自創(chuàng)新、發(fā)展、內卷等

的各方面壓力。隨著業(yè)務量、數(shù)據(jù)量增長，大家對數(shù)據(jù)粒度需求從之前的高匯

總逐漸轉為過程化的細粒度明細數(shù)據(jù)，以及從T+1的數(shù)據(jù)轉為近乎實時的數(shù)據(jù)

訴求。

大量的數(shù)據(jù)需求、海量的臨時需求，讓分析師、數(shù)據(jù)開發(fā)疲憊不堪。這些職位

也變成了企業(yè)資源的瓶頸，傳統(tǒng)BI中的Report>OLAP等工具也都無法滿足互

聯(lián)網(wǎng)行業(yè)個性化的數(shù)據(jù)需求。大家開始考慮如何把需求固定為一個面向最終用

戶自助式、半自助的產品，來快速獲取數(shù)據(jù)并分析得到結果，數(shù)據(jù)通過各類數(shù)

據(jù)產品對外更有針對性的數(shù)據(jù)價值傳遞。

（關于數(shù)據(jù)產品一個題外補充：當總結出的指標、分析方法（模型）、使用流

程與工具有機的結合在一起時數(shù)據(jù)產品就此產生，隨著數(shù)據(jù)中臺&數(shù)據(jù)平臺的建

設逐漸的進入快速迭代期，數(shù)據(jù)產品、數(shù)據(jù)產品經(jīng)理這兩個詞逐漸的升溫并逐

漸到今天各大公司對數(shù)產品經(jīng)理崗位的旺盛訴求，目前這兩方面的方法論也逐

步的體系化、具象化）。

在這十幾年中，影響數(shù)據(jù)倉庫、數(shù)據(jù)平臺、數(shù)據(jù)中臺、數(shù)據(jù)湖的演進變革的因

素也很多，比如不斷快速迭代的業(yè)務模式與膨脹的群體規(guī)模所帶來的數(shù)據(jù)量的

沖擊，新的大數(shù)據(jù)處理技術的驅動。還有落地在數(shù)據(jù)中臺上各種數(shù)據(jù)產品的建

設，比如工具化數(shù)據(jù)產品體系、各種自助式的數(shù)據(jù)產品、平臺化各數(shù)據(jù)產品的

建設。這些數(shù)據(jù)建設能力的泛化，也讓更多的大眾參與數(shù)據(jù)中臺的建設中，比

如一些懂SQL的用戶以及分析師參與數(shù)據(jù)平臺直接建設比重增加。還有一些原

本數(shù)據(jù)中臺具備的能力也有一些逐步地被前置到業(yè)務系統(tǒng)進行處理。

二、一張圖看清楚大數(shù)據(jù)架構發(fā)展

數(shù)據(jù)倉庫在國外發(fā)展多年，于大約在1998-1999年傳入中國。進入中國以后，

發(fā)展出了很多專有名詞，比如數(shù)據(jù)倉庫、數(shù)據(jù)中心、數(shù)據(jù)平臺、數(shù)據(jù)中臺、數(shù)

據(jù)湖等，從大數(shù)據(jù)架構角度來看可用三個時代九種架構來做總結，其中前四代

是傳統(tǒng)數(shù)據(jù)倉庫時代的架構，后面五代是大數(shù)據(jù)架構模式。

其中有兩個承前啟后的地方：

?一個特殊地方是，傳統(tǒng)行業(yè)第三代架構與大數(shù)據(jù)第一代架構在架構形式

上基本相似。傳統(tǒng)行業(yè)的第三代架構可以算是用大數(shù)據(jù)處理技術重新實

現(xiàn)了一遍。

?傳統(tǒng)行業(yè)第四代的架構中實時部分在現(xiàn)代用大數(shù)據(jù)實時方式做了新的落

地。

如下圖所示：

由向私提紫梅

取能倉庫第一代紫狗

傳

n統(tǒng)敬提倉庫第二代架構

混權掘倉庫第三代紫科

錄

構

料堤倉庫第四代架科

大大權提

?

據(jù)

罌

構

?。辦->DU/->ST->應用

?Ods->DU/D->DU/->DM->應用

?04x->PU/D->DU/B->DV>/$

?O4;->Dl7D->DU/->5T(ADM)?應用

三個時代：非互聯(lián)網(wǎng)、互聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)時代，每一種時代的業(yè)務特點、數(shù)

據(jù)量、數(shù)據(jù)類型各不相同，自然數(shù)據(jù)架構也是有顯著差異的。

行業(yè)域非互聯(lián)網(wǎng)互聯(lián)網(wǎng)

數(shù)據(jù)來源（相對結構化各類數(shù)據(jù)庫（DBWeb、

于數(shù)據(jù)平臺來系統(tǒng)）、結構化文本、日志，

講）Excel表格等，少量據(jù)、長

word要是來

數(shù)據(jù)包含信息CRM客戶信息、事務除了傳

性ERP/MRPII數(shù)據(jù)、夕卜，還

資金賬務數(shù)據(jù)等。擊日志

媒體、

數(shù)據(jù)結構特性幾乎都是結構化數(shù)據(jù)非結構

數(shù)據(jù)存儲/數(shù)主要以DB結構化存儲文件形

據(jù)量為主，從幾百兆到百月工式

G級另U

產生周期慢，幾天甚至周為單秒或更

位

對消費者行為粒度粗粒度較

采集與還原

數(shù)據(jù)價值長期有效隨著時

表格源自：《我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史》

三、從數(shù)據(jù)到大數(shù)據(jù)的數(shù)據(jù)架構總結

我自己對傳統(tǒng)數(shù)據(jù)倉庫的發(fā)展，簡單抽象為為五個時代、四種架構（或許也不

是那么嚴謹）。

五個時代大概，按照兩位數(shù)據(jù)倉庫大師RalphkilmbalkBillInnmon在數(shù)據(jù)

倉庫建設理念上碰撞階段來作為小的分界線：

?大概在1991年之前，數(shù)據(jù)倉庫的實施基本采用全企業(yè)集成的模式。

?大概在1992年企業(yè)在數(shù)據(jù)倉庫實施基本采用EDW的方式，Bill

Innmon博士出版了《如何構建數(shù)據(jù)倉庫》，里面清晰的闡述了EDW架構

與實施方式。

?1994-1996年是數(shù)據(jù)集市時代，這個時代另外一種維度建模、數(shù)據(jù)集市

的方式較為盛行起來，其主要代表之一RalphKimball博士出版了他的

第一本書"TheDataWarehouseToolkit”（《數(shù)據(jù)倉庫工具箱》），里

面非常清晰的定義了數(shù)據(jù)集市、維度建模。

?大概在1996-1997年左右的兩個架構競爭時代。

?1998-2001年左右的合并年代。

在主要歷史事件中提到了兩位經(jīng)典代表人物：BillInnmon、Ralphkilmballo

這兩位在數(shù)據(jù)界可以算是元祖級別的人物?，F(xiàn)在數(shù)據(jù)中臺/平臺的很多設計理念

依然受到他倆90年代所提出方法論為依據(jù)。

經(jīng)典的BillInmon和Ralphkilmball爭論

BillInmon提出的遵循的是自上而下的建設原則，Ralphkilmball提出自下

而上的建設原則，兩種方法擁護者會在不同場合爭論哪一種方法論更有優(yōu)勢。

兩位大師對于建設方法爭論要點：

其中BillInmon的方法論：認為僅僅有數(shù)據(jù)集市是不夠的，提倡先必須得從

企業(yè)級的數(shù)據(jù)模型角度入手來構建。企業(yè)級模型就有較為完善的業(yè)務主題域劃

分、邏輯模型劃分，在解決某個業(yè)務單元問題時可以很容易的選擇不同數(shù)據(jù)路

徑來組成數(shù)據(jù)集市。

后來數(shù)據(jù)倉庫在千禧年傳到中國后，幾個大實施廠商都是遵守該原則的實施方

法，也逐漸的演進成了現(xiàn)在大家熟悉的數(shù)據(jù)架構中關于數(shù)據(jù)層次的劃分：

?0ds->DW->ST->應用

?Ods->DWD->DW->DM->應用

?Ods->DWD->DWB->DWS->應用

?Ods->DWD->DW->ST（ADM）->應用

上個10年的國內實施數(shù)據(jù)倉庫以及數(shù)據(jù)平臺企業(yè)，有幾家專業(yè)的廠商：IBM、

Teradata、埃森哲、菲奈特(被東南收購)、亞信等。這些廠商針對自己領域服

務的客戶，從方案特點等一系列角度出發(fā)，在實施中對ODS層、EDW、DM等不

同數(shù)據(jù)層逐步地賦予了各種不同的功能與含義。

現(xiàn)在大家熟知的數(shù)據(jù)模型層次劃分，基本上也是傳承原有的BillInmon的方法

論。

數(shù)據(jù)集市年代的代表人物為Ralphkilmball,他的代表作是《TheData

WarehouseToolkit》。這本書就是大名鼎鼎的《數(shù)據(jù)倉庫工具箱》。企業(yè)級

數(shù)據(jù)的建設方法主張自下而上建立數(shù)據(jù)倉庫，極力推崇創(chuàng)建數(shù)據(jù)集市，認為數(shù)

據(jù)倉庫是數(shù)據(jù)集市的集合，信息總是被存儲在多維模型中。

這種思想從業(yè)務或部門入手，設計面向業(yè)務或部門主題數(shù)據(jù)集市。隨著更多的

不同業(yè)務或部門數(shù)據(jù)集市實施落地，此時企業(yè)可以根據(jù)需要來合并不同的數(shù)據(jù)

集市，并逐步形成企業(yè)級的數(shù)據(jù)倉庫，這種方式被稱為自下而上(Botton-up)方

法。這個方法在當時剛好與BillInnmon的自上而下建設方法相反。

類比BillInmon提出的方法論

建設周期需要花費大量時間

維護難易度容易維護

建設成本前期投入大，后期建設成本低

建設周期周期長，見效慢

需要的團隊類型專業(yè)團隊搭建

數(shù)據(jù)集成需求全企業(yè)生命周期數(shù)據(jù)集成

面向用戶群體潛在的全企業(yè)用戶

專業(yè)術語面向主題、隨時間而變化、保殍

歷史、數(shù)據(jù)集成

數(shù)據(jù)模型準三范式設計原則

隨著數(shù)據(jù)倉庫的不斷實踐與迭代發(fā)展，從爭吵期進入到了合并的時代，其實爭

吵的結果要么一方妥協(xié)，要么新的結論出現(xiàn)。Billinmon與Ralphkilmball

的爭吵沒有結論，干脆提出一種新的架構包含對方，也就是后來BillInmon

提出的CIF(corporationinformationfactory)信息工廠的架構模式，這個

架構模式將Ralphkilmball的數(shù)據(jù)集市包含了進來，有關兩種數(shù)據(jù)倉庫實施

方法論的爭吵才逐步地平息下來。

3.1非互聯(lián)網(wǎng)四代架構

3.1.1第一代edw架構

第一代“DW

Dafa

ETL

U/areHou

現(xiàn)在數(shù)據(jù)建設中使用到的“商業(yè)智能”、“信息倉庫”等很多專業(yè)術語、方法

論，基本上是在上世紀60年代至90年代出現(xiàn)的。比如“維度模型”這個詞是

個世紀60年代GM與DarmouthCollege大學第一次提出，

“DatawareHouse”、“事實”是在上個世紀70年代BillInmon明確定義出

來的，后來90年代BillInmon出版《如何構建數(shù)據(jù)倉庫》一書更加體系化

的與明確定義了如何構建數(shù)據(jù)倉庫，這套方法在落地上形成了第一代數(shù)據(jù)倉庫

架構。

在第一代的數(shù)據(jù)倉庫中，清晰地定義了數(shù)據(jù)倉庫(DataWarehouse)是一個面向

主題的(SubjectOriented)、集成的(Integrate)、相對穩(wěn)定的(Non-

Volatile)、反映歷史變化(TimeVariant)的數(shù)據(jù)集合，用于支持管理決策

(DecisionMarkingSupport)。

首先，數(shù)據(jù)倉庫(DataWarehouse)是用來支持決策的、面向主題的用來支撐分

析型數(shù)據(jù)處理的，這里有別于企業(yè)使用的數(shù)據(jù)庫。

數(shù)據(jù)庫、數(shù)據(jù)倉庫小的區(qū)別:

數(shù)據(jù)庫系統(tǒng)的設計目標是事務處理。數(shù)據(jù)庫系統(tǒng)是為記錄更新和事務處理而設

計，數(shù)據(jù)的訪問的特點是基于主鍵，大量原子，隔離的小事務，并發(fā)和可恢復

是關鍵屬性，最大事務吞吐量是關鍵指標，因此數(shù)據(jù)庫的設計都反映了這些需

求。

數(shù)據(jù)倉庫的設計目標是決策支持。歷史的、摘要的、聚合的數(shù)據(jù)比原始的記錄

重要的多。查詢負載主要集中在即席查詢和包含連接，聚合等復雜查詢操作

上。

其次，數(shù)據(jù)倉庫(DataWarehouse)是對多種異構數(shù)據(jù)源進行有效集成與處理，

是按照主題的方式對數(shù)據(jù)進行重新整合，且包一般不怎么修改的歷史數(shù)據(jù)，一

句話總結面向主題、集成性、穩(wěn)定性和時變性。

數(shù)據(jù)倉庫(DataWarehouse)從特點上來看：

?數(shù)據(jù)倉庫是面向主題的。

?數(shù)據(jù)倉庫是集成的，數(shù)據(jù)倉庫的數(shù)據(jù)有來自于分散的操作型數(shù)據(jù)，將所

需數(shù)據(jù)從原來的數(shù)據(jù)中抽取出來，進行加工與集成，統(tǒng)一與綜合之后才

能進入數(shù)據(jù)倉庫。

?數(shù)據(jù)倉庫是不可更新的，數(shù)據(jù)倉庫主要是為決策分析提供數(shù)據(jù)，所涉及

的操作主要是數(shù)據(jù)的查詢。

?數(shù)據(jù)倉庫是隨時間而變化的，傳統(tǒng)的關系數(shù)據(jù)庫系統(tǒng)比較適合處理格式

化的數(shù)據(jù)，能夠較好的滿足商業(yè)商務處理的需求，它在商業(yè)領域取得了

巨大的成功。

數(shù)據(jù)倉庫和數(shù)據(jù)庫系統(tǒng)的區(qū)別，一言蔽之：OLAP和OLTP的區(qū)別。數(shù)據(jù)庫支持

是OLTP,數(shù)據(jù)倉庫支持的是OLAP。

3.1.2第二代大集市架構

第二代大集市架構

Z-------------\

訂單條統(tǒng)X

Dafa-a9m9

forPlhADafa

U/HR

PIA/bus

ARJ

第二代就是Ralphkilmball的大集市的架構。第二代架構基本可以成為總線

型架構，從業(yè)務或部門入手，設計面向業(yè)務或部門主題數(shù)據(jù)集市。Kilmball的

這種構建方式可以不用考慮其它正在進行的數(shù)據(jù)類項目實施，只要快速滿足當

前部門的需求即可，這種實施的好處是阻力較小且路徑很短。

但是考慮到在實施中可能會存在多個并行的項目，是需要在數(shù)據(jù)標準化、模型

階段是需要進行維度歸一化處理，需要有一套標準來定義公共維度，讓不同的

數(shù)據(jù)集市項目都遵守相同的標準，在后面的多個數(shù)據(jù)集市做合并時可以平滑處

理。比如業(yè)務中相似的名詞、不同系統(tǒng)的枚舉值、相似的業(yè)務規(guī)則都需要做統(tǒng)

一命名，這里在現(xiàn)在的中臺就是全域統(tǒng)一ID之類的東西。

主要核心：

?一致的維度，以進行集成和全面支持。一致的維度具有一致的描述性屬

性名稱、值和含義。

?一致的事實是一致定義的；如果不是一致的業(yè)務規(guī)則，那么將為其指定

一個獨特的名稱。業(yè)務中相似的名詞、不同系統(tǒng)的枚舉值、相似的業(yè)務

規(guī)則都需要做統(tǒng)一命名。

?建模方式：星型模型、雪花模型。

3.1.3第三代匯總維度集市&CIF2.0數(shù)倉結構

第三代匯總維度集市的標準數(shù)廢倉庫結構

第三代C&2.0架構(,日一化的敬粕倉庫和堆數(shù)泥層倉庫的混合)

CIF(corporationinformationfactor)信息工廠(作者備注，關于Cif的

英文版文章名字CorporateInformationFactory(CIF)Overview),Bill

Inmon認為企業(yè)的發(fā)展會隨著信息資源重要性會逐步的提升，會出現(xiàn)一種信息

處理架構，類似工廠一樣能滿足所有信息的需求與請求。這個信息工廠的功能

包含了數(shù)據(jù)存儲與處理(活躍數(shù)據(jù)、沉默數(shù)據(jù))，支持跨部門甚至跨企業(yè)的數(shù)

據(jù)訪問與整合，同時也要保證數(shù)據(jù)安全性等。

剛好CIF架構模式也逐步的變成了數(shù)據(jù)倉庫第三代架構。為什么把這個CIF

架構定義成一個經(jīng)典架構呢，因為CIF的這種架構總結了前面提到的兩種架構

的同時，又把架構的不同層次定義得非常明確。

例如CIF2.0主要包括集成轉換層(IntegratedandTransformation

Layer)、操作數(shù)據(jù)存儲(OperationalDataStore)、數(shù)據(jù)倉庫(Enterprise

DataWarehouse)、數(shù)據(jù)集市(DataMart)、探索倉庫(Exploration

Warehouse)等部件。DataMart分為后臺(BackRoom)和前臺(Front

Room)兩部分。后臺主要負責數(shù)據(jù)準備工作，稱為數(shù)據(jù)準備區(qū)(Staging

Area),前臺主要負責數(shù)據(jù)展示工作，稱為數(shù)據(jù)集市(DataMart)o

這個經(jīng)典的架構在后來2006年~2012年進入到這個領域的從業(yè)者，乃至現(xiàn)在

有些互聯(lián)網(wǎng)企業(yè)的數(shù)據(jù)平臺架構也是相似的。

3.1.4第四代OPDM操作實時數(shù)倉

第四代OPDM掾作實時數(shù)倉

Dafa

U/qreH。皿

OPDM大約是在2011年提出來的，嚴格上來說，Opdm操作型數(shù)據(jù)集市（倉

庫）是實時數(shù)據(jù)倉庫的一種，他更多的是面向操作型數(shù)據(jù)而非歷史數(shù)據(jù)查詢與

分析。

在這里很多人會問到什么是操作型數(shù)據(jù)？比如財務系統(tǒng)、CRM系統(tǒng)、營銷系統(tǒng)

生產系統(tǒng)，通過某一種機制實時的把這些數(shù)據(jù)從各數(shù)據(jù)孤島按照業(yè)務的某個層

次有機的自動化整合在一起，提供業(yè)務監(jiān)控與指導。

3.2互聯(lián)網(wǎng)的五代大數(shù)據(jù)處理架構

在文章的開頭有提過，傳統(tǒng)行業(yè)第三代架構與大數(shù)據(jù)第一代架構在架構形式上

基本相似，只不過是通過大數(shù)據(jù)的處理技術嘗試對傳統(tǒng)第三架構進行落地的。

比如說在Hadoop&Hive剛興起的階段，有用SyaselQ、Greenplum等技術來作

為大數(shù)據(jù)處理技術，后來Hadoop&hive以及FacebookScribe>Linkedin

kafka等逐步開源后又產生了新的適應互聯(lián)網(wǎng)大數(shù)據(jù)的架構模式。

后續(xù)阿里巴巴淘系的TImeTunnel等更多的近百種大數(shù)據(jù)處理的開源技術，進一

步促進了整個大數(shù)據(jù)處理架構與技術框架的發(fā)展，我在后面會給出一個比較完

善截止到目前所有技術的數(shù)據(jù)處理框架。

按照大數(shù)據(jù)的使用場景、數(shù)據(jù)量、數(shù)據(jù)的類型，在架構上也基本上分為流式處

理技術框架、批處理技術框架等，所以互聯(lián)網(wǎng)這五代的大數(shù)據(jù)處理框架基本上

是圍繞著批處理、流式處理以及混合型架構這三種來做演進。

3.2.1第一代離線大數(shù)據(jù)統(tǒng)計分析技術架構

離線統(tǒng)計分析技術架構

(OPS)(

取掘同步

服治型*

Kafka

泉據(jù)廿算

Dafax

其它

泉爆后儺

業(yè)務生產城5■，城

大料龐處理與心儲Hi

內好辦公1統(tǒng)

數(shù)據(jù)詆收據(jù)同步euT/erc孰倉

這個結構與第三代的數(shù)據(jù)處理架構非常相似，具體如下圖所示:

數(shù)據(jù)階段傳統(tǒng)行業(yè)第三代架構

數(shù)據(jù)源結構化數(shù)據(jù)為主（數(shù)據(jù)庫數(shù)據(jù)、內

辦公數(shù)據(jù)、財務數(shù)據(jù)等）、非結構化數(shù)

很少或者是沒有

數(shù)據(jù)處理名詞：ETL為主，在數(shù)據(jù)如中央倉庫乂

前已經(jīng)開始很多的數(shù)據(jù)轉換、歸一化白

處理

技術：Datastage、informa、Dts、C

腳本等等

數(shù)據(jù)中央技術：Oracle.DB2、SybaselQ.

處理Teradata

數(shù)據(jù)模型：維度模型、準三范式

數(shù)據(jù)應用成型的解決方案產品：Report.

OLAP,在線分析等

這代架構定位是為了解決傳統(tǒng)BI的問題，簡單來說，數(shù)據(jù)分析的業(yè)務沒有發(fā)生

任何變化，但是因為數(shù)據(jù)量、性能等問題導致系統(tǒng)無法正常使用，需要進行升

級改造，此類架構便是為了解決這個問題。

3.2.2第二代流式架構

Sfro?M/jshrot^

其它

S/TO?M

命k

敬據(jù)強敬掘傳輸簡單汁洗

流式的應用場景非常廣泛，比如搜索、推薦、信息流等都是在線化的，對數(shù)據(jù)

實時性的要求變更高，自然計算與使用是同步進行的。

隨著業(yè)務的復雜化，數(shù)據(jù)的處理邏輯更加復雜，比如各種維度交叉、關聯(lián)、聚

類，以及需要更多算法或機器學習。這些應用場景可以完全地分為兩類：事件

流、持續(xù)計算。

?事件流，就是業(yè)務相對固定，只是數(shù)據(jù)在業(yè)務的規(guī)則下不斷的變化。

?持續(xù)計算，適合購物網(wǎng)站等場景。

流式計算處理框架與第一代的大數(shù)據(jù)處理框架相比，去掉了原有的ETL過程，

數(shù)據(jù)流過數(shù)據(jù)通道時得到處理，處理結果通過消息的方式推送數(shù)據(jù)消費者。

流式計算框架舍棄了大數(shù)據(jù)離線批量處理模式，只有很少的數(shù)據(jù)存儲，所以數(shù)

據(jù)保存周期非常短。如果有歷史數(shù)據(jù)場景或很復雜歷史數(shù)據(jù)參與計算的場景，

實現(xiàn)起來難度就比較大。

現(xiàn)在一些場景，會把流式計算的結果數(shù)據(jù)周期性地存到批處理的數(shù)據(jù)存儲區(qū)

域。如果有場景需要使用歷史數(shù)據(jù)，流式計算框架會把保存的歷史結果用更新

的方式進行加載，再做進一步處理。

3.2.3第三代Lambda大數(shù)據(jù)架構

SfroKt/js+roh*/fiink/

意據(jù)唐儂““)

肅式處理

J

取據(jù)兼取庭傳輸汁洗/處理/存儲

Lambda架構是由Twitter工程師南森?馬茨(NathanMarz)提出的，是一種

經(jīng)典的、實施廣泛的技術架構。后來出現(xiàn)的其他大數(shù)據(jù)處理架構也是Lambda

架構的優(yōu)化或升級版。

Lambda架構有兩條數(shù)據(jù)鏈路，一條兼顧處理批量、離線數(shù)據(jù)結構，一條是實時

流式處理技術。

?批量離線處理流在構建時大部分還是采用一些經(jīng)典的大數(shù)據(jù)統(tǒng)計分析方

法論，在保證數(shù)據(jù)一致性、完整性的同時還會對數(shù)據(jù)按照不同應用場景

進行分層。

?實時流式處理主要是增量計算，也會跑一些機器學習模型等。為了保證

數(shù)據(jù)的一致性，實時流處理結果與批量處理結果會有一個合并動作。

Lambda架構主要的組成是批處理、流式處理、數(shù)據(jù)服務層這三部分。

?批處理層(Bathchlayer)：Lambda架構核心層之一，批處理接收過來

的數(shù)據(jù)，并保存到相應的數(shù)據(jù)模型中，這一層的數(shù)據(jù)主題、模型設計的

方法論是繼承面向統(tǒng)計分析離線大數(shù)據(jù)中的。而且一般都會按照比較經(jīng)

典的ODS、DWD、DWB、ST/ADM的層次結構來劃分。

?流式處理層(SpeedLayer)：Lambda另一?個核心層，為了解決比如各

場景下數(shù)據(jù)需要一邊計算一邊應用以及各種維度交叉、關聯(lián)的事件流與

持續(xù)計算的問題，計算結果在最后與批處理層的結果做合并。

?服務層(Servinglayer)：這是Lambda架構的最后一層，服務層的職

責是獲取批處理和流處理的結果，向用戶提供統(tǒng)一查詢視圖服務。

Lamabda架構理念從出現(xiàn)到發(fā)展這么多年，優(yōu)缺點非常明顯。比如穩(wěn)定與性能

上的優(yōu)勢，ETL處理計算利用晚上時間來做，能復用部分實時計算的資源。劣

勢，兩套數(shù)據(jù)流因為結果要做合并，所有的算法要實現(xiàn)兩次，一次是批處理、

一次是實時計算，最終兩個結果還得做合并顯得會很復雜。

3.2.4Kappa大數(shù)據(jù)架構

第總隊列

散貸誦教強傳輸緯洗/處理/它儲

在Lamadba架構下需要維護兩套的代碼，為了解決這個問題，Linkedln公司的

JayKreps結合實際經(jīng)驗與個人思考提出了Kappa架構。

Kappa架構核心是通過改進流式計算架構的計算、存儲部分來解決全量的問

題，使得實時計算、批處理可以共用一套代碼。Kappa架構認為對于歷史數(shù)據(jù)

的重復計算幾率是很小的，即使需要，可以通過啟用不同的實例的方式來做重

復計算。

其中Kappa的核心思想是：

?用Kafka或者類似MQ隊列系統(tǒng)收集各種各樣的數(shù)據(jù)，需要幾天的數(shù)據(jù)量

就保存幾天。

?當需要全量重新計算時，重新起一個流計算實例，從頭開始讀取數(shù)據(jù)進

行處理，并輸出到一個新的結果存儲中。

?當新的實例做完后，停止老的流計算實例，并把一些老的結果刪除。

Kappa架構的優(yōu)點在于將實時和離線代碼統(tǒng)一起來，方便維護而且統(tǒng)一了數(shù)據(jù)

口徑。

Kappa架構與Lamabda架構相比，其優(yōu)缺點是：

?Lambda架構需要維護兩套跑在批處理和實時流上的代碼，兩個結果還需

要做merge,Kappa架構下只維護一套代碼，在需要時候才跑全量數(shù)

據(jù)。

?Kappa架構下可以同時啟動很多實例來做重復計算，有利于算法模型調

整優(yōu)化與結果對比，Lamabda架構下，代碼調整比較復雜。所以kappa

架構下，技術人員只需要維護一個框架就可以，成本很小。

?kappa每次接入新的數(shù)據(jù)類型格式是需要定制開發(fā)接入程序，接入周期

會變長。

?Kappa這種架構過度依賴于Redis、Hbase服務，兩種存儲結構又不是滿

足全量數(shù)據(jù)存儲的，用來做全量存儲會顯得浪費資源。

3.2.5Unified大數(shù)據(jù)架構

明號叢則

AWST

服務?5坊大叔施處理與口幡MapR.duc”Spark

技處理

數(shù)據(jù)

算法與疙碌操型

/jstrohx/Spark/f&k/其

敬隹庠Canal

流式處理

數(shù)掘傳輸汁洗/處理/傳儲

以上的這些架構都圍繞大數(shù)據(jù)處理為主，Unifield架構則更激進，將機器學習

和數(shù)據(jù)處理整合為一體，從核心上來說，Unifield在Lambda基礎上進行升

級，在流處理層新增了機器學習層。數(shù)據(jù)經(jīng)過數(shù)據(jù)通道進入數(shù)據(jù)湖，新增了模

型訓練部分，并且將其在流式層進行使用。同時流式層不單使用模型，也包含

著對模型的持續(xù)訓練。

3.2.6IOTA架構

IOTA大數(shù)據(jù)架構是一種基于AI生態(tài)下的、全新的數(shù)據(jù)架構模式，這個概念由

易觀于2018年首次提出。IOTA的整體思路是設定標準數(shù)據(jù)模型，通過邊緣計

算技術把所有的計算過程分散在數(shù)據(jù)產生、計算和查詢過程當中，以統(tǒng)一的數(shù)

據(jù)模型貫穿始終，從而提高整體的計算效率，同時滿足計算的需要，可以使用

各種Ad-hocQuery來查詢底層數(shù)據(jù)。

主要有幾個特點：

?去ETL化：ETL和相關開發(fā)一直是大數(shù)據(jù)處理的痛點，IOTA架構通過

CommonDataModel的設計，專注在某一個具體領域的數(shù)據(jù)計算，從而

可以從SDK端開始計算，中央端只做采集、建立索引和查詢，提高整體

數(shù)據(jù)分析的效率。

?Ad-hoc即時查詢：鑒于整體的計算流程機制，在手機端、智能I0T事件

發(fā)生之時，就可以直接傳送到云端進入realtimedata區(qū)，可以被前端

的QueryEngine來查詢。此時用戶可以使用各種各樣的查詢，直接查到

前幾秒發(fā)生的事件，而不用在等待ETL或者Streaming的數(shù)據(jù)研發(fā)和處

理。

?邊緣計算(Edge-Computing)：將過去統(tǒng)一到中央進行整體計算，分散

到數(shù)據(jù)產生、存儲和查詢端，數(shù)據(jù)產生既符合CommonDataModel。同

時，也給與Realtimemodelfeedback,讓客戶端傳送數(shù)據(jù)的同時馬上

進行反饋，而不需要所有事件都要到中央端處理之后再進行下發(fā)。

可能是由于我接觸到的范圍有限，暫時還沒有遇到一家企業(yè)完整按照IOTA這個

架構模式來實施的，暫時沒有更多的個人經(jīng)驗來分享這塊。

3.2.7小結

大數(shù)據(jù)架構的每一代的定義與出現(xiàn)是有必然性的，當然沒有一個嚴格上的時間

區(qū)分點。直接給出一個每種架構比較：

架構優(yōu)點缺點

離線大簡單，易懂，對于BI系對于大數(shù)據(jù)來

數(shù)據(jù)統(tǒng)統(tǒng)來說，基本思想沒有完備的Cube當

計分析發(fā)生變化，變化的僅僅kylin,但是ky

技術架是技術選型，用大數(shù)據(jù)顯，遠遠沒有

構架構替換掉BI的組件?；疃群头€(wěn)定度

的靈活度不夠

量報表，或者

景，需要太多

時該架構依舊

乏實時的支撐

流式架沒有臃腫的ETL過程，對于流式架構

構數(shù)據(jù)的實效性非常高。理，因此對于

統(tǒng)計無法很好

分析僅僅支撐

Lambd既有實時又有離線，對離線層和實時

a架構于數(shù)據(jù)分析場景涵蓋的不相同，但是

非常到位。卻是相同，因

復的模塊存在

KappaKappa架構解決了雖然Kappa架

架構Lambda架構里面的冗是實施難度相

余部分，以數(shù)據(jù)可重播于數(shù)據(jù)重播部

的超凡脫俗的思想講行

架構講完了，落地肯定是離不開技術的，我之前花了不少時間整理了一下目前

大數(shù)據(jù)方向的技術棧的內容。

四、大數(shù)據(jù)處理技術棧

分享完了架構，在從大數(shù)據(jù)技術棧的角度來看看對應的數(shù)據(jù)采集、數(shù)據(jù)傳輸、

數(shù)據(jù)存儲、計算、ide管理、分析可視化微服務都有哪些技術，下圖的技術棧

我花了蠻多的時間梳理的。

管理層/IDE層Dataphin)(其它？

數(shù)倉層Hivec

c

C

傳輸層

數(shù)據(jù)采集層

?按照數(shù)據(jù)采集-傳輸-落地到存儲層，再通過調度調起計算數(shù)據(jù)處理任務

把整合結果數(shù)據(jù)存到數(shù)據(jù)倉庫以及相關存儲區(qū)域中。

?通過管理層/ide進行數(shù)據(jù)管理或數(shù)據(jù)開發(fā)。

?通過OLAP、分析、算