編輯導(dǎo)讀：數(shù)據(jù)中臺是近幾年比較火熱的話題，不少公司都在其探索。作者結(jié)合自己在數(shù)據(jù)中臺領(lǐng)域多年實踐經(jīng)驗，總結(jié)了數(shù)據(jù)架構(gòu)知識、BI 知識，以及分享給大家一些產(chǎn)業(yè)互聯(lián)網(wǎng)實施經(jīng)驗。本文是系列文章中的第三篇。

在前面兩篇“關(guān)于數(shù)字化轉(zhuǎn)型的幾個見解”、“唯一性定理中的數(shù)據(jù)中臺”提到了數(shù)據(jù)中臺發(fā)展問題。比如概念發(fā)展太快，信息量過載，以及存在廣義、狹義的數(shù)據(jù)中臺定義的差別等，涉及到的這些知識都離不開數(shù)據(jù)架構(gòu)的范疇，所以這一篇我會通過大數(shù)據(jù)架構(gòu)發(fā)展的視角來總結(jié)與分享。（一些知識繼承自己在2015年寫的《從數(shù)據(jù)倉庫到大數(shù)據(jù)，數(shù)據(jù)平臺這25年是怎樣進(jìn)化的？》，又名我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史系列），主要涉及三個方面：

• 從數(shù)倉架構(gòu)到大數(shù)據(jù)架構(gòu)總共三個時代九種架構(gòu)的演進(jìn)
• 自己整理的大數(shù)據(jù)技術(shù)棧
• 最新一代的Data Mesh 架構(gòu)的數(shù)據(jù)平臺

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

從現(xiàn)在的企業(yè)發(fā)展來看，大家的訴求重點已經(jīng)從經(jīng)營與分析轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運營。在如何做好精細(xì)化運營過程中，企業(yè)也面臨著來自創(chuàng)新、發(fā)展、內(nèi)卷等的各方面壓力。隨著業(yè)務(wù)量、數(shù)據(jù)量增長，大家對數(shù)據(jù)粒度需求從之前的高匯總逐漸轉(zhuǎn)為過程化的細(xì)粒度明細(xì)數(shù)據(jù)，以及從T+1的數(shù)據(jù)轉(zhuǎn)為近乎實時的數(shù)據(jù)訴求。

大量的數(shù)據(jù)需求、海量的臨時需求，讓分析師、數(shù)據(jù)開發(fā)疲憊不堪。這些職位也變成了企業(yè)資源的瓶頸，傳統(tǒng)BI中的 Report、OLAP 等工具也都無法滿足互聯(lián)網(wǎng)行業(yè)個性化的數(shù)據(jù)需求。大家開始考慮如何把需求固定為一個面向最終用戶自助式、半自助的產(chǎn)品，來快速獲取數(shù)據(jù)并分析得到結(jié)果，數(shù)據(jù)通過各類數(shù)據(jù)產(chǎn)品對外更有針對性的數(shù)據(jù)價值傳遞。

（關(guān)于數(shù)據(jù)產(chǎn)品一個題外補充：當(dāng)總結(jié)出的指標(biāo)、分析方法（模型）、使用流程與工具有機的結(jié)合在一起時數(shù)據(jù)產(chǎn)品就此產(chǎn)生，隨著數(shù)據(jù)中臺&數(shù)據(jù)平臺的建設(shè)逐漸的進(jìn)入快速迭代期，數(shù)據(jù)產(chǎn)品、數(shù)據(jù)產(chǎn)品經(jīng)理這兩個詞逐漸的升溫并逐漸到今天各大公司對數(shù)產(chǎn)品經(jīng)理崗位的旺盛訴求，目前這兩方面的方法論也逐步的體系化、具象化）。

在這十幾年中，影響數(shù)據(jù)倉庫、數(shù)據(jù)平臺、數(shù)據(jù)中臺、數(shù)據(jù)湖的演進(jìn)變革的因素也很多，比如不斷快速迭代的業(yè)務(wù)模式與膨脹的群體規(guī)模所帶來的數(shù)據(jù)量的沖擊，新的大數(shù)據(jù)處理技術(shù)的驅(qū)動。還有落地在數(shù)據(jù)中臺上各種數(shù)據(jù)產(chǎn)品的建設(shè)，比如工具化數(shù)據(jù)產(chǎn)品體系、各種自助式的數(shù)據(jù)產(chǎn)品、平臺化各數(shù)據(jù)產(chǎn)品的建設(shè)。這些數(shù)據(jù)建設(shè)能力的泛化，也讓更多的大眾參與數(shù)據(jù)中臺的建設(shè)中 ，比如一些懂SQL的用戶以及分析師參與數(shù)據(jù)平臺直接建設(shè)比重增加 。還有一些原本數(shù)據(jù)中臺具備的能力也有一些逐步地被前置到業(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ù)平臺、數(shù)據(jù)中臺、數(shù)據(jù)湖等，從大數(shù)據(jù)架構(gòu)角度來看可用三個時代九種架構(gòu)來做總結(jié)，其中前四代是傳統(tǒng)數(shù)據(jù)倉庫時代的架構(gòu)，后面五代是大數(shù)據(jù)架構(gòu)模式。

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

