透過數(shù)字化轉(zhuǎn)型再談數(shù)據(jù)中臺(tái)（三）：一文遍歷大數(shù)據(jù)架構(gòu)變遷史

透過數(shù)字化轉(zhuǎn)型再談數(shù)據(jù)中臺(tái)（三）：一文遍歷大數(shù)據(jù)架構(gòu)變遷史/>

在前面兩篇“關(guān)于數(shù)字化轉(zhuǎn)型的幾個(gè)見解”、“唯一性定理中的數(shù)據(jù)中臺(tái)”提

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

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

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

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

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

?從數(shù)倉架構(gòu)到大數(shù)據(jù)架構(gòu)總共三個(gè)時(shí)代九種架構(gòu)的演進(jìn)

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

?最新一代的DataMesh架構(gòu)的數(shù)據(jù)平臺(tái)

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

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

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

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

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

訴求。

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

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

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

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

據(jù)產(chǎn)品對(duì)外更有針對(duì)性的數(shù)據(jù)價(jià)值傳遞。

（關(guān)于數(shù)據(jù)產(chǎn)品一個(gè)題外補(bǔ)充：當(dāng)總結(jié)出的指標(biāo)、分析方法（模型）、使用流

程與工具有機(jī)的結(jié)合在一起時(shí)數(shù)據(jù)產(chǎn)品就此產(chǎn)生，隨著數(shù)據(jù)中臺(tái)&數(shù)據(jù)平臺(tái)的建

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

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

步的體系化、具象化）。

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

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

沖擊，新的大數(shù)據(jù)處理技術(shù)的驅(qū)動(dòng)。還有落地在數(shù)據(jù)中臺(tái)上各種數(shù)據(jù)產(chǎn)品的建

設(shè)，比如工具化數(shù)據(jù)產(chǎn)品體系、各種自助式的數(shù)據(jù)產(chǎn)品、平臺(tái)化各數(shù)據(jù)產(chǎn)品的

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

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

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

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

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

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

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

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

其中有兩個(gè)承前啟后的地方：

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

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

現(xiàn)了一遍。

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

地。

如下圖所示：

由向私提紫梅

取能倉庫第一代紫狗

傳

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

混權(quán)掘倉庫第三代紫科

錄

構(gòu)

料堤倉庫第四代架科

大大權(quán)提

?

據(jù)

罌

構(gòu)

?。辦->DU/->ST->應(yīng)用

?Ods->DU/D->DU/->DM->應(yīng)用

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

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

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

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

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

數(shù)據(jù)來源（相對(duì)結(jié)構(gòu)化各類數(shù)據(jù)庫（DBWeb、

于數(shù)據(jù)平臺(tái)來系統(tǒng)）、結(jié)構(gòu)化文本、日志，

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

word要是來

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

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

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

媒體、

數(shù)據(jù)結(jié)構(gòu)特性幾乎都是結(jié)構(gòu)化數(shù)據(jù)非結(jié)構(gòu)

數(shù)據(jù)存儲(chǔ)/數(shù)主要以DB結(jié)構(gòu)化存儲(chǔ)文件形

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

G級(jí)另U

產(chǎn)生周期慢，幾天甚至周為單秒或更

位

對(duì)消費(fèi)者行為粒度粗粒度較

采集與還原

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

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

三、從數(shù)據(jù)到大數(shù)據(jù)的數(shù)據(jù)架構(gòu)總結(jié)

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

是那么嚴(yán)謹(jǐn)）。

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

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

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

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

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

與實(shí)施方式。

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

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

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

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

?大概在1996-1997年左右的兩個(gè)架構(gòu)競(jìng)爭時(shí)代。

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

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

這兩位在數(shù)據(jù)界可以算是元祖級(jí)別的人物。現(xiàn)在數(shù)據(jù)中臺(tái)/平臺(tái)的很多設(shè)計(jì)理念

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

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

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

而上的建設(shè)原則，兩種方法擁護(hù)者會(huì)在不同場(chǎng)合爭論哪一種方法論更有優(yōu)勢(shì)。

