一、前大數(shù)據(jù)時代

人人都知道羅馬不是一天建成的，但沒人告訴過你羅馬是怎樣一天天建成的。你看見羅馬時，它就已經(jīng)是羅馬了。當(dāng)我進(jìn)阿里時，正是這樣的感覺。

我沒有經(jīng)歷過阿里數(shù)據(jù)架構(gòu)（包括平臺工具）從0到1的過程。我相信很多阿里老員工也沒有未見得全經(jīng)歷過。因?yàn)閺男袠I(yè)視角來看，這是一個長達(dá)二三十年的過程，阿里作為先行者本身也是摸著石頭過河。很多年輕一些的阿里員工看到當(dāng)前的架構(gòu)設(shè)計，他們的感受大概就是：“不就該是這樣嗎？不然還能怎樣？”?

魯迅就有話說了：“從來如此，便對么？”

好在我前些年輾轉(zhuǎn)了多家公司，有幸在一線接觸到了國內(nèi)外各種不同業(yè)務(wù)不同類型的數(shù)據(jù)團(tuán)隊(duì)及架構(gòu)，再加上自己翻閱資料，才基本梳理清楚了數(shù)據(jù)架構(gòu)的發(fā)展脈絡(luò)。

BI系統(tǒng)

現(xiàn)在人們身處大數(shù)據(jù)時代的洪流之中，數(shù)據(jù)產(chǎn)品日新月異，令人應(yīng)接不暇。阿里還出過一本書——《大數(shù)據(jù)之路》，里面詳細(xì)介紹了大數(shù)據(jù)從采集到消費(fèi)等各個環(huán)節(jié)的方法論和案例。那么，在大數(shù)據(jù)時代之前，人們也進(jìn)行數(shù)據(jù)分析嗎？那時的人們又使用的是怎樣的工具和方法論呢？ 這就要介紹一位熟悉又陌生的老朋友——BI系統(tǒng)。說它熟悉，是因?yàn)閿?shù)據(jù)側(cè)的同學(xué)幾乎天天都會和BI系統(tǒng)打交道，比如阿里的FBI。說它陌生，是因?yàn)楝F(xiàn)在的BI系統(tǒng)與上世紀(jì)九十年代的初代BI系統(tǒng)并不完全是一回事。

BI（Business Intelligence，商業(yè)智能）的概念很早就有了（正如AI這一概念一樣）。早期它的內(nèi)涵相對模糊，按照百度百科的解釋：“商業(yè)智能描述了一系列的概念和方法，通過應(yīng)用基于事實(shí)的支持系統(tǒng)來輔助商業(yè)決策的制定。“隨著人們實(shí)踐不斷深入，BI系統(tǒng)的樣貌也逐漸清晰。

到了上世紀(jì)九十年代，BI系統(tǒng)迎來了它的第一個輝煌時期，Gartner將各種類型的類BI系統(tǒng)全部統(tǒng)稱為BI，BI產(chǎn)品也基本確定為了是一套集數(shù)據(jù)清洗、數(shù)據(jù)分析、數(shù)據(jù)挖掘、報表展示等功能于一體的完整解決方案，數(shù)據(jù)倉庫也基于此建立。從此BI系統(tǒng)一統(tǒng)江湖，江湖上再也沒了DSS（Decision Support System, 決策支持系統(tǒng)）、EIS（Executive Information System, 主管信息系統(tǒng)）的名字。如果大家翻閱出版于上世紀(jì)八九十年代的數(shù)據(jù)倉庫領(lǐng)域的書籍，就會發(fā)現(xiàn)里面頻繁出現(xiàn)DSS、EIS、DW/BI等概念，例如William H.Inmon所著的《數(shù)據(jù)倉庫（Building the Data Warehouse）》、Ralph Kimball所著的《數(shù)據(jù)倉庫生命周期工具箱（The Data Warehouse Lifecycle Toolkit）》等，即便它們經(jīng)歷了多次翻譯和再版，但其中的概念還是得以保留，大家一定要注意辨析其中很多概念實(shí)際上早已過時。