• 一個特殊地方是，傳統(tǒng)行業(yè)第三代架構(gòu)與大數(shù)據(jù)第一代架構(gòu)在架構(gòu)形式上基本相似。傳統(tǒng)行業(yè)的第三代架構(gòu)可以算是用大數(shù)據(jù)處理技術(shù)重新實現(xiàn)了一遍。
• 傳統(tǒng)行業(yè)第四代的架構(gòu)中實時部分在現(xiàn)代用大數(shù)據(jù)實時方式做了新的落地。

如下圖所示：

三個時代：非互聯(lián)網(wǎng)、互聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)時代，每一種時代的業(yè)務(wù)特點、數(shù)據(jù)量、數(shù)據(jù)類型各不相同，自然數(shù)據(jù)架構(gòu)也是有顯著差異的。

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

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

我自己對傳統(tǒng)數(shù)據(jù)倉庫的發(fā)展，簡單抽象為為五個時代、四種架構(gòu)（或許也不是那么嚴(yán)謹(jǐn)）。

五個時代大概，按照兩位數(shù)據(jù)倉庫大師 Ralph kilmball、Bill Innmon 在數(shù)據(jù)倉庫建設(shè)理念上碰撞階段來作為小的分界線：

• 大概在 1991 年之前，數(shù)據(jù)倉庫的實施基本采用全企業(yè)集成的模式。
• 大概在 1992 年企業(yè)在數(shù)據(jù)倉庫實施基本采用 EDW 的方式，Bill Innmon 博士出版了《如何構(gòu)建數(shù)據(jù)倉庫》，里面清晰的闡述了EDW架構(gòu)與實施方式。
• 1994-1996 年是數(shù)據(jù)集市時代，這個時代另外一種維度建模、數(shù)據(jù)集市的方式較為盛行起來，其主要代表之一 Ralph Kimball 博士出版了他的第一本書“The DataWarehouse Toolkit”（《數(shù)據(jù)倉庫工具箱》），里面非常清晰的定義了數(shù)據(jù)集市、維度建模。
• 大概在 1996-1997 年左右的兩個架構(gòu)競爭時代。
• 1998-2001 年左右的合并年代。

在主要歷史事件中提到了兩位經(jīng)典代表人物：Bill Innmon、Ralph kilmball。這兩位在數(shù)據(jù)界可以算是元祖級別的人物。現(xiàn)在數(shù)據(jù)中臺/平臺的很多設(shè)計理念依然受到他倆90年代所提出方法論為依據(jù)。

經(jīng)典的 BIll Inmon 和 Ralph kilmball 爭論

Bill Inmon 提出的遵循的是自上而下的建設(shè)原則，Ralph kilmball提出自下而上的建設(shè)原則，兩種方法擁護(hù)者會在不同場合爭論哪一種方法論更有優(yōu)勢。

兩位大師對于建設(shè)方法爭論要點：

其中Bill Inmon的方法論：認(rèn)為僅僅有數(shù)據(jù)集市是不夠的，提倡先必須得從企業(yè)級的數(shù)據(jù)模型角度入手來構(gòu)建。企業(yè)級模型就有較為完善的業(yè)務(wù)主題域劃分、邏輯模型劃分，在解決某個業(yè)務(wù)單元問題時可以很容易的選擇不同數(shù)據(jù)路徑來組成數(shù)據(jù)集市。

后來數(shù)據(jù)倉庫在千禧年傳到中國后，幾個大實施廠商都是遵守該原則的實施方法，也逐漸的演進(jìn)成了現(xiàn)在大家熟悉的數(shù)據(jù)架構(gòu)中關(guān)于數(shù)據(jù)層次的劃分 ：

• Ods-> DW-> ST->應(yīng)用
• Ods->DWD->DW->DM ->應(yīng)用
• Ods->DWD->DWB->DWS ->應(yīng)用
• Ods->DWD->DW->ST（ADM）->應(yīng)用