兩位大師對(duì)于建設(shè)方法爭論要點(diǎn)：

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

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

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

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

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

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

?0ds->DW->ST->應(yīng)用

?Ods->DWD->DW->DM->應(yīng)用

?Ods->DWD->DWB->DWS->應(yīng)用

?Ods->DWD->DW->ST（ADM）->應(yīng)用

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

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

務(wù)的客戶，從方案特點(diǎn)等一系列角度出發(fā)，在實(shí)施中對(duì)ODS層、EDW、DM等不

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

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

論。

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

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

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

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

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

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

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

法。這個(gè)方法在當(dāng)時(shí)剛好與BillInnmon的自上而下建設(shè)方法相反。

類比BillInmon提出的方法論

建設(shè)周期需要花費(fèi)大量時(shí)間

維護(hù)難易度容易維護(hù)

建設(shè)成本前期投入大，后期建設(shè)成本低

建設(shè)周期周期長，見效慢

需要的團(tuán)隊(duì)類型專業(yè)團(tuán)隊(duì)搭建

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

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

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

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

數(shù)據(jù)模型準(zhǔn)三范式設(shè)計(jì)原則

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

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

的爭吵沒有結(jié)論，干脆提出一種新的架構(gòu)包含對(duì)方，也就是后來BillInmon

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

架構(gòu)模式將Ralphkilmball的數(shù)據(jù)集市包含了進(jìn)來，有關(guān)兩種數(shù)據(jù)倉庫實(shí)施

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

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

3.1.1第一代edw架構(gòu)

第一代“DW

Dafa

ETL

U/areHou

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

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

個(gè)世紀(jì)60年代GM與DarmouthCollege大學(xué)第一次提出，

“DatawareHouse”、“事實(shí)”是在上個(gè)世紀(jì)70年代BillInmon明確定義出

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

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

架構(gòu)。

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

主題的(SubjectOriented)、集成的(Integrate)、相對(duì)穩(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ì)目標(biāo)是事務(wù)處理。數(shù)據(jù)庫系統(tǒng)是為記錄更新和事務(wù)處理而設(shè)

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

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

求。

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

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

上。

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

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

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

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

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

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

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

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

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

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

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

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

巨大的成功。

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

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

3.1.2第二代大集市架構(gòu)

第二代大集市架構(gòu)

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

訂單條統(tǒng)X

Dafa-a9m9

forPlhADafa

U/HR

PIA/bus

ARJ

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

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

這種構(gòu)建方式可以不用考慮其它正在進(jìn)行的數(shù)據(jù)類項(xiàng)目實(shí)施，只要快速滿足當(dāng)

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

但是考慮到在實(shí)施中可能會(huì)存在多個(gè)并行的項(xiàng)目，是需要在數(shù)據(jù)標(biāo)準(zhǔn)化、模型

階段是需要進(jìn)行維度歸一化處理，需要有一套標(biāo)準(zhǔn)來定義公共維度，讓不同的

數(shù)據(jù)集市項(xiàng)目都遵守相同的標(biāo)準(zhǔn)，在后面的多個(gè)數(shù)據(jù)集市做合并時(shí)可以平滑處

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

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

主要核心：

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

性名稱、值和含義。

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

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

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

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

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

第三代匯總維度集市的標(biāo)準(zhǔn)數(shù)廢倉庫結(jié)構(gòu)

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

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

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

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

處理架構(gòu)，類似工廠一樣能滿足所有信息的需求與請(qǐng)求。這個(gè)信息工廠的功能

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

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

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

架構(gòu)定義成一個(gè)經(jīng)典架構(gòu)呢，因?yàn)镃IF的這種架構(gòu)總結(jié)了前面提到的兩種架構(gòu)

的同時(shí)，又把架構(gòu)的不同層次定義得非常明確。

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

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

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

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