事實(shí)上，與中國許多工業(yè)領(lǐng)域的發(fā)展一樣，正由于我們起步晚，因此反而沒有歷史包袱，我國絕大多數(shù)企業(yè)都沒有經(jīng)歷過初代BI的時代，因此除非對技術(shù)歷史感興趣也實(shí)在沒有必要去了解這些概念。? 那時雖然沒有大數(shù)據(jù)的概念，但數(shù)據(jù)分析、商業(yè)分析顯然是人們長久以來都有的需求，也積累了相當(dāng)多的方法論。

當(dāng)數(shù)據(jù)量不是主要矛盾時，BI系統(tǒng)能夠支持的分析方法、UI等層面就成為了核心競爭力。BI系統(tǒng)的核心是Cube，它是一個業(yè)務(wù)模型抽象，在Cube上可以上鉆、下鉆、切片，為了更方便多維分析，還配套了MDX查詢語言。當(dāng)然，大多數(shù)BI系統(tǒng)都構(gòu)建在關(guān)系型數(shù)據(jù)庫之上，或者說很多BI系統(tǒng)本就是商業(yè)關(guān)系型數(shù)據(jù)庫的配套產(chǎn)品，因此也都是支持SQL語言的。在計算和存儲上可能類似于開源框架Apache Kylin。??

初代BI系統(tǒng)沒落的原因主要是：

1.底層構(gòu)建在傳統(tǒng)關(guān)系型數(shù)據(jù)庫之上，因?yàn)榇嬖跀?shù)據(jù)一致性約束等問題，支持不了大數(shù)據(jù)。（這也暗合了網(wǎng)傳了很多年的阿里技術(shù)規(guī)范中提到的一條——不要設(shè)置外鍵，要通過其他技術(shù)手段保證數(shù)據(jù)一致性。）

2.不支持非結(jié)構(gòu)化數(shù)據(jù)。?

說它沒落，但是它也并未消亡，在歐洲、澳大利亞、東南亞等不少地區(qū)還有不少傳統(tǒng)企業(yè)仍然在使用這項(xiàng)技術(shù)。因此人們常說這些地方技術(shù)落后國內(nèi)互聯(lián)網(wǎng)大廠二十年，這就是一典型案例。而中國伴隨著經(jīng)濟(jì)的快速發(fā)展、互聯(lián)網(wǎng)技術(shù)的迅速普及、開源大數(shù)據(jù)技術(shù)的引進(jìn)和國務(wù)院《促進(jìn)大數(shù)據(jù)發(fā)展行動綱要》的印發(fā)，除了阿里等少數(shù)企業(yè)，幾乎是一步到位直接進(jìn)入了大數(shù)據(jù)時代。?

下面就談?wù)劥髷?shù)據(jù)時代中數(shù)據(jù)架構(gòu)的變遷。

二、大數(shù)據(jù)架構(gòu)的演變

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

為了解決上述問題，一些公司開始研發(fā)分布式的計算引擎和分布式的存儲平臺。其中最成功、最知名的便是Google研發(fā)的分布式文件系統(tǒng)與MapReduce計算引擎，后來這套技術(shù)被開源重寫為了Hadoop體系的多個項(xiàng)目，其生態(tài)圈也不斷擴(kuò)大。?

下圖是一個典型的傳統(tǒng)大數(shù)據(jù)架構(gòu)：

?

雖然我在上文提到了Hadoop體系，但我還是需要做一點(diǎn)澄清——本文提到的架構(gòu)與具體的技術(shù)選型沒有必然聯(lián)系。比如上圖的傳統(tǒng)大數(shù)據(jù)架構(gòu)，它的業(yè)務(wù)系統(tǒng)數(shù)據(jù)源可能是關(guān)系型數(shù)據(jù)庫MySQL，也可能是平面文件，也可能是任意未知的源；數(shù)據(jù)采集和數(shù)據(jù)同步工具也是視具體的業(yè)務(wù)和上下游技術(shù)選型而定；接下來數(shù)據(jù)會進(jìn)入數(shù)據(jù)倉庫，大致上會依次經(jīng)過ODS層、DWD層和ADS層，最終提供給消費(fèi)方使用。