上個 10 年的國內(nèi)實施數(shù)據(jù)倉庫以及數(shù)據(jù)平臺企業(yè)，有幾家專業(yè)的廠商：IBM、Teradata、埃森哲、菲奈特 (被東南收購)、亞信等。這些廠商針對自己領(lǐng)域服務(wù)的客戶，從方案特點等一系列角度出發(fā)，在實施中對 ODS 層、EDW、DM 等不同數(shù)據(jù)層逐步地賦予了各種不同的功能與含義。

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

數(shù)據(jù)集市年代的代表人物為 Ralph kilmball，他的代表作是 《The Data Warehouse Toolkit》。這本書就是大名鼎鼎的《數(shù)據(jù)倉庫工具箱》。企業(yè)級數(shù)據(jù)的建設(shè)方法主張自下而上建立數(shù)據(jù)倉庫，極力推崇創(chuàng)建數(shù)據(jù)集市，認(rèn)為數(shù)據(jù)倉庫是數(shù)據(jù)集市的集合，信息總是被存儲在多維模型中。

這種思想從業(yè)務(wù)或部門入手，設(shè)計面向業(yè)務(wù)或部門主題數(shù)據(jù)集市。隨著更多的不同業(yè)務(wù)或部門數(shù)據(jù)集市實施落地，此時企業(yè)可以根據(jù)需要來合并不同的數(shù)據(jù)集市，并逐步形成企業(yè)級的數(shù)據(jù)倉庫，這種方式被稱為自下而上(Botton-up)方法。這個方法在當(dāng)時剛好與 Bill Innmon 的自上而下建設(shè)方法相反。

隨著數(shù)據(jù)倉庫的不斷實踐與迭代發(fā)展，從爭吵期進(jìn)入到了合并的時代，其實爭吵的結(jié)果要么一方妥協(xié)，要么新的結(jié)論出現(xiàn)。Bill inmon 與 Ralph kilmball 的爭吵沒有結(jié)論，干脆提出一種新的架構(gòu)包含對方，也就是后來 Bill Inmon 提出的 CIF（corporation information factory）信息工廠的架構(gòu)模式，這個架構(gòu)模式將 Ralph kilmball 的數(shù)據(jù)集市包含了進(jìn)來，有關(guān)兩種數(shù)據(jù)倉庫實施方法論的爭吵才逐步地平息下來。

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

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

現(xiàn)在數(shù)據(jù)建設(shè)中使用到的“商業(yè)智能” 、“信息倉庫”等很多專業(yè)術(shù)語、方法論，基本上是在上世紀(jì)60年代至90年代出現(xiàn)的。比如“維度模型”這個詞是個世紀(jì) 60 年代 GM 與 Darmouth College 大學(xué)第一次提出， “DatawareHouse”、“事實” 是在上個世紀(jì)70年代BIll Inmon 明確定義出來的，后來 90 年代 BIll Inmon 出版《如何構(gòu)建數(shù)據(jù)倉庫》一書更加體系化的與明確定義了如何構(gòu)建數(shù)據(jù)倉庫，這套方法在落地上形成了第一代數(shù)據(jù)倉庫架構(gòu)。

在第一代的數(shù)據(jù)倉庫中，清晰地定義了數(shù)據(jù)倉庫(Data Warehouse) 是一個面向主題的(Subject Oriented) 、集成的( Integrate ) 、相對穩(wěn)定的(Non -Volatile ) 、反映歷史變化( Time Variant) 的數(shù)據(jù)集合，用于支持管理決策（ Decision Marking Support）。

首先，數(shù)據(jù)倉庫(Data Warehouse)是用來支持決策的、面向主題的用來支撐分析型數(shù)據(jù)處理的，這里有別于企業(yè)使用的數(shù)據(jù)庫。

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

數(shù)據(jù)庫系統(tǒng)的設(shè)計目標(biāo)是事務(wù)處理。數(shù)據(jù)庫系統(tǒng)是為記錄更新和事務(wù)處理而設(shè)計，數(shù)據(jù)的訪問的特點是基于主鍵，大量原子，隔離的小事務(wù)，并發(fā)和可恢復(fù)是關(guān)鍵屬性，最大事務(wù)吞吐量是關(guān)鍵指標(biāo)，因此數(shù)據(jù)庫的設(shè)計都反映了這些需求。

數(shù)據(jù)倉庫的設(shè)計目標(biāo)是決策支持。歷史的、摘要的、聚合的數(shù)據(jù)比原始的記錄重要的多。查詢負(fù)載主要集中在即席查詢和包含連接，聚合等復(fù)雜查詢操作上。

其次，數(shù)據(jù)倉庫(Data Warehouse)是對多種異構(gòu)數(shù)據(jù)源進(jìn)行有效集成與處理，是按照主題的方式對數(shù)據(jù)進(jìn)行重新整合，且包一般不怎么修改的歷史數(shù)據(jù)，一句話總結(jié)面向主題、集成性、穩(wěn)定性和時變性。

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

