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

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

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

魯迅就有話說(shuō)了：“從來(lái)如此，便對(duì)么？”

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

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

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

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

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

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

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

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

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

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

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

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

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

下圖是一個(gè)典型的傳統(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ù)庫(kù)MySQL，也可能是平面文件，也可能是任意未知的源；數(shù)據(jù)采集和數(shù)據(jù)同步工具也是視具體的業(yè)務(wù)和上下游技術(shù)選型而定；接下來(lái)數(shù)據(jù)會(huì)進(jìn)入數(shù)據(jù)倉(cāng)庫(kù)，大致上會(huì)依次經(jīng)過(guò)ODS層、DWD層和ADS層，最終提供給消費(fèi)方使用。

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

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

流式架構(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工作，直接讓流式計(jì)算引擎消費(fèi)業(yè)務(wù)數(shù)據(jù)庫(kù)產(chǎn)生的增量數(shù)據(jù)，并直接輸出給消費(fèi)方，以此提供實(shí)時(shí)的計(jì)算結(jié)果。?

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

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

Lambda架構(gòu)

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

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

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

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

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

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

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

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

“少林功夫+唱歌跳舞，你說(shuō)有沒有搞頭啊?！?/p>

”沒搞頭?！?/p>

”不試試你怎么知道沒搞頭?！?/p>

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

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

Kappa架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

因?yàn)榱魅蝿?wù)和批任務(wù)對(duì)輸入的要求是不一樣的，前者一般讀取的都是類似Kafka這樣的消息流，后者則讀取的是數(shù)據(jù)庫(kù)在某一刻的全量快照，所以我們暫且認(rèn)為兩個(gè)任務(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ù)輸出時(shí)，結(jié)果應(yīng)與流任務(wù)先前輸出的T-1的結(jié)果相同。

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

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

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

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

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

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

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

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

四、總結(jié)

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

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

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

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

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

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

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

審核編輯：劉清