前言

本文隸屬于專(zhuān)欄《大數(shù)據(jù)理論體系》，該專(zhuān)欄為筆者原創(chuàng)，引用請(qǐng)注明來(lái)源，不足和錯(cuò)誤之處請(qǐng)?jiān)谠u(píng)論區(qū)幫忙指出，謝謝！

本專(zhuān)欄目錄結(jié)構(gòu)和參考文獻(xiàn)請(qǐng)見(jiàn)大數(shù)據(jù)理論體系

姊妹篇

《分布式數(shù)據(jù)模型詳解：OldSQL =＞ NoSQL =＞ NewSQL》

《分布式計(jì)算模型詳解：MapReduce、數(shù)據(jù)流、P2P、RPC、Agent》

《大數(shù)據(jù)存儲(chǔ)架構(gòu)詳解：數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)集市、數(shù)據(jù)湖、數(shù)據(jù)網(wǎng)格、湖倉(cāng)一體》

《大數(shù)據(jù)處理架構(gòu)詳解：Lambda架構(gòu)、Kappa架構(gòu)、流批一體、Dataflow模型、實(shí)時(shí)數(shù)倉(cāng)》

《實(shí)時(shí)數(shù)倉(cāng)詳解》

思維導(dǎo)圖

Lambda 架構(gòu)

Lambda 的由來(lái)

我們通常認(rèn)為這個(gè)希臘字母與這一模式相關(guān)聯(lián)是因?yàn)閿?shù)據(jù)來(lái)自?xún)蓚€(gè)地方。

批量數(shù)據(jù)和快速的流式數(shù)據(jù)代表Lambda符號(hào)的彎曲部分，然后通過(guò)服務(wù)層(線(xiàn)段與曲線(xiàn)部分合并)合并，如上圖所示。

WHAT

Lambda架構(gòu)（Lambda Architecture）是由Twitter工程師南森·馬茨（Nathan Marz）提出的大數(shù)據(jù)處理架構(gòu)。

它的目標(biāo)是構(gòu)建一個(gè)通用的、健壯的大數(shù)據(jù)系統(tǒng)，能夠同時(shí)滿(mǎn)足實(shí)時(shí)查詢(xún)和歷史數(shù)據(jù)批處理的需求。

隨著大數(shù)據(jù)的興起，越來(lái)越多的公司開(kāi)始面臨海量數(shù)據(jù)的處理問(wèn)題。傳統(tǒng)的批處理系統(tǒng)無(wú)法滿(mǎn)足實(shí)時(shí)數(shù)據(jù)處理的需求，而簡(jiǎn)單的流式處理系統(tǒng)又無(wú)法進(jìn)行復(fù)雜的歷史數(shù)據(jù)分析。這就需要一種混合架構(gòu)，能夠兼顧實(shí)時(shí)性和復(fù)雜分析。Lambda架構(gòu)應(yīng)運(yùn)而生。

關(guān)于 Lambda 架構(gòu)的詳情請(qǐng)參考我的博客——《什么是Lambda架構(gòu)？》

組成

Lambda 架構(gòu)總共由三層系統(tǒng)組成：批處理層（Batch Layer），速度處理層（Speed Layer），以及用于響應(yīng)查詢(xún)的服務(wù)層（Serving Layer）。

在 Lambda 架構(gòu)中，每層都有自己所肩負(fù)的任務(wù)。

批處理層

批處理層存儲(chǔ)管理主數(shù)據(jù)集（不可變的數(shù)據(jù)集）和預(yù)先批處理計(jì)算好的視圖。

批處理層使用可處理大量數(shù)據(jù)的分布式處理系統(tǒng)預(yù)先計(jì)算結(jié)果。

它通過(guò)處理所有的已有歷史數(shù)據(jù)來(lái)實(shí)現(xiàn)數(shù)據(jù)的準(zhǔn)確性。

這意味著它是基于完整的數(shù)據(jù)集來(lái)重新計(jì)算的，能夠修復(fù)任何錯(cuò)誤，然后更新現(xiàn)有的數(shù)據(jù)視圖。

輸出通常存儲(chǔ)在只讀數(shù)據(jù)庫(kù)中，更新則完全取代現(xiàn)有的預(yù)先計(jì)算好的視圖。

速度處理層

速度處理層會(huì)實(shí)時(shí)處理新來(lái)的大數(shù)據(jù)。

速度層通過(guò)提供最新數(shù)據(jù)的實(shí)時(shí)視圖來(lái)最小化延遲。

速度層所生成的數(shù)據(jù)視圖可能不如批處理層最終生成的視圖那樣準(zhǔn)確或完整，但它們幾乎在收到數(shù)據(jù)后立即可用。

而當(dāng)同樣的數(shù)據(jù)在批處理層處理完成后，在速度層的數(shù)據(jù)就可以被替代掉了。

本質(zhì)上，速度層彌補(bǔ)了批處理層所導(dǎo)致的數(shù)據(jù)視圖滯后。

比如說(shuō)，批處理層的每個(gè)任務(wù)都需要 1 個(gè)小時(shí)才能完成，而在這 1 個(gè)小時(shí)里，我們是無(wú)法獲取批處理層中最新任務(wù)給出的數(shù)據(jù)視圖的。