• 數(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ù)倉庫是隨時間而變化的，傳統(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)

第二代就是 Ralph kilmball 的大集市的架構(gòu)。第二代架構(gòu)基本可以成為總線型架構(gòu)，從業(yè)務(wù)或部門入手，設(shè)計面向業(yè)務(wù)或部門主題數(shù)據(jù)集市。Kilmball 的這種構(gòu)建方式可以不用考慮其它正在進(jìn)行的數(shù)據(jù)類項目實施，只要快速滿足當(dāng)前部門的需求即可，這種實施的好處是阻力較小且路徑很短。

但是考慮到在實施中可能會存在多個并行的項目，是需要在數(shù)據(jù)標(biāo)準(zhǔn)化、模型階段是需要進(jìn)行維度歸一化處理，需要有一套標(biāo)準(zhǔn)來定義公共維度，讓不同的數(shù)據(jù)集市項目都遵守相同的標(biāo)準(zhǔn)，在后面的多個數(shù)據(jù)集市做合并時可以平滑處理。比如業(yè)務(wù)中相似的名詞、不同系統(tǒng)的枚舉值、相似的業(yè)務(wù)規(guī)則都需要做統(tǒng)一命名，這里在現(xiàn)在的中臺就是全域統(tǒng)一 ID 之類的東西。

主要核心：

• 一致的維度，以進(jìn)行集成和全面支持。一致的維度具有一致的描述性屬性名稱、值和含義。
• 一致的事實是一致定義的；如果不是一致的業(yè)務(wù)規(guī)則，那么將為其指定一個獨特的名稱。業(yè)務(wù)中相似的名詞、不同系統(tǒng)的枚舉值、相似的業(yè)務(wù)規(guī)則都需要做統(tǒng)一命名。
• 建模方式：星型模型、雪花模型。

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

CIF（corporation information factor）信息工廠（作者備注，關(guān)于 Cif 的英文版文章名字 Corporate Information Factory (CIF) Overview），Bill Inmon 認(rèn)為企業(yè)的發(fā)展會隨著信息資源重要性會逐步的提升，會出現(xiàn)一種信息處理架構(gòu)，類似工廠一樣能滿足所有信息的需求與請求。這個信息工廠的功能包含了數(shù)據(jù)存儲與處理（活躍數(shù)據(jù)、沉默數(shù)據(jù)），支持跨部門甚至跨企業(yè)的數(shù)據(jù)訪問與整合，同時也要保證數(shù)據(jù)安全性等。

剛好 CIF 架構(gòu)模式也逐步的變成了數(shù)據(jù)倉庫第三代架構(gòu)。為什么把這個 CIF 架構(gòu)定義成一個經(jīng)典架構(gòu)呢，因為 CIF 的這種架構(gòu)總結(jié)了前面提到的兩種架構(gòu)的同時，又把架構(gòu)的不同層次定義得非常明確。

例如 CIF 2.0 主要包括集成轉(zhuǎn)換層（Integrated and Transformation Layer）、操作數(shù)據(jù)存儲（Operational Data Store）、數(shù)據(jù)倉庫（Enterprise Data Warehouse）、數(shù)據(jù)集市（Data Mart）、探索倉庫（Exploration Warehouse）等部件。Data Mart 分為后臺（Back Room）和前臺（Front Room）兩部分。后臺主要負(fù)責(zé)數(shù)據(jù)準(zhǔn)備工作，稱為數(shù)據(jù)準(zhǔn)備區(qū)（Staging Area），前臺主要負(fù)責(zé)數(shù)據(jù)展示工作，稱為數(shù)據(jù)集市（Data Mart）。

這個經(jīng)典的架構(gòu)在后來 2006 年~2012 年進(jìn)入到這個領(lǐng)域的從業(yè)者，乃至現(xiàn)在有些互聯(lián)網(wǎng)企業(yè)的數(shù)據(jù)平臺架構(gòu)也是相似的。

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

OPDM 大約是在 2011 年提出來的，嚴(yán)格上來說，Opdm 操作型數(shù)據(jù)集市（倉庫）是實時數(shù)據(jù)倉庫的一種，他更多的是面向操作型數(shù)據(jù)而非歷史數(shù)據(jù)查詢與分析。

在這里很多人會問到什么是操作型數(shù)據(jù)？比如財務(wù)系統(tǒng)、CRM 系統(tǒng)、營銷系統(tǒng)生產(chǎn)系統(tǒng)，通過某一種機制實時的把這些數(shù)據(jù)從各數(shù)據(jù)孤島按照業(yè)務(wù)的某個層次有機的自動化整合在一起，提供業(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ù)嘗試對傳統(tǒng)第三架構(gòu)進(jìn)行落地的。