在Miravia的技術(shù)選型中，通常業(yè)務(wù)數(shù)據(jù)通過binlog同步到TT，或者流量日志直接上報到日志服務(wù)器，再同步到TT。TT定期將一個時間區(qū)間內(nèi)的數(shù)據(jù)同步到ODPS，ODPS再通過每日調(diào)度的任務(wù)對這些數(shù)據(jù)進(jìn)行處理，最終落到ADS層的表。結(jié)果表的數(shù)據(jù)再同步到Holo或Lindorm等介質(zhì)中，供消費(fèi)方使用。因此單看這整個流程，實(shí)際上就是典型的傳統(tǒng)大數(shù)據(jù)架構(gòu)的一種實(shí)現(xiàn)。但需要注意的是，該架構(gòu)并沒有對輸入數(shù)據(jù)有結(jié)構(gòu)化的要求，也沒有規(guī)定ETL過程使用的工具和編程語言。

在這種架構(gòu)下，業(yè)務(wù)系統(tǒng)和分析系統(tǒng)的隔離性做得更好了，而且無論輸入數(shù)據(jù)是什么，最終提供給消費(fèi)方的都是標(biāo)準(zhǔn)的結(jié)構(gòu)化數(shù)據(jù)。它的缺點(diǎn)是整個過程不再有完整的解決方案，需要做大量的定制化工作。

流式架構(gòu)

正應(yīng)了湯師爺那句話：“步子大了，容易……”

流式架構(gòu)就是典型代表。

流式架構(gòu)的思路相當(dāng)激進(jìn)。雖然傳統(tǒng)大數(shù)據(jù)架構(gòu)在技術(shù)選型上與BI系統(tǒng)比已經(jīng)算是脫胎換骨，但其精神還是一脈相承。流式架構(gòu)干脆扔掉一整套離線的數(shù)據(jù)采集、數(shù)據(jù)同步和ETL工作，直接讓流式計算引擎消費(fèi)業(yè)務(wù)數(shù)據(jù)庫產(chǎn)生的增量數(shù)據(jù)，并直接輸出給消費(fèi)方，以此提供實(shí)時的計算結(jié)果。?

而早期的技術(shù)儲備明顯不足以同時高質(zhì)量保證實(shí)時性和結(jié)果的準(zhǔn)確性，因此只被用在了極少數(shù)對結(jié)果實(shí)時性十分敏感卻對準(zhǔn)確性要求不高的場景中。隨著技術(shù)的進(jìn)步和業(yè)務(wù)復(fù)雜度的提高，這種架構(gòu)也基本銷聲匿跡了。?

下圖是流式架構(gòu)的典型代表：?

Lambda架構(gòu)

在早期技術(shù)無法同時支持結(jié)果的實(shí)時性和準(zhǔn)確性的情況下，有沒有辦法可以通過架構(gòu)的設(shè)計，同時滿足兩者呢？有一位叫做Nathan Marz的大佬提出了Lambda架構(gòu)。

先看Lambda架構(gòu)的示意圖：

Lambda架構(gòu)的邏輯是，流任務(wù)與批任務(wù)讀取相同的數(shù)據(jù)源，實(shí)時計算結(jié)果由流任務(wù)產(chǎn)出；批任務(wù)通常按天執(zhí)行，計算T-1的數(shù)據(jù)，并寫入到結(jié)果表中。最終數(shù)據(jù)應(yīng)用根據(jù)自己的需要對兩個結(jié)果表的結(jié)果進(jìn)行合并。其核心思路是：用流任務(wù)保證結(jié)果的實(shí)時性，同時用批任務(wù)保證結(jié)果的最終一致性。