而速度層因?yàn)槟軌驅(qū)崟r(shí)處理數(shù)據(jù)給出結(jié)果，就彌補(bǔ)了這 1 個(gè)小時(shí)的滯后。

服務(wù)層

所有在批處理層和速度層處理完的結(jié)果都輸出存儲(chǔ)在服務(wù)層中，服務(wù)層通過(guò)返回預(yù)先計(jì)算的數(shù)據(jù)視圖或從速度層處理構(gòu)建好數(shù)據(jù)視圖來(lái)響應(yīng)查詢(xún)。

Kappa 架構(gòu)

Kappa架構(gòu)是對(duì)Lambda架構(gòu)的改進(jìn)和優(yōu)化，由Jay Kreps于2014年首次提出。

隨著流式計(jì)算系統(tǒng)的發(fā)展，Lambda架構(gòu)存在的一些問(wèn)題逐漸顯現(xiàn)出來(lái)：

1. 系統(tǒng)復(fù)雜度高：需要同時(shí)開(kāi)發(fā)和維護(hù)批處理系統(tǒng)和流式系統(tǒng)。
2. 通過(guò)日志重播實(shí)現(xiàn)低延遲查詢(xún)，會(huì)導(dǎo)致數(shù)據(jù)冗余。
3. 實(shí)時(shí)視圖和批處理視圖存在延遲不一致的問(wèn)題。

為了解決這些問(wèn)題，Jay Kreps提出了Kappa架構(gòu)。Kappa架構(gòu)去除了Lambda架構(gòu)的批處理層，直接通過(guò)流式處理系統(tǒng)實(shí)現(xiàn)整個(gè)流程。

關(guān)于 Kappa 架構(gòu)的詳情請(qǐng)參考我的博客——《什么是Kappa架構(gòu)？》

組成

Kappa架構(gòu)主要包含兩個(gè)層:

1. 流式處理層：通過(guò)流式處理系統(tǒng)接收所有數(shù)據(jù)，并進(jìn)行實(shí)時(shí)計(jì)算，更新存儲(chǔ)中的結(jié)果視圖。
2. 服務(wù)層：對(duì)外提供查詢(xún)服務(wù)，直接基于流式處理層更新的結(jié)果視圖進(jìn)行查詢(xún)返回。

Kappa架構(gòu)減少了系統(tǒng)復(fù)雜度，避免了數(shù)據(jù)冗余和數(shù)據(jù)不一致的問(wèn)題。但需要流式處理系統(tǒng)能夠保證Exactly-once語(yǔ)義，以保證流式計(jì)算的正確性。而且，去除批處理系統(tǒng)后，對(duì)歷史數(shù)據(jù)的復(fù)雜計(jì)算會(huì)更加困難。

以 Apache Kafka 為例來(lái)講述整個(gè)Kappa架構(gòu)的過(guò)程

1. 部署 Apache Kafka，并設(shè)置數(shù)據(jù)日志的保留期（Retention Period）。這里的保留期指的是你希望能夠重新處理的歷史數(shù)據(jù)的時(shí)間區(qū)間。例如，如果你希望重新處理最多一年的歷史數(shù)據(jù)，那就可以把 Apache Kafka 中的保留期設(shè)置為 365 天。如果你希望能夠處理所有的歷史數(shù)據(jù)，那就可以把 Apache Kafka 中的保留期設(shè)置為“永久（Forever）”。
2. 如果我們需要改進(jìn)現(xiàn)有的邏輯算法，那就表示我們需要對(duì)歷史數(shù)據(jù)進(jìn)行重新處理。我們需要做的就是重新啟動(dòng)一個(gè) Apache Kafka 作業(yè)實(shí)例（Instance）。這個(gè)作業(yè)實(shí)例將重頭開(kāi)始，重新計(jì)算保留好的歷史數(shù)據(jù)，并將結(jié)果輸出到一個(gè)新的數(shù)據(jù)視圖中。我們知道 Apache Kafka 的底層是使用 Log Offset 來(lái)判斷現(xiàn)在已經(jīng)處理到哪個(gè)數(shù)據(jù)塊了，所以只需要將 Log Offset 設(shè)置為 0，新的作業(yè)實(shí)例就會(huì)重頭開(kāi)始處理歷史數(shù)據(jù)。
3. 當(dāng)這個(gè)新的數(shù)據(jù)視圖處理過(guò)的數(shù)據(jù)進(jìn)度趕上了舊的數(shù)據(jù)視圖時(shí)，我們的應(yīng)用便可以切換到從新的數(shù)據(jù)視圖中讀取。
4. 停止舊版本的作業(yè)實(shí)例，并刪除舊的數(shù)據(jù)視圖。

與 Lambda 架構(gòu)不同的是，Kappa 架構(gòu)去掉了批處理層這一體系結(jié)構(gòu)，而只保留了速度層。 你只需要在業(yè)務(wù)邏輯改變又或者是代碼更改的時(shí)候進(jìn)行數(shù)據(jù)的重新處理。

當(dāng)然了，也可以在上面講到的步驟中做一些優(yōu)化。 例如不執(zhí)行第 4 步，也就是不刪除舊的數(shù)據(jù)視圖。這樣的好處是當(dāng)你發(fā)現(xiàn)代碼邏輯出錯(cuò)時(shí)可以及時(shí)回滾（Roll Back）到上一個(gè)版本的數(shù)據(jù)視圖中去。又或者是你想在服務(wù)層提供 A/B 測(cè)試，保留多個(gè)數(shù)據(jù)視圖版本將有助于你進(jìn)行 A/B 測(cè)試。