比如說在Hadoop&Hive 剛興起的階段，有用SyaseIQ、Greenplum等技術(shù)來作為大數(shù)據(jù)處理技術(shù)，后來Hadoop&hive以及Facebook Scribe、Linkedin kafka等逐步開源后又產(chǎn)生了新的適應(yīng)互聯(lián)網(wǎng)大數(shù)據(jù)的架構(gòu)模式。

后續(xù)阿里巴巴淘系的TImeTunnel等更多的近百種大數(shù)據(jù)處理的開源技術(shù)，進(jìn)一步促進(jìn)了整個大數(shù)據(jù)處理架構(gòu)與技術(shù)框架的發(fā)展，我在后面會給出一個比較完善截止到目前所有技術(shù)的數(shù)據(jù)處理框架。

按照大數(shù)據(jù)的使用場景、數(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)計分析技術(shù)架構(gòu)

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

這代架構(gòu)定位是為了解決傳統(tǒng)BI的問題，簡單來說，數(shù)據(jù)分析的業(yè)務(wù)沒有發(fā)生任何變化，但是因為數(shù)據(jù)量、性能等問題導(dǎo)致系統(tǒng)無法正常使用，需要進(jìn)行升級改造，此類架構(gòu)便是為了解決這個問題。

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

流式的應(yīng)用場景非常廣泛， 比如搜索、推薦、信息流等都是在線化的，對數(shù)據(jù)實時性的要求變更高，自然計算與使用是同步進(jìn)行的。

隨著業(yè)務(wù)的復(fù)雜化，數(shù)據(jù)的處理邏輯更加復(fù)雜，比如各種維度交叉、關(guān)聯(lián)、聚類，以及需要更多算法或機器學(xué)習(xí)。這些應(yīng)用場景可以完全地分為兩類：事件流、持續(xù)計算。

• 事件流，就是業(yè)務(wù)相對固定，只是數(shù)據(jù)在業(yè)務(wù)的規(guī)則下不斷的變化。
• 持續(xù)計算，適合購物網(wǎng)站等場景。

流式計算處理框架與第一代的大數(shù)據(jù)處理框架相比，去掉了原有的ETL過程，數(shù)據(jù)流過數(shù)據(jù)通道時得到處理，處理結(jié)果通過消息的方式推送數(shù)據(jù)消費者。

流式計算框架舍棄了大數(shù)據(jù)離線批量處理模式，只有很少的數(shù)據(jù)存儲，所以數(shù)據(jù)保存周期非常短。如果有歷史數(shù)據(jù)場景或很復(fù)雜歷史數(shù)據(jù)參與計算的場景，實現(xiàn)起來難度就比較大。

現(xiàn)在一些場景，會把流式計算的結(jié)果數(shù)據(jù)周期性地存到批處理的數(shù)據(jù)存儲區(qū)域。如果有場景需要使用歷史數(shù)據(jù)，流式計算框架會把保存的歷史結(jié)果用更新的方式進(jìn)行加載，再做進(jìn)一步處理。

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

Lambda架構(gòu)是由Twitter工程師南森·馬茨（Nathan Marz）提出的，是一種經(jīng)典的、實施廣泛的技術(shù)架構(gòu)。后來出現(xiàn)的其他大數(shù)據(jù)處理架構(gòu)也是Lambda 架構(gòu)的優(yōu)化或升級版。

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

• 批量離線處理流在構(gòu)建時大部分還是采用一些經(jīng)典的大數(shù)據(jù)統(tǒng)計分析方法論，在保證數(shù)據(jù)一致性、完整性的同時還會對數(shù)據(jù)按照不同應(yīng)用場景進(jìn)行分層。
• 實時流式處理主要是增量計算，也會跑一些機器學(xué)習(xí)模型等。為了保證數(shù)據(jù)的一致性， 實時流處理結(jié)果與批量處理結(jié)果會有一個合并動作。

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

• 批處理層(Bathchlayer) ： Lambda架構(gòu)核心層之一，批處理接收過來的數(shù)據(jù)，并保存到相應(yīng)的數(shù)據(jù)模型中，這一層的數(shù)據(jù)主題、模型設(shè)計的方法論是繼承面向統(tǒng)計分析離線大數(shù)據(jù)中的。而且一般都會按照比較經(jīng)典的ODS、DWD、DWB、ST/ADM 的層次結(jié)構(gòu)來劃分。
• 流式處理層(Speed Layer) ： Lambda另一個核心層，為了解決比如各場景下數(shù)據(jù)需要一邊計算一邊應(yīng)用以及各種維度交叉、關(guān)聯(lián)的事件流與持續(xù)計算的問題，計算結(jié)果在最后與批處理層的結(jié)果做合并。
• 服務(wù)層( Serving layer) ：這是Lambda架構(gòu)的最后一層，服務(wù)層的職責(zé)是獲取批處理和流處理的結(jié)果，向用戶提供統(tǒng)一查詢視圖服務(wù)。