據(jù)我觀察，凡是對結(jié)果有實(shí)時性要求的業(yè)務(wù)團(tuán)隊(duì)，在數(shù)據(jù)側(cè)基本都采用的是這種架構(gòu)。但Lambda架構(gòu)有幾個顯而易見的缺點(diǎn)：

1.需要開發(fā)、維護(hù)兩套系統(tǒng)，成本太大。

2.兩套系統(tǒng)難以保證計算口徑的一致。甚至不同計算引擎提供的計算語義完全不同。

總之，Lambda架構(gòu)在滿足了部分業(yè)務(wù)需求的同時，給開發(fā)和運(yùn)維同學(xué)也帶來了“深重的災(zāi)難”。懂的都懂。

因此，我每每看到Lambda架構(gòu)這種硬把批和流雜糅在一起的架構(gòu)，都不免想起周星馳《少林足球》中的臺詞：

“少林功夫+唱歌跳舞，你說有沒有搞頭啊。”

”沒搞頭。“

”不試試你怎么知道沒搞頭。“

說完還邊唱邊跳：“少林功夫好耶，真是好。”?

如果說流式架構(gòu)好比是人用一條腿走路，存在先天性的不足，那么Lambda架構(gòu)就是走路時一條腿長一條腿短。

Kappa架構(gòu)

雖然Lambda架構(gòu)存在這么多缺點(diǎn)，但有行業(yè)大佬背書，并且在現(xiàn)有技術(shù)限制下，也很難提出更好的解決方案，故天下數(shù)（據(jù)）開（發(fā)），不敢言而敢怒，只等某一天“戍卒叫，函谷舉”。終于等到了另一位大佬Jay Kreps提出了一種新的架構(gòu)方案——Kappa架構(gòu)。?

在流處理技術(shù)不成熟的時期，主要問題之一就是吞吐量上不去。隨著Kafka等大數(shù)據(jù)消息隊(duì)列的出現(xiàn)，吞吐量不再是瓶頸。Kappa架構(gòu)的主要貢獻(xiàn)之一就是引入了分布式消息隊(duì)列。如下圖所示：

?與Lambda架構(gòu)不通，Kappa架構(gòu)只保留了流處理層，完全舍棄了批處理層。讓其中一個流處理層正常運(yùn)行，數(shù)據(jù)應(yīng)用讀取它的輸出；當(dāng)數(shù)據(jù)出現(xiàn)錯誤，或是業(yè)務(wù)邏輯發(fā)生變更時，啟動另一個流處理層，利用消息隊(duì)列的重播機(jī)制，重新消費(fèi)先前的數(shù)據(jù)并輸出到另一個結(jié)果表中，當(dāng)確定可以替換線上表時，完成替換。?

當(dāng)然，在實(shí)際生產(chǎn)中這個過程會復(fù)雜得多。而且受限于消息隊(duì)列數(shù)據(jù)生命周期的限制，這種架構(gòu)在生產(chǎn)中被應(yīng)用得較少。

不過，Kappa架構(gòu)的另一貢獻(xiàn)是啟發(fā)了人們用單一系統(tǒng)去實(shí)現(xiàn)曾經(jīng)需要兩套系統(tǒng)才能實(shí)現(xiàn)的需求。人們開始思考：為什么流式計算引擎不能提供結(jié)果的準(zhǔn)確性？是哪些環(huán)節(jié)出了問題？如果流處理能夠保證結(jié)果準(zhǔn)確性，是否意味著重啟流任務(wù)的需要大大降低，是否意味著Kappa架構(gòu)能夠徹底取代Lambda架構(gòu)？流處理引擎是否可以實(shí)現(xiàn)批處理引擎等價的語義？

后續(xù)文章將會通過對Flink底層技術(shù)細(xì)節(jié)的介紹來回答上述問題。在此之前，讓我們先脫離具體技術(shù)選型，來看看流批一體與上述架構(gòu)的關(guān)系。

三、流批一體與數(shù)據(jù)架構(gòu)的關(guān)系