Room)兩部分。后臺(tái)主要負(fù)責(zé)數(shù)據(jù)準(zhǔn)備工作，稱為數(shù)據(jù)準(zhǔn)備區(qū)(Staging

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

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

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

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

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

Dafa

U/qreH。皿

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

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

分析。

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

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

次有機(jī)的自動(dòng)化整合在一起，提供業(yè)務(wù)監(jiān)控與指導(dǎo)。

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

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

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

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

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

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

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

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

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

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

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

是圍繞著批處理、流式處理以及混合型架構(gòu)這三種來做演進(jìn)。

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

離線統(tǒng)計(jì)分析技術(shù)架構(gòu)

(OPS)(

取掘同步

服治型*

Kafka

泉據(jù)廿算

Dafax

其它

泉爆后儺

業(yè)務(wù)生產(chǎn)城5■，城

大料龐處理與心儲(chǔ)Hi

內(nèi)好辦公1統(tǒng)

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

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

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

數(shù)據(jù)源結(jié)構(gòu)化數(shù)據(jù)為主（數(shù)據(jù)庫數(shù)據(jù)、內(nèi)

辦公數(shù)據(jù)、財(cái)務(wù)數(shù)據(jù)等）、非結(jié)構(gòu)化數(shù)

很少或者是沒有

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

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

處理

技術(shù)：Datastage、informa、Dts、C

腳本等等

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

處理Teradata

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

數(shù)據(jù)應(yīng)用成型的解決方案產(chǎn)品：Report.

OLAP,在線分析等

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

任何變化，但是因?yàn)閿?shù)據(jù)量、性能等問題導(dǎo)致系統(tǒng)無法正常使用，需要進(jìn)行升

級(jí)改造，此類架構(gòu)便是為了解決這個(gè)問題。

3.2.2第二代流式架構(gòu)

Sfro?M/jshrot^

其它

S/TO?M

命k

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

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

實(shí)時(shí)性的要求變更高，自然計(jì)算與使用是同步進(jìn)行的。

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

類，以及需要更多算法或機(jī)器學(xué)習(xí)。這些應(yīng)用場(chǎng)景可以完全地分為兩類：事件

流、持續(xù)計(jì)算。

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

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

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

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

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

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

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

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

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

的方式進(jìn)行加載，再做進(jìn)一步處理。

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

SfroKt/js+roh*/fiink/

意據(jù)唐儂““)

肅式處理

J

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

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

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

架構(gòu)的優(yōu)化或升級(jí)版。

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

流式處理技術(shù)。

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

法論，在保證數(shù)據(jù)一致性、完整性的同時(shí)還會(huì)對(duì)數(shù)據(jù)按照不同應(yīng)用場(chǎng)景

進(jìn)行分層。

?實(shí)時(shí)流式處理主要是增量計(jì)算，也會(huì)跑一些機(jī)器學(xué)習(xí)模型等。為了保證

數(shù)據(jù)的一致性，實(shí)時(shí)流處理結(jié)果與批量處理結(jié)果會(huì)有一個(gè)合并動(dòng)作。

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

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

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

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

典的ODS、DWD、DWB、ST/ADM的層次結(jié)構(gòu)來劃分。

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

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

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

?服務(wù)層(Servinglayer)：這是Lambda架構(gòu)的最后一層，服務(wù)層的職

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

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

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

勢(shì)，兩套數(shù)據(jù)流因?yàn)榻Y(jié)果要做合并，所有的算法要實(shí)現(xiàn)兩次，一次是批處理、

一次是實(shí)時(shí)計(jì)算，最終兩個(gè)結(jié)果還得做合并顯得會(huì)很復(fù)雜。

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

第總隊(duì)列

散貸誦教強(qiáng)傳輸緯洗/處理/它儲(chǔ)

在Lamadba架構(gòu)下需要維護(hù)兩套的代碼，為了解決這個(gè)問題，Linkedln公司的

JayKreps結(jié)合實(shí)際經(jīng)驗(yàn)與個(gè)人思考提出了Kappa架構(gòu)。

Kappa架構(gòu)核心是通過改進(jìn)流式計(jì)算架構(gòu)的計(jì)算、存儲(chǔ)部分來解決全量的問

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