Lamabda 架構(gòu)理念從出現(xiàn)到發(fā)展這么多年，優(yōu)缺點非常明顯。比如穩(wěn)定與性能上的優(yōu)勢，ETL處理計算利用晚上時間來做，能復(fù)用部分實時計算的資源。劣勢，兩套數(shù)據(jù)流因為結(jié)果要做合并，所有的算法要實現(xiàn)兩次，一次是批處理、一次是實時計算，最終兩個結(jié)果還得做合并顯得會很復(fù)雜。

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

在Lamadba 架構(gòu)下需要維護(hù)兩套的代碼，為了解決這個問題，LinkedIn公司的Jay Kreps 結(jié)合實際經(jīng)驗與個人思考提出了Kappa 架構(gòu)。

Kappa 架構(gòu)核心是通過改進(jìn)流式計算架構(gòu)的計算、存儲部分來解決全量的問題，使得實時計算、批處理可以共用一套代碼。Kappa 架構(gòu)認(rèn)為對于歷史數(shù)據(jù)的重復(fù)計算幾率是很小的，即使需要，可以通過啟用不同的實例的方式來做重復(fù)計算。

其中Kappa的核心思想是：

• 用Kafka或者類似MQ隊列系統(tǒng)收集各種各樣的數(shù)據(jù)，需要幾天的數(shù)據(jù)量就保存幾天。
• 當(dāng)需要全量重新計算時，重新起一個流計算實例，從頭開始讀取數(shù)據(jù)進(jìn)行處理，并輸出到一個新的結(jié)果存儲中。
• 當(dāng)新的實例做完后，停止老的流計算實例，并把一些老的結(jié)果刪除。

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

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

• Lambda架構(gòu)需要維護(hù)兩套跑在批處理和實時流上的代碼，兩個結(jié)果還需要做merge， Kappa 架構(gòu)下只維護(hù)一套代碼，在需要時候才跑全量數(shù)據(jù)。
• Kappa 架構(gòu)下可以同時啟動很多實例來做重復(fù)計算，有利于算法模型調(diào)整優(yōu)化與結(jié)果對比，Lamabda架構(gòu)下，代碼調(diào)整比較復(fù)雜。所以kappa架構(gòu)下，技術(shù)人員只需要維護(hù)一個框架就可以，成本很小。
• kappa 每次接入新的數(shù)據(jù)類型格式是需要定制開發(fā)接入程序，接入周期會變長。
• Kappa這種架構(gòu)過度依賴于Redis、Hbase 服務(wù)，兩種存儲結(jié)構(gòu)又不是滿足全量數(shù)據(jù)存儲的，用來做全量存儲會顯得浪費資源。

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

以上的這些架構(gòu)都圍繞大數(shù)據(jù)處理為主，Unifield架構(gòu)則更激進(jìn)，將機器學(xué)習(xí)和數(shù)據(jù)處理整合為一體，從核心上來說，Unifield在Lambda基礎(chǔ)上進(jìn)行升級，在流處理層新增了機器學(xué)習(xí)層。數(shù)據(jù)經(jīng)過數(shù)據(jù)通道進(jìn)入數(shù)據(jù)湖，新增了模型訓(xùn)練部分，并且將其在流式層進(jìn)行使用。同時流式層不單使用模型，也包含著對模型的持續(xù)訓(xùn)練。

3.2.6 IOTA架構(gòu)

IOTA大數(shù)據(jù)架構(gòu)是一種基于AI生態(tài)下的、全新的數(shù)據(jù)架構(gòu)模式，這個概念由易觀于2018年首次提出。IOTA的整體思路是設(shè)定標(biāo)準(zhǔn)數(shù)據(jù)模型，通過邊緣計算技術(shù)把所有的計算過程分散在數(shù)據(jù)產(chǎn)生、計算和查詢過程當(dāng)中，以統(tǒng)一的數(shù)據(jù)模型貫穿始終，從而提高整體的計算效率，同時滿足計算的需要，可以使用各種Ad-hoc Query來查詢底層數(shù)據(jù)。

主要有幾個特點：