流批一體聽起來很簡單，但內(nèi)涵卻十分復(fù)雜。它包含了計算語義、編程模型、API、調(diào)度、執(zhí)行、shuffle等各個方面的統(tǒng)一，不過對于我們數(shù)據(jù)開發(fā)的同學(xué)來說，我認(rèn)為流批一體最終想要達(dá)到的效果可以這樣描述：給定確定的數(shù)據(jù)源（可以是物理的也可以是邏輯上的），編寫一套代碼（Java代碼或SQL），執(zhí)行引擎能夠根據(jù)需要（例如根據(jù)用戶配置“STREAMING/BATCH”或自動識別）將代碼轉(zhuǎn)換為流任務(wù)（增量地讀取、流式地處理）或批任務(wù)（全量地讀取、批式地處理），并輸出相同的結(jié)果。

可以認(rèn)為這是計算引擎發(fā)展到一定階段后固有的一個能力，用戶可以使用也可以不使用，可以通過配置將其當(dāng)作單純的流式/批式計算引擎也是一種選擇。

現(xiàn)在我們討論的，是在同一個應(yīng)用中，同時使用兩種模式（手動配置或自動識別/切換）。而具體如何使用流批一體，要根據(jù)應(yīng)用類型而定，這既決定了流批一體與數(shù)據(jù)架構(gòu)的關(guān)系，也體現(xiàn)了流批一體在不同場景下的價值。

數(shù)據(jù)分析型應(yīng)用

數(shù)據(jù)側(cè)的同學(xué)開發(fā)的絕大多數(shù)應(yīng)用都屬于數(shù)據(jù)分析型應(yīng)用。上一節(jié)的所有數(shù)據(jù)架構(gòu)也基本是為這種應(yīng)用設(shè)計的。在這種應(yīng)用中，流批一體與Lambda架構(gòu)結(jié)合得最為自然。如下圖所示：?

這里引入了消息隊(duì)列，算是Jay Kreps在提出Kappa架構(gòu)時給我們提供的改進(jìn)思路。由于流任務(wù)和批任務(wù)用的是同一套代碼，我們默認(rèn)計算引擎內(nèi)部已經(jīng)實(shí)現(xiàn)了語義的統(tǒng)一，因此核心問題在于如何上輸入統(tǒng)一。輸出結(jié)果可以是不同的表，也可以是相同的表，根據(jù)需要而定，這并沒有太大影響。?

因?yàn)榱魅蝿?wù)和批任務(wù)對輸入的要求是不一樣的，前者一般讀取的都是類似Kafka這樣的消息流，后者則讀取的是數(shù)據(jù)庫在某一刻的全量快照，所以我們暫且認(rèn)為兩個任務(wù)需要用不同的連接器讀取不同的數(shù)據(jù)源。為了保證輸入統(tǒng)一，我們可以讓流任務(wù)直接讀取消息隊(duì)列中的數(shù)據(jù)，這樣它就在一刻不停地讀取業(yè)務(wù)上的增量數(shù)據(jù)；在離線側(cè)，我們周期性地將消息隊(duì)列中的數(shù)據(jù)落盤，然后每日單獨(dú)處理當(dāng)天的增量數(shù)據(jù)，由此批任務(wù)也達(dá)成了周期性處理增量數(shù)據(jù)的效果。理想情況下，當(dāng)批任務(wù)把T-1的數(shù)據(jù)輸出時，結(jié)果應(yīng)與流任務(wù)先前輸出的T-1的結(jié)果相同。

這就是流批一體在數(shù)據(jù)分析型應(yīng)用中的典型案例，它是Lambda架構(gòu)的一種高級實(shí)現(xiàn)，解決了原Lambda架構(gòu)中需要開發(fā)兩套代碼、維護(hù)兩套系統(tǒng)、計算邏輯口徑不一致的問題。Dataphin提供給大家的解決方案就是針對這種應(yīng)用而來的。