的重復(fù)計(jì)算幾率是很小的，即使需要，可以通過啟用不同的實(shí)例的方式來做重

復(fù)計(jì)算。

其中Kappa的核心思想是：

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

就保存幾天。

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

行處理，并輸出到一個(gè)新的結(jié)果存儲(chǔ)中。

?當(dāng)新的實(shí)例做完后，停止老的流計(jì)算實(shí)例，并把一些老的結(jié)果刪除。

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

口徑。

Kappa架構(gòu)與Lamabda架構(gòu)相比，其優(yōu)缺點(diǎn)是：

?Lambda架構(gòu)需要維護(hù)兩套跑在批處理和實(shí)時(shí)流上的代碼，兩個(gè)結(jié)果還需

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

據(jù)。

?Kappa架構(gòu)下可以同時(shí)啟動(dòng)很多實(shí)例來做重復(fù)計(jì)算，有利于算法模型調(diào)

整優(yōu)化與結(jié)果對(duì)比，Lamabda架構(gòu)下，代碼調(diào)整比較復(fù)雜。所以kappa

架構(gòu)下，技術(shù)人員只需要維護(hù)一個(gè)框架就可以，成本很小。

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

會(huì)變長。

?Kappa這種架構(gòu)過度依賴于Redis、Hbase服務(wù)，兩種存儲(chǔ)結(jié)構(gòu)又不是滿

足全量數(shù)據(jù)存儲(chǔ)的，用來做全量存儲(chǔ)會(huì)顯得浪費(fèi)資源。

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

明號(hào)叢則

AWST

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

技處理

數(shù)據(jù)

算法與疙碌操型

/jstrohx/Spark/f&k/其

敬隹庠Canal

流式處理

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

以上的這些架構(gòu)都圍繞大數(shù)據(jù)處理為主，Unifield架構(gòu)則更激進(jìn)，將機(jī)器學(xué)習(xí)

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

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

型訓(xùn)練部分，并且將其在流式層進(jìn)行使用。同時(shí)流式層不單使用模型，也包含

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

3.2.6IOTA架構(gòu)

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

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

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

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

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

主要有幾個(gè)特點(diǎn)：

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

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

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

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

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

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

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

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

理。

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

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

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

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

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

架構(gòu)模式來實(shí)施的，暫時(shí)沒有更多的個(gè)人經(jīng)驗(yàn)來分享這塊。

3.2.7小結(jié)

大數(shù)據(jù)架構(gòu)的每一代的定義與出現(xiàn)是有必然性的，當(dāng)然沒有一個(gè)嚴(yán)格上的時(shí)間

區(qū)分點(diǎn)。直接給出一個(gè)每種架構(gòu)比較：

架構(gòu)優(yōu)點(diǎn)缺點(diǎn)

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

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

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

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

構(gòu)架構(gòu)替換掉BI的組件。活度和穩(wěn)定度

的靈活度不夠

量報(bào)表，或者

景，需要太多

時(shí)該架構(gòu)依舊

乏實(shí)時(shí)的支撐

流式架沒有臃腫的ETL過程，對(duì)于流式架構(gòu)

構(gòu)數(shù)據(jù)的實(shí)效性非常高。理，因此對(duì)于

統(tǒng)計(jì)無法很好

分析僅僅支撐

Lambd既有實(shí)時(shí)又有離線，對(duì)離線層和實(shí)時(shí)

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

非常到位。卻是相同，因

復(fù)的模塊存在

KappaKappa架構(gòu)解決了雖然Kappa架

架構(gòu)Lambda架構(gòu)里面的冗是實(shí)施難度相

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

的超凡脫俗的思想講行

架構(gòu)講完了，落地肯定是離不開技術(shù)的，我之前花了不少時(shí)間整理了一下目前

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

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

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

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

我花了蠻多的時(shí)間梳理的。

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

數(shù)倉層Hivec

c

C

傳輸層

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

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

把整合結(jié)果數(shù)據(jù)存到數(shù)據(jù)倉庫以及相關(guān)存儲(chǔ)區(qū)域中。

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

?通過OLAP、分析、算