• 去ETL化：ETL和相關(guān)開發(fā)一直是大數(shù)據(jù)處理的痛點，IOTA架構(gòu)通過Common Data Model的設(shè)計，專注在某一個具體領(lǐng)域的數(shù)據(jù)計算，從而可以從SDK端開始計算，中央端只做采集、建立索引和查詢，提高整體數(shù)據(jù)分析的效率。
• Ad-hoc即時查詢：鑒于整體的計算流程機制，在手機端、智能IOT事件發(fā)生之時，就可以直接傳送到云端進(jìn)入real time data區(qū)，可以被前端的Query Engine來查詢。此時用戶可以使用各種各樣的查詢，直接查到前幾秒發(fā)生的事件，而不用在等待ETL或者Streaming的數(shù)據(jù)研發(fā)和處理。
• 邊緣計算（Edge-Computing）：將過去統(tǒng)一到中央進(jìn)行整體計算，分散到數(shù)據(jù)產(chǎn)生、存儲和查詢端，數(shù)據(jù)產(chǎn)生既符合Common Data Model。同時，也給與Realtime model feedback，讓客戶端傳送數(shù)據(jù)的同時馬上進(jìn)行反饋，而不需要所有事件都要到中央端處理之后再進(jìn)行下發(fā)。

可能是由于我接觸到的范圍有限，暫時還沒有遇到一家企業(yè)完整按照IOTA這個架構(gòu)模式來實施的，暫時沒有更多的個人經(jīng)驗來分享這塊。

3.2.7 小結(jié)

大數(shù)據(jù)架構(gòu)的每一代的定義與出現(xiàn)是有必然性的， 當(dāng)然沒有一個嚴(yán)格上的時間區(qū)分點。直接給出一個每種架構(gòu)比較：

架構(gòu)講完了，落地肯定是離不開技術(shù)的，我之前花了不少時間整理了一下目前大數(shù)據(jù)方向的技術(shù)棧的內(nèi)容。

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

分享完了架構(gòu)，在從大數(shù)據(jù)技術(shù)棧的角度來看看對應(yīng)的數(shù)據(jù)采集、數(shù)據(jù)傳輸、數(shù)據(jù)存儲、計算、ide管理、分析可視化微服務(wù)都有哪些技術(shù)，下圖的技術(shù)棧我花了蠻多的時間梳理的。

• 按照數(shù)據(jù)采集-傳輸-落地到存儲層，再通過調(diào)度調(diào)起計算數(shù)據(jù)處理任務(wù)把整合結(jié)果數(shù)據(jù)存到數(shù)據(jù)倉庫以及相關(guān)存儲區(qū)域中。
• 通過管理層/ide 進(jìn)行數(shù)據(jù)管理或數(shù)據(jù)開發(fā)。
• 通過OLAP 、分析、算法、可視化、微服務(wù)層對外提供數(shù)據(jù)服務(wù)與數(shù)據(jù)場景化應(yīng)用。

這個技術(shù)棧暫時沒有按照沒有按照批處理、流式技術(shù)的分類的角度來分類，稍微有點遺憾。

五、Data Mesh 面向域的分散式數(shù)據(jù)架構(gòu)

Data Mesh 是在2019年左右，由 ThoughtWorks的首席技術(shù)顧問Zhamak Dehghani提出的（《How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh》https://martinfowler.com/articles/data-monolith-to-mesh.html）。她將對客戶進(jìn)行企業(yè)數(shù)據(jù)平臺實施過程出現(xiàn)的問題和面向領(lǐng)域設(shè)計中的微服務(wù)結(jié)合了起來，思考出來了一種新式面向域的數(shù)據(jù)架構(gòu)。

企業(yè)面向數(shù)據(jù)平臺的實施中，不管是數(shù)據(jù)BI系統(tǒng)，還是基于大數(shù)據(jù)(數(shù)據(jù)湖)架構(gòu)模式，或者是基于云數(shù)據(jù)平臺，無一例外地延續(xù)著一個架構(gòu)（Monolithic Architecture）的核心模式，只是這個架構(gòu)的表現(xiàn)形式從一個嚴(yán)格規(guī)范化的數(shù)據(jù)倉庫，到更加專業(yè)的大數(shù)據(jù)（數(shù)據(jù)湖），最終轉(zhuǎn)化成一個多種實踐模式的混合。

現(xiàn)在這些大數(shù)據(jù)平臺實施與解決方案難以通過簡單復(fù)制來達(dá)到規(guī)?；?、商業(yè)化，企業(yè)數(shù)據(jù)平臺項目實施要三到五年的時間，巨大的投入使得投入產(chǎn)出比不夠高，很難獲取預(yù)期的收益。原文提到Zhamak Dehghani基于對基于對企業(yè)數(shù)據(jù)平臺架構(gòu)現(xiàn)狀和弊端以及微服務(wù)的視角提出了Data Meth 面向域的分布式架構(gòu)模式。這個架構(gòu)模式有四個特點：