不過要特別注意的是，計算邏輯口徑一致不是因?yàn)槟闶褂昧讼嗤拇a，而是基于相同的代碼，計算引擎內(nèi)部將其翻譯成批任務(wù)和流任務(wù)時在語義、編程模型等方面達(dá)到了統(tǒng)一。如果計算引擎內(nèi)部沒有做到這一點(diǎn)，即便寫了相同的代碼也是無濟(jì)于事的。

數(shù)據(jù)管道型應(yīng)用

除了數(shù)據(jù)分析型應(yīng)用，還有一類應(yīng)用，比如數(shù)據(jù)同步，這部分工作其實(shí)也可以通過計算引擎來實(shí)現(xiàn)，流批一體在這其中還能發(fā)揮大作用。這類應(yīng)用可以叫做數(shù)據(jù)管道型應(yīng)用。?

比如需求是將一個線上數(shù)據(jù)庫中的數(shù)據(jù)遷移到另一個數(shù)據(jù)庫中，在同步的過程中線上數(shù)據(jù)庫仍然會繼續(xù)發(fā)生增刪改查等業(yè)務(wù)操作。以往的方式往往是先通過一個離線同步工具同步全量數(shù)據(jù)，再通過另一個增量同步工具不斷地同步新增數(shù)據(jù)。在這個過程中選擇從哪一時刻開始增量同步是一大難點(diǎn)。如果在同步的過程中需要對數(shù)據(jù)做一些清洗或轉(zhuǎn)換，則難度又大了一截。

而通過計算引擎的流批一體能力和對應(yīng)的connector，則可以解決上述問題。我們可以直接通過寫SQL的方式聲明數(shù)據(jù)轉(zhuǎn)換的邏輯，配合connector的能力，計算引擎會先批量讀取數(shù)據(jù)，然后在某一時刻自動切換成流任務(wù)增量讀取后續(xù)數(shù)據(jù)，而計算引擎內(nèi)部流批一體的能力保證了語義的相同。

例如Flink CDC項(xiàng)目就是在做這樣的事。不過在此場景中Flink runtime是否有流和批的區(qū)別，這一點(diǎn)我并沒有核實(shí)。?

不管怎么說，這也可以算是廣義的流批一體的應(yīng)用。并且，利用此技術(shù)，還可以實(shí)現(xiàn)實(shí)時數(shù)倉的建設(shè)，這在后續(xù)文章中或許會提到，大家也可以直接參考其他文章。

四、總結(jié)

數(shù)據(jù)架構(gòu)經(jīng)歷了如下演變：

早期BI系統(tǒng) --> 傳統(tǒng)大數(shù)據(jù)架構(gòu)（解決數(shù)據(jù)量的問題，但業(yè)務(wù)延遲高）

傳統(tǒng)大數(shù)據(jù)架構(gòu) --> 流式架構(gòu)（解決業(yè)務(wù)延遲問題，但數(shù)據(jù)準(zhǔn)確性低）

流式架構(gòu) --> Lambda架構(gòu)（解決數(shù)據(jù)準(zhǔn)確性低的問題，用實(shí)時層保證低延遲，用離線層保證數(shù)據(jù)最終一致性，但架構(gòu)復(fù)雜、計算邏輯口徑難以一致）

Lambda架構(gòu) --> Kappa架構(gòu)（解決架構(gòu)冗余問題和計算邏輯口徑不一致的問題，但消息隊(duì)列數(shù)據(jù)生命周期短）

最終，在Lambda架構(gòu)的基礎(chǔ)上采用了流批一體實(shí)現(xiàn)方案，使得系統(tǒng)復(fù)雜度降低，計算邏輯口徑達(dá)成一致。

流批一體當(dāng)然也能用在其他架構(gòu)中，以Flink為例，利用Flink CDC技術(shù)還能有更多玩法，但Lambda架構(gòu)這一案例在我看來是能夠最直觀展示流批一體這一技術(shù)在數(shù)據(jù)架構(gòu)中的位置和作用的。?

審核編輯：劉清