Lambda 架構(gòu) vs Kappa 架構(gòu)

Lambda架構(gòu)和Kappa架構(gòu)的區(qū)別可以通過(guò)下表進(jìn)行對(duì)比說(shuō)明:

總結(jié)來(lái)說(shuō):

Lambda架構(gòu)通過(guò)批處理層和速度層的組合，兼顧了低延遲和復(fù)雜分析，但系統(tǒng)較復(fù)雜，存在數(shù)據(jù)冗余和延遲不一致問(wèn)題。

Kappa架構(gòu)只通過(guò)流式系統(tǒng)實(shí)現(xiàn)所有處理，簡(jiǎn)化了架構(gòu)，但歷史數(shù)據(jù)分析相對(duì)復(fù)雜，需要流式系統(tǒng)保證精確一次語(yǔ)義。

兩者都有各自的優(yōu)缺點(diǎn)，需要根據(jù)具體場(chǎng)景進(jìn)行技術(shù)選型和設(shè)計(jì)權(quán)衡。

Kappa 架構(gòu)變種

Kappa-S

Kappa-S架構(gòu)是在Kappa架構(gòu)的基礎(chǔ)上進(jìn)行的優(yōu)化和改進(jìn)。

Kappa架構(gòu)通過(guò)單個(gè)流式處理系統(tǒng)實(shí)現(xiàn)低延遲的實(shí)時(shí)計(jì)算以及歷史數(shù)據(jù)的處理。

但原始的Kappa架構(gòu)依然存在一些問(wèn)題:

1. 歷史數(shù)據(jù)的處理還是相對(duì)復(fù)雜，不如Lambda架構(gòu)中的批處理系統(tǒng)。
2. 單個(gè)流式系統(tǒng)需要承擔(dān)全部數(shù)據(jù)的處理，面臨較大的壓力。
3. 流式系統(tǒng)需要保證精確一次語(yǔ)義，實(shí)現(xiàn)較為復(fù)雜。

為了解決這些問(wèn)題，Jay Kreps等人提出了Kappa-S架構(gòu)。該架構(gòu)在Kappa架構(gòu)的基礎(chǔ)上，引入了Stream-Serving層。

Kappa-S架構(gòu)包含以下組件:

1. Stream層:實(shí)時(shí)流式處理層。
2. Serving層:查詢(xún)服務(wù)層。
3. Stream-Serving層:用來(lái)預(yù)計(jì)算并服務(wù)歷史數(shù)據(jù)的查詢(xún)，減輕Stream負(fù)載。

通過(guò)引入Stream-Serving層針對(duì)歷史數(shù)據(jù)進(jìn)行預(yù)計(jì)算，Kappa-S架構(gòu)減輕了流式處理的壓力，使歷史數(shù)據(jù)的查詢(xún)和分析更加簡(jiǎn)單，同時(shí)也避免了流式系統(tǒng)需要提供精確一次語(yǔ)義的復(fù)雜性?？梢钥醋魇荎appa架構(gòu)和Lambda架構(gòu)的折中方案。

Kappa-Lambda

Kappa-Lambda架構(gòu)是在Kappa架構(gòu)的基礎(chǔ)上，引入了Lambda架構(gòu)中的批處理層組件，形成的一種混合架構(gòu)。

Kappa-Lambda架構(gòu)包含以下組件:

• Stream層:實(shí)時(shí)流式處理層。
• Serving層:查詢(xún)服務(wù)層。
• Batch層:批處理層，用于復(fù)雜的歷史數(shù)據(jù)分析。
• Speed層:速度層，用于低延遲的實(shí)時(shí)計(jì)算。

其工作流程如下:

1. Stream層接收實(shí)時(shí)數(shù)據(jù)，進(jìn)行實(shí)時(shí)計(jì)算。
2. Speed層從Stream層獲取實(shí)時(shí)結(jié)果，進(jìn)行低延遲的實(shí)時(shí)分析。
3. Serving層查詢(xún)時(shí)，實(shí)時(shí)部分從Speed層獲取，歷史部分從Batch層獲取。
4. Batch層定期從Stream層獲取數(shù)據(jù)，進(jìn)行復(fù)雜的歷史數(shù)據(jù)分析和處理。

可以看出，Kappa-Lambda架構(gòu)相比Kappa架構(gòu)，引入了批處理層組件，以便進(jìn)行復(fù)雜的歷史數(shù)據(jù)分析。同時(shí)保留了Speed層，進(jìn)行低延遲的實(shí)時(shí)計(jì)算。

這種設(shè)計(jì)兼顧了Kappa架構(gòu)的簡(jiǎn)單性，以及Lambda架構(gòu)在復(fù)雜分析上的優(yōu)勢(shì)。既能實(shí)時(shí)處理，也能進(jìn)行復(fù)雜的批處理。

Kappa-DB

Kappa-DB架構(gòu)是在Kappa架構(gòu)的基礎(chǔ)上，通過(guò)引入數(shù)據(jù)庫(kù)組件，實(shí)現(xiàn)流式數(shù)據(jù)到數(shù)據(jù)庫(kù)的持久化保存，形成的一種架構(gòu)設(shè)計(jì)。

Kappa-DB架構(gòu)通常包含以下組件:

• Stream層:實(shí)時(shí)流式處理層。
• Serving層:查詢(xún)服務(wù)層。
• Database:數(shù)據(jù)庫(kù)層，用于存儲(chǔ)流式處理的結(jié)果數(shù)據(jù)。

其工作流程如下:

• Stream層接收實(shí)時(shí)數(shù)據(jù)，進(jìn)行實(shí)時(shí)處理。
• Stream層將處理結(jié)果寫(xiě)入數(shù)據(jù)庫(kù)進(jìn)行持久化存儲(chǔ)。
• Serving層接收查詢(xún)請(qǐng)求，從數(shù)據(jù)庫(kù)中讀取數(shù)據(jù)，進(jìn)行計(jì)算后返回結(jié)果。
• 定期進(jìn)行歸檔或聚合，避免數(shù)據(jù)庫(kù)數(shù)據(jù)過(guò)多。

引入數(shù)據(jù)庫(kù)組件的優(yōu)點(diǎn)包括:

• 通過(guò)數(shù)據(jù)庫(kù)持久化存儲(chǔ)，避免數(shù)據(jù)丟失。
• 簡(jiǎn)化歷史數(shù)據(jù)查詢(xún)，數(shù)據(jù)庫(kù)可以進(jìn)行索引優(yōu)化。
• 可以通過(guò)歸檔降低存儲(chǔ)成本。
• 可以重用數(shù)據(jù)庫(kù)的計(jì)算能力，減少流計(jì)算開(kāi)銷(xiāo)。

需要注意數(shù)據(jù)庫(kù)寫(xiě)入成為系統(tǒng)瓶頸的問(wèn)題，通常要控制寫(xiě)入數(shù)據(jù)庫(kù)的頻率，進(jìn)行歸檔優(yōu)化等。

總體上，Kappa-DB架構(gòu)通過(guò)融合流式處理和數(shù)據(jù)庫(kù)，實(shí)現(xiàn)了數(shù)據(jù)的持久化存儲(chǔ)，同時(shí)也繼承了Kappa架構(gòu)的優(yōu)點(diǎn)。

Kappa 系列架構(gòu)對(duì)比

綜合來(lái)看:

• Kappa架構(gòu)簡(jiǎn)單但歷史處理復(fù)雜
• Kappa-S通過(guò)預(yù)計(jì)算層減輕實(shí)時(shí)流量壓力，但增加了系統(tǒng)復(fù)雜度
• Kappa-Lambda引入批處理能力，但架構(gòu)非常復(fù)雜
• Kappa-DB使用數(shù)據(jù)庫(kù)實(shí)現(xiàn)持久化，但可能面臨DB瓶頸

需要根據(jù)具體業(yè)務(wù)需求，平衡實(shí)時(shí)處理、歷史處理、一致性、范疇等方面的需求，選擇適合的架構(gòu)。

流批一體

流批一體(Unified Batch and Streaming Processing)是指將流式處理和批處理統(tǒng)一在一個(gè)運(yùn)行時(shí)框架中，進(jìn)行一體化的處理。

在流批一體架構(gòu)中，實(shí)時(shí)數(shù)據(jù)流和歷史數(shù)據(jù)批量處理可以使用同一組數(shù)據(jù)處理工具和技術(shù)，例如Apache Spark、Apache Flink等。流批一體架構(gòu)可以將實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)進(jìn)行統(tǒng)一的處理和分析，以簡(jiǎn)化數(shù)據(jù)處理的復(fù)雜性和提高數(shù)據(jù)處理的效率。

在流批一體架構(gòu)中，實(shí)時(shí)數(shù)據(jù)流和歷史數(shù)據(jù)批量處理可以使用同一套數(shù)據(jù)處理代碼。這意味著，數(shù)據(jù)處理人員可以使用同一種編程語(yǔ)言、框架和工具來(lái)處理實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)。這樣可以減少數(shù)據(jù)處理人員的學(xué)習(xí)和使用成本，并提高數(shù)據(jù)處理的效率和精度。

流批一體架構(gòu)還可以將實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)存儲(chǔ)在同一套數(shù)據(jù)存儲(chǔ)系統(tǒng)中，例如Apache HBase、Apache Cassandra等。這樣可以簡(jiǎn)化數(shù)據(jù)存儲(chǔ)的管理和維護(hù)，并提高數(shù)據(jù)的可用性和可靠性。

總之，流批一體是一種將流數(shù)據(jù)處理和批數(shù)據(jù)處理整合在一起的數(shù)據(jù)處理架構(gòu)，它可以簡(jiǎn)化數(shù)據(jù)處理的復(fù)雜性和提高數(shù)據(jù)處理的效率。流批一體架構(gòu)可以在實(shí)時(shí)數(shù)據(jù)處理和歷史數(shù)據(jù)批量處理之間實(shí)現(xiàn)無(wú)縫切換，以滿(mǎn)足不同的數(shù)據(jù)處理需求。

誕生背景

流批一體的誕生主要有以下背景:

1. Lambda架構(gòu)的復(fù)雜性問(wèn)題：Lambda架構(gòu)需要同時(shí)開(kāi)發(fā)和維護(hù)批處理系統(tǒng)和流式處理系統(tǒng)，系統(tǒng)復(fù)雜，開(kāi)發(fā)和運(yùn)維困難。
2. 實(shí)時(shí)計(jì)算和歷史計(jì)算的需求融合：越來(lái)越多的應(yīng)用同時(shí)需要實(shí)時(shí)數(shù)據(jù)處理和歷史數(shù)據(jù)分析，需要一個(gè)統(tǒng)一的框架。
3. 流式處理系統(tǒng)的發(fā)展成熟：流式處理系統(tǒng)的計(jì)算模型和性能已經(jīng)發(fā)展成熟，可以用于替代傳統(tǒng)的批處理任務(wù)。
4. 微批流式處理技術(shù)的出現(xiàn)：Spark Streaming等系統(tǒng)采用微批流式處理，簡(jiǎn)化了流式處理的事件時(shí)間管理。
5. 云原生技術(shù)的興起：Kubernetes等技術(shù)為流批一體提供了更好的資源調(diào)度和技術(shù)支撐。

綜上，流批一體可以看作是對(duì)Lambda架構(gòu)的簡(jiǎn)化，也是實(shí)時(shí)處理和批處理融合的產(chǎn)物，以應(yīng)對(duì)實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)雙需求的場(chǎng)景。

Dataflow 模型

DataFlow 模型是一種用于描述數(shù)據(jù)處理流程的計(jì)算模型，它描述了數(shù)據(jù)從源頭到目的地的流動(dòng)過(guò)程，并指定了數(shù)據(jù)處理的方式和順序。

DataFlow 模型常用于并行計(jì)算和數(shù)據(jù)流處理領(lǐng)域，例如流處理框架 Apache Flink 就是基于 DataFlow 模型實(shí)現(xiàn)的。

在 DataFlow 模型中，數(shù)據(jù)被視為流動(dòng)的實(shí)體，數(shù)據(jù)處理被視為一系列的數(shù)據(jù)轉(zhuǎn)換操作。數(shù)據(jù)可以從一個(gè)或多個(gè)輸入源中流入數(shù)據(jù)處理系統(tǒng)，經(jīng)過(guò)一系列的處理操作，最終輸出到一個(gè)或多個(gè)輸出目的地中。在數(shù)據(jù)處理的過(guò)程中，數(shù)據(jù)可以被分割成多個(gè)數(shù)據(jù)塊，這些數(shù)據(jù)塊可以并行處理，以提高數(shù)據(jù)處理的效率。

DataFlow 模型中的數(shù)據(jù)處理操作通常被描述為有向圖中的節(jié)點(diǎn)，數(shù)據(jù)流動(dòng)則被描述為有向邊。每個(gè)節(jié)點(diǎn)可以執(zhí)行一些特定的數(shù)據(jù)處理操作，例如數(shù)據(jù)過(guò)濾、數(shù)據(jù)轉(zhuǎn)換、數(shù)據(jù)聚合等。節(jié)點(diǎn)之間的邊表示數(shù)據(jù)的流動(dòng)方向和數(shù)據(jù)處理順序。在 DataFlow 模型中，數(shù)據(jù)處理操作可以被組合成復(fù)雜的數(shù)據(jù)處理流程，以實(shí)現(xiàn)不同的數(shù)據(jù)處理需求。

總之，DataFlow 模型是一種用于描述數(shù)據(jù)處理流程的計(jì)算模型，它描述了數(shù)據(jù)從源頭到目的地的流動(dòng)過(guò)程，并指定了數(shù)據(jù)處理的方式和順序。DataFlow 模型常用于并行計(jì)算和數(shù)據(jù)流處理領(lǐng)域，例如流處理框架 Apache Flink 就是基于 DataFlow 模型實(shí)現(xiàn)的。

關(guān)于 Dataflow 模型的更多細(xì)節(jié)請(qǐng)參考我的博客——《DataFlow 模型是什么？》

誕生背景

Dataflow模型的主要誕生背景:

1. 大數(shù)據(jù)時(shí)代的數(shù)據(jù)規(guī)模爆炸，需要并行計(jì)算能力
2. 流式計(jì)算和批處理的需求融合
3. MapReduce模型的局限性：MapReduce模型對(duì)迭代計(jì)算和DAG支持不友好，而Dataflow模型通過(guò)Operator圖更適合表達(dá)復(fù)雜的數(shù)據(jù)處理流程。
4. 分布式資源管理與集群調(diào)度技術(shù)的進(jìn)步：YARN、Mesos、Kubernetes等技術(shù)為Dataflow模型提供了更好的運(yùn)行時(shí)支撐。
5. 內(nèi)存計(jì)算的發(fā)展：Spark等內(nèi)存計(jì)算框架更適合Dataflow模型。

綜上，Dataflow模型是對(duì)MapReduce模型的重要發(fā)展和延伸，可以更好地處理迭代、流式、DAG等復(fù)雜數(shù)據(jù)處理任務(wù)，在大數(shù)據(jù)時(shí)代得到廣泛應(yīng)用。

關(guān)于 MapReduce 模型請(qǐng)參考我的博客——《MapReduce 編程模型到底是怎樣的？》

Dataflow 模型全流程

DataFlow 模型的全流程可以分為以下幾個(gè)步驟：