• 面向域的數(shù)據(jù)架構(gòu)
• 自服務(wù)式的平臺基礎(chǔ)設(shè)施
• 數(shù)據(jù)產(chǎn)品導(dǎo)向的管理與角色
• 基于靈活、規(guī)模化、演進(jìn)式的基礎(chǔ)設(shè)施交付能力

講一下自己的理解(可能理解還是比較淺)：

• 面向域的數(shù)據(jù)架構(gòu)：對數(shù)據(jù)內(nèi)容即插即用的類似一種SaaS能力，比如根據(jù)領(lǐng)域建模來設(shè)計數(shù)據(jù)模型，比如之前IBM 的IAA模型，Teradata 金融標(biāo)準(zhǔn)模型提到的用戶主題域，參與者主題域、地址主題、集團(tuán)客戶主題等等，這類主題有自己的數(shù)據(jù)接入標(biāo)準(zhǔn)。比如通過數(shù)據(jù)處理流程、統(tǒng)計指標(biāo)、數(shù)據(jù)資產(chǎn)管理的模板化配置，只關(guān)心輸入內(nèi)容就可以得到完整輸出，并且自動完成合規(guī)、安全、管理以及運營型的一些工作。

• 自服務(wù)式的平臺基礎(chǔ)設(shè)施：為數(shù)據(jù)域架構(gòu)中提到落地功能提供必要的產(chǎn)品能力，例如提供各種快速組件化、配置化的基礎(chǔ)模板工具。像是提供自動化數(shù)據(jù)加工管理，數(shù)據(jù)模型建模到自動化ETL過程，指標(biāo)維度分析模板、數(shù)據(jù)應(yīng)用模板等，最終實現(xiàn)自動化與規(guī)?；?。(以前自己設(shè)計過一個自動化ETL引擎，并實現(xiàn)了最小迷你版落地，但是待解決的問題還比較多)。

• 數(shù)據(jù)產(chǎn)品導(dǎo)向的管理與角色，數(shù)據(jù)的價值本身就是透過數(shù)據(jù)產(chǎn)品對外進(jìn)行傳遞，從數(shù)據(jù)產(chǎn)品的角度來說偏業(yè)務(wù)數(shù)據(jù)產(chǎn)品、偏工具平臺數(shù)據(jù)產(chǎn)品，這些都是在推進(jìn)數(shù)據(jù)平臺的建設(shè)，自然不管數(shù)據(jù)價值的透傳方式、效率、洞察等都會通過租戶使用平臺工具去建設(shè)自己的數(shù)據(jù)能力。

自己也在思考未來給企業(yè)提供的數(shù)據(jù)服務(wù)能力是什么樣子，以及基于元數(shù)據(jù)驅(qū)動數(shù)據(jù)中臺/平臺是什么樣子的。

六、寫在結(jié)尾

自己在2015年時曾經(jīng)寫過一篇從數(shù)據(jù)團(tuán)隊組織變化角度來分享大數(shù)據(jù)的架構(gòu)進(jìn)化的文章，這次從大數(shù)據(jù)處理架構(gòu)做了一個發(fā)展總結(jié)，兩個角度基本上涵蓋了數(shù)據(jù)中臺/平臺建設(shè)比較重點兩個問題。

在上一篇中提到一個話題：數(shù)據(jù)中臺是有組織結(jié)構(gòu)的保障，很多地方都有提到數(shù)據(jù)中臺必須得有強力的組織上的保障！確實需要嗎？我的觀點是什么呢？這個系列的下一篇給大家講解數(shù)據(jù)中臺的組織結(jié)構(gòu)。

相關(guān)文章：

透過數(shù)字化轉(zhuǎn)型再談數(shù)據(jù)中臺（一）：關(guān)于數(shù)字化轉(zhuǎn)型的幾個見解

透過數(shù)字化轉(zhuǎn)型再談數(shù)據(jù)中臺（二）：唯一性定理中的數(shù)據(jù)中臺

作者：松子（李博源），BI& 數(shù)據(jù)產(chǎn)品老兵一枚，漂過幾個大廠。2016 年到現(xiàn)在持續(xù)輸出原創(chuàng)內(nèi)容幾十篇，《中臺翻車紀(jì)實》 、《從數(shù)據(jù)倉庫到大數(shù)據(jù)，數(shù)據(jù)平臺這 25 年是怎樣進(jìn)化的》 、《數(shù)據(jù)產(chǎn)品三部曲系列》等系列有思考深度的文章。

本文由 @松子 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議