1. 數(shù)據(jù)源輸入：數(shù)據(jù)源可以是各種類(lèi)型的數(shù)據(jù)，例如文件、數(shù)據(jù)庫(kù)、消息隊(duì)列等。在 DataFlow 模型中，數(shù)據(jù)源被視為數(shù)據(jù)處理流程的起點(diǎn)，數(shù)據(jù)從數(shù)據(jù)源中流入數(shù)據(jù)處理系統(tǒng)。
2. 數(shù)據(jù)切割：在 DataFlow 模型中，數(shù)據(jù)可以被分割成多個(gè)數(shù)據(jù)塊，這些數(shù)據(jù)塊可以并行處理，以提高數(shù)據(jù)處理的效率。數(shù)據(jù)切割可以根據(jù)數(shù)據(jù)的大小、時(shí)間戳、鍵值等方式進(jìn)行，以便更好地實(shí)現(xiàn)數(shù)據(jù)并行處理。
3. 數(shù)據(jù)轉(zhuǎn)換：在 DataFlow 模型中，數(shù)據(jù)可以經(jīng)過(guò)一系列的數(shù)據(jù)轉(zhuǎn)換操作，例如數(shù)據(jù)清洗、數(shù)據(jù)過(guò)濾、數(shù)據(jù)聚合等。數(shù)據(jù)轉(zhuǎn)換操作被描述為有向圖中的節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)可以執(zhí)行一些特定的數(shù)據(jù)處理操作，節(jié)點(diǎn)之間的邊表示數(shù)據(jù)的流動(dòng)方向和數(shù)據(jù)處理順序。
4. 數(shù)據(jù)聚合：在 DataFlow 模型中，數(shù)據(jù)可以經(jīng)過(guò)多個(gè)數(shù)據(jù)轉(zhuǎn)換操作后被聚合起來(lái)，以便更好地實(shí)現(xiàn)數(shù)據(jù)分析和挖掘。
5. 數(shù)據(jù)輸出：在 DataFlow 模型中，數(shù)據(jù)輸出可以是各種類(lèi)型的數(shù)據(jù)目的地，例如文件、數(shù)據(jù)庫(kù)、消息隊(duì)列等。數(shù)據(jù)輸出被視為數(shù)據(jù)處理流程的終點(diǎn)，數(shù)據(jù)從數(shù)據(jù)處理系統(tǒng)中輸出到數(shù)據(jù)目的地中。

在 DataFlow 模型中，數(shù)據(jù)處理操作可以被組合成復(fù)雜的數(shù)據(jù)處理流程，以實(shí)現(xiàn)不同的數(shù)據(jù)處理需求。數(shù)據(jù)處理流程可以使用各種數(shù)據(jù)處理框架和工具來(lái)實(shí)現(xiàn)，例如 Apache Flink、Apache Beam、Apache Kafka 等。

Dataflow 模型怎樣保證數(shù)據(jù)的準(zhǔn)確性和一致性

DataFlow 模型可以通過(guò)以下方式來(lái)保證數(shù)據(jù)的準(zhǔn)確性和一致性：

1. 數(shù)據(jù)校驗(yàn)：在數(shù)據(jù)流入數(shù)據(jù)處理系統(tǒng)之前，可以進(jìn)行數(shù)據(jù)校驗(yàn)，例如數(shù)據(jù)格式、數(shù)據(jù)類(lèi)型、數(shù)據(jù)范圍等。這可以保證數(shù)據(jù)的準(zhǔn)確性和完整性。
2. 數(shù)據(jù)清洗：在數(shù)據(jù)處理過(guò)程中，可以進(jìn)行數(shù)據(jù)清洗，例如去除重復(fù)數(shù)據(jù)、填充缺失數(shù)據(jù)等。這可以保證數(shù)據(jù)的一致性和準(zhǔn)確性。
3. 事務(wù)處理：在數(shù)據(jù)處理過(guò)程中，可以使用事務(wù)機(jī)制來(lái)確保數(shù)據(jù)的一致性。例如，如果一個(gè)節(jié)點(diǎn)的數(shù)據(jù)處理失敗，整個(gè)數(shù)據(jù)處理流程可以回滾到之前的狀態(tài)，以保證數(shù)據(jù)的一致性。
4. 數(shù)據(jù)分區(qū)：在數(shù)據(jù)處理過(guò)程中，可以將數(shù)據(jù)分成多個(gè)數(shù)據(jù)塊，每個(gè)數(shù)據(jù)塊可以并行處理。這可以提高數(shù)據(jù)處理的效率，同時(shí)也可以避免數(shù)據(jù)競(jìng)爭(zhēng)和數(shù)據(jù)沖突，以保證數(shù)據(jù)的一致性。
5. 數(shù)據(jù)重試：在數(shù)據(jù)處理過(guò)程中，如果某個(gè)節(jié)點(diǎn)處理失敗，可以進(jìn)行數(shù)據(jù)重試，直到數(shù)據(jù)處理成功。這可以保證數(shù)據(jù)的完整性和準(zhǔn)確性。

實(shí)時(shí)數(shù)倉(cāng)

實(shí)時(shí)數(shù)倉(cāng)是一種現(xiàn)代化的數(shù)據(jù)倉(cāng)庫(kù)，具有大數(shù)據(jù)規(guī)模的小數(shù)據(jù)語(yǔ)義和性能。它可以處理實(shí)時(shí)數(shù)據(jù)、最新數(shù)據(jù)和歷史數(shù)據(jù)，并且能夠跨數(shù)據(jù)域進(jìn)行相關(guān)性分析。實(shí)時(shí)數(shù)倉(cāng)具有更快的數(shù)據(jù)到達(dá)和查詢(xún)速度，可以在集成且安全的平臺(tái)上完成所有功能。

實(shí)時(shí)數(shù)倉(cāng)的優(yōu)勢(shì)包括更快的決策、數(shù)據(jù)民主化、個(gè)性化的客戶(hù)體驗(yàn)、提高業(yè)務(wù)敏捷性和解鎖新的業(yè)務(wù)用例。然而，實(shí)時(shí)數(shù)倉(cāng)也面臨著ETL性能和復(fù)雜實(shí)時(shí)計(jì)算場(chǎng)景等挑戰(zhàn)。

典型的實(shí)時(shí)數(shù)倉(cāng)架構(gòu)包括數(shù)據(jù)收集層、數(shù)據(jù)存儲(chǔ)層、實(shí)時(shí)計(jì)算層和實(shí)時(shí)應(yīng)用層。數(shù)據(jù)收集層負(fù)責(zé)接收和傳輸數(shù)據(jù)，數(shù)據(jù)存儲(chǔ)層用于實(shí)時(shí)數(shù)據(jù)存儲(chǔ)，實(shí)時(shí)計(jì)算層用于實(shí)時(shí)計(jì)算和分析，實(shí)時(shí)應(yīng)用層用于數(shù)據(jù)分析和挖掘。

實(shí)時(shí)數(shù)倉(cāng)可以應(yīng)用于實(shí)時(shí)OLAP分析、實(shí)時(shí)數(shù)據(jù)看板、實(shí)時(shí)業(yè)務(wù)監(jiān)控和實(shí)時(shí)數(shù)據(jù)接口服務(wù)等場(chǎng)景。其技術(shù)實(shí)現(xiàn)通常包括消息總線(xiàn)、實(shí)時(shí)存儲(chǔ)、流處理和分析以及應(yīng)用層。

常用的實(shí)時(shí)數(shù)倉(cāng)技術(shù)包括Apache Kafka、Apache Druid、Apache Spark、Hadoop、TiDB等，具體選擇取決于需求和偏好。

關(guān)于實(shí)時(shí)數(shù)倉(cāng)的更多細(xì)節(jié)請(qǐng)參考我的博客——《實(shí)時(shí)數(shù)倉(cāng)詳解》

誕生背景

實(shí)時(shí)數(shù)倉(cāng)的主要誕生背景有:

1. 對(duì)實(shí)時(shí)數(shù)據(jù)分析需求的增長(zhǎng)：越來(lái)越多的企業(yè)希望能夠立即分析操作數(shù)據(jù)，以便及時(shí)做出決策。
2. 傳統(tǒng)數(shù)倉(cāng)延遲大的問(wèn)題：傳統(tǒng)的數(shù)倉(cāng)以批量方式定期更新，無(wú)法滿(mǎn)足對(duì)實(shí)時(shí)數(shù)據(jù)的分析需要。
3. 流式計(jì)算技術(shù)的發(fā)展：大數(shù)據(jù)技術(shù)使得流式數(shù)據(jù)的采集、傳輸和計(jì)算成為可能。
4. 內(nèi)存計(jì)算的進(jìn)步：Spark等內(nèi)存計(jì)算技術(shù)使得內(nèi)存級(jí)的交互式分析成為可能。
5. 對(duì)用戶(hù)體驗(yàn)的提高要求：用戶(hù)希望立即獲取分析見(jiàn)解，不能等待傳統(tǒng)數(shù)倉(cāng)的延遲。
6. 云計(jì)算技術(shù)的進(jìn)步：云計(jì)算提供了實(shí)時(shí)數(shù)倉(cāng)彈性擴(kuò)展的能力。

架構(gòu)

實(shí)時(shí)數(shù)倉(cāng)通常具有四個(gè)組件：數(shù)據(jù)收集層、數(shù)據(jù)存儲(chǔ)層、實(shí)時(shí)計(jì)算層和實(shí)時(shí)應(yīng)用層。這些組件協(xié)同工作，以便在事件發(fā)生后立即或短時(shí)間內(nèi)支持事件數(shù)據(jù)的處理和分析。所有數(shù)據(jù)處理階段（數(shù)據(jù)攝取、豐富、分析、基于 AI/ML 的分析）都是連續(xù)的，具有最小延遲，并且能夠?qū)崿F(xiàn)實(shí)時(shí)報(bào)告和即席分析。

一個(gè)比較典型的實(shí)時(shí)數(shù)倉(cāng)架構(gòu)如下所示：

• 數(shù)據(jù)收集層：第三方服務(wù)和協(xié)同系統(tǒng)通過(guò) Apache Kafka/Apache Nifi 之類(lèi)的消息總線(xiàn)傳輸數(shù)據(jù)到實(shí)時(shí)數(shù)倉(cāng)；第三方數(shù)據(jù)源通過(guò)調(diào)用實(shí)時(shí)數(shù)倉(cāng)的 API；物聯(lián)網(wǎng)系統(tǒng)通過(guò)直接連接并推送數(shù)據(jù)的方法傳輸數(shù)據(jù)
• 數(shù)據(jù)存儲(chǔ)層：使用 Apache Kudu/Apache Druid/Amazon Redshift 來(lái)進(jìn)行實(shí)時(shí)數(shù)據(jù)存儲(chǔ)
• 實(shí)時(shí)計(jì)算層：使用 Apache Spark/Amazon Kinesis/Hadoop 來(lái)進(jìn)行實(shí)時(shí)計(jì)算和分析
• 實(shí)時(shí)應(yīng)用層：使用 AI 和機(jī)器學(xué)習(xí)技術(shù)對(duì)數(shù)據(jù)進(jìn)行分析和挖掘，使用 SQL Server/Oracle BI 來(lái)支持查詢(xún)、報(bào)告和即席查詢(xún)；使用 Apache Impala 來(lái)支持實(shí)時(shí)報(bào)告和告警。

對(duì)比

總結(jié)

本文詳細(xì)介紹了幾種主要的大數(shù)據(jù)處理架構(gòu):

• Lambda架構(gòu)：組合批處理層和速度層，兼顧低延遲和復(fù)雜分析，但系統(tǒng)較復(fù)雜，存在數(shù)據(jù)冗余和延遲不一致問(wèn)題。Lambda架構(gòu)的批處理層可以基于Hadoop、Spark等技術(shù)來(lái)實(shí)現(xiàn)，速度層可以基于Storm、Flink等流式處理系統(tǒng)來(lái)實(shí)現(xiàn)。服務(wù)層需要實(shí)現(xiàn)查詢(xún)接口，可以使用REST API。Lambda架構(gòu)適合大數(shù)據(jù)場(chǎng)景，但維護(hù)批處理層和速度層的重復(fù)開(kāi)發(fā)較為麻煩。
• Kappa架構(gòu)：僅通過(guò)流式處理實(shí)現(xiàn)所有處理，簡(jiǎn)化了架構(gòu)，但歷史數(shù)據(jù)分析相對(duì)復(fù)雜。Kappa架構(gòu)還有幾種變種，如Kappa-S、Kappa-Lambda、Kappa-DB。Kappa架構(gòu)中的流式處理層可以基于Flink、Spark Streaming等來(lái)實(shí)現(xiàn)，需要實(shí)現(xiàn)Exactly-once語(yǔ)義。服務(wù)層同樣需要查詢(xún)接口。Kappa架構(gòu)簡(jiǎn)單高效，但對(duì)實(shí)時(shí)流有較高要求，歷史數(shù)據(jù)處理不如Lambda架構(gòu)方便。
• 流批一體：將流式處理和批處理統(tǒng)一在一個(gè)運(yùn)行時(shí)框架中，可以簡(jiǎn)化處理，提高效率。流批一體需要統(tǒng)一運(yùn)行時(shí)框架，如Flink、Spark等，可以通過(guò)DataStream和DataSet在流式處理和批處理之間無(wú)縫切換。計(jì)算模型也需要統(tǒng)一，如Dataflow模型。流批一體簡(jiǎn)化系統(tǒng)，但實(shí)時(shí)性不如純流式處理。
• Dataflow模型：將數(shù)據(jù)處理視為數(shù)據(jù)流經(jīng)轉(zhuǎn)換操作的流程，可以表達(dá)復(fù)雜的數(shù)據(jù)處理流程。Dataflow模型通常用有向圖表達(dá)，并基于并行運(yùn)行時(shí)框架實(shí)現(xiàn)，如Flink。需要解決數(shù)據(jù)一致性、容錯(cuò)等問(wèn)題。Dataflow模型可以靈活表示復(fù)雜處理流程。
• 實(shí)時(shí)數(shù)倉(cāng)：通過(guò)流式處理實(shí)現(xiàn)對(duì)實(shí)時(shí)數(shù)據(jù)的快速存儲(chǔ)和計(jì)算分析，滿(mǎn)足了對(duì)實(shí)時(shí)分析的需求。實(shí)時(shí)數(shù)倉(cāng)中的消息總線(xiàn)可以用Kafka實(shí)現(xiàn)，存儲(chǔ)系統(tǒng)可以使用HBase、Druid等，計(jì)算使用Spark Streaming、Flink。實(shí)時(shí)數(shù)倉(cāng)可以快速分析數(shù)據(jù)并實(shí)時(shí)更新，但對(duì)基礎(chǔ)設(shè)施要求較高。

總的來(lái)說(shuō)，大數(shù)據(jù)處理架構(gòu)的發(fā)展趨勢(shì)是實(shí)時(shí)性增強(qiáng)、處理統(tǒng)一簡(jiǎn)化、滿(mǎn)足復(fù)雜分析需求。需要根據(jù)具體業(yè)務(wù)場(chǎng)景需求選擇合適的架構(gòu)方案。未來(lái)可能是基于流式處理的架構(gòu)為主，同時(shí)引入批處理能力進(jìn)行復(fù)雜分析。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-612630.html

到了這里，關(guān)于大數(shù)據(jù)處理架構(gòu)詳解：Lambda架構(gòu)、Kappa架構(gòu)、流批一體、Dataflow模型、實(shí)時(shí)數(shù)倉(cāng)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！