在大數(shù)據(jù)技術(shù)發(fā)展早期，離線計(jì)算（批處理）作為唯一的大數(shù)據(jù)處理技術(shù)，很快在各個(gè)場(chǎng)景下取得了驚人成果，吸引了一大批優(yōu)秀的科學(xué)家和工程師，這些因素的疊加使大數(shù)據(jù)技術(shù)快速成熟，形成了以HDFS+YARN+Spark為格局的Hadoop生態(tài)體系。

同時(shí)，離線計(jì)算也成為了大數(shù)據(jù)的主流技術(shù)，但在由Hadoop構(gòu)筑的離線計(jì)算大廈上空，卻也飄著幾朵烏云，其中一朵就是高延遲。

Hadoop在設(shè)計(jì)之初便確定了架構(gòu)目標(biāo)：高吞吐、高容錯(cuò)、易擴(kuò)展。而高吞吐和低延遲又在一定程度上對(duì)立，因此早期Hadoop在架構(gòu)上就決定了其高延遲的缺陷，這直接限制了離線計(jì)算的使用場(chǎng)景。

而Storm、Spark Stream、Flink等大數(shù)據(jù)流處理框架的普及，對(duì)大數(shù)據(jù)技術(shù)早期的批處理計(jì)算邏輯帶來(lái)了顛覆，解決了高延遲的問(wèn)題，極大地?cái)U(kuò)充了大數(shù)據(jù)處理的使用場(chǎng)景，將大數(shù)據(jù)處理帶到了一個(gè)全新的實(shí)時(shí)計(jì)算時(shí)代。實(shí)時(shí)計(jì)算的普及再一次推動(dòng)著技術(shù)的進(jìn)步和人們認(rèn)知的提升，一些之前離線計(jì)算無(wú)法解決的低延遲場(chǎng)景開(kāi)始迅速被實(shí)時(shí)計(jì)算所解決。

然而，在實(shí)際情況中，受限于資源性能的因素，很多問(wèn)題往往需要輔助一些歷史數(shù)據(jù)，因此并不能直接通過(guò)實(shí)時(shí)計(jì)算完成。在這些場(chǎng)景下，就要求實(shí)時(shí)計(jì)算需要配合離線計(jì)算共同完成某些任務(wù)。在這樣的背景下，融合離線計(jì)算和實(shí)時(shí)計(jì)算的流處理框架應(yīng)運(yùn)而生。

上圖展示了一個(gè)Lambda架構(gòu)的示意圖，Lambda架構(gòu)分為實(shí)時(shí)計(jì)算層、離線計(jì)算層和在線服務(wù)層。其核心思想是事件在被實(shí)時(shí)計(jì)算引擎處理的同時(shí)寫(xiě)入到離線計(jì)算的存儲(chǔ)中，并于在線服務(wù)層中合并，得出最終結(jié)論。

2.1 離線計(jì)算層

離線處理層用于將事件持久化存儲(chǔ)到數(shù)倉(cāng)中，并對(duì)數(shù)倉(cāng)中的歷史數(shù)據(jù)進(jìn)行批量計(jì)算，將結(jié)果保存到分析數(shù)據(jù)庫(kù)中。分析數(shù)據(jù)庫(kù)不同于持久化的數(shù)倉(cāng)，需要配合實(shí)時(shí)計(jì)算，因此延時(shí)必須要低，所以最好選擇一些查詢速度快的分析型數(shù)據(jù)庫(kù)，例如Clickhouse、Elasticsearch等。

2.2 實(shí)時(shí)計(jì)算層

實(shí)時(shí)計(jì)算層在有些文獻(xiàn)中也被成為快速處理層，本質(zhì)上就是用于處理流式數(shù)據(jù)。這一層的主要職責(zé)是提供低延遲的實(shí)時(shí)計(jì)算能力，但由于其能力有限，一般用戶計(jì)算一個(gè)小的時(shí)間窗口的增量數(shù)據(jù)。得出的增量數(shù)據(jù)會(huì)被推送到分析數(shù)據(jù)庫(kù)中，或直接觸發(fā)在線服務(wù)層的業(yè)務(wù)，從而實(shí)現(xiàn)實(shí)時(shí)處理。

2.3 在線服務(wù)層

在線服務(wù)層可以是業(yè)務(wù)系統(tǒng)，主要承擔(dān)合并離線計(jì)算和實(shí)時(shí)計(jì)算結(jié)果并觸發(fā)下游業(yè)務(wù)動(dòng)作的職責(zé)。理論上離線計(jì)算得出的歷史數(shù)據(jù)+實(shí)時(shí)計(jì)算得出的增量數(shù)據(jù)=真實(shí)的實(shí)時(shí)數(shù)據(jù)。

2.4 案例：智能補(bǔ)貨

讀者們可以考慮一個(gè)門(mén)店零售中的智能配補(bǔ)貨場(chǎng)景：某連鎖品牌鞋店，新上了一批鞋子，需要實(shí)時(shí)監(jiān)測(cè)鞋子的銷售情況，并在合適時(shí)機(jī)觸發(fā)補(bǔ)貨機(jī)制。我們假設(shè)一條規(guī)則：某個(gè)尺碼庫(kù)存數(shù)量-過(guò)去三個(gè)月該尺碼日均銷量≤1時(shí)，觸發(fā)補(bǔ)貨。

在這個(gè)場(chǎng)景中，可以將計(jì)算分成實(shí)時(shí)和離線兩部分：

離線部分負(fù)責(zé)每天凌晨統(tǒng)計(jì)所有門(mén)店過(guò)去3個(gè)月的銷售情況，并將結(jié)果寫(xiě)入離線計(jì)算的分析數(shù)據(jù)庫(kù)中；

實(shí)時(shí)計(jì)算部分負(fù)責(zé)實(shí)時(shí)監(jiān)測(cè)當(dāng)天門(mén)店內(nèi)各個(gè)尺碼鞋子的庫(kù)存，將每個(gè)銷售事件推送到在線處理層；

在線處理層負(fù)責(zé)接收實(shí)時(shí)計(jì)算層的事件，并讀取離線計(jì)算的分析數(shù)據(jù)庫(kù)來(lái)判斷規(guī)則，最終確定是否需要觸發(fā)補(bǔ)貨機(jī)制。

這一案例的規(guī)則非常簡(jiǎn)單，真實(shí)世界中的規(guī)則會(huì)更復(fù)雜，但已經(jīng)能夠說(shuō)明Lambda架構(gòu)是如何解決需要同時(shí)依賴離線計(jì)算和實(shí)時(shí)計(jì)算問(wèn)題的場(chǎng)景。

2.5 Lambda架構(gòu)總結(jié)

Lambda架構(gòu)的核心邏輯在于，它認(rèn)為真實(shí)結(jié)果=增量結(jié)果+歷史結(jié)果。因此，其設(shè)計(jì)了三個(gè)獨(dú)立的計(jì)算層，分別用于計(jì)算增量結(jié)果、計(jì)算歷史結(jié)果、處理兩者的合并。這種架構(gòu)在很大程度上解決了當(dāng)數(shù)據(jù)量太多無(wú)法全部實(shí)時(shí)計(jì)算的缺陷。

同時(shí)，由于實(shí)時(shí)計(jì)算和離線計(jì)算使用兩套計(jì)算引擎，兩套計(jì)算引擎的API和抽象都不同，因此原始的Lambda架構(gòu)也存在著使用和維護(hù)難的問(wèn)題。

Kappa架構(gòu)本質(zhì)上是Lambda的一個(gè)變體,目的是為了解決Lambda架構(gòu)中兩套不同的計(jì)算引擎導(dǎo)致的使用和維護(hù)難的問(wèn)題。

如圖 2 Kappa架構(gòu)示意圖所示，Kappa架構(gòu)的核心是將兩套計(jì)算引擎合并成一套。換句話說(shuō)，要么使用批處理的計(jì)算引擎來(lái)計(jì)算流，要么使用流處理計(jì)算引擎來(lái)處理離線問(wèn)題。

圖 2 Kappa架構(gòu)示意圖的架構(gòu)可以簡(jiǎn)化成圖 3 Kappa架構(gòu)圖中的架構(gòu)。數(shù)據(jù)流進(jìn)入實(shí)時(shí)處理計(jì)算引擎，由實(shí)時(shí)計(jì)算引擎進(jìn)行運(yùn)算，將結(jié)果保存到分析數(shù)據(jù)庫(kù)中，同時(shí)將原始數(shù)據(jù)保存到數(shù)倉(cāng)中。在這一架構(gòu)中，數(shù)倉(cāng)可以使用對(duì)象存儲(chǔ)引擎來(lái)代替，保存所有歷史數(shù)據(jù)。同時(shí)，分析數(shù)據(jù)庫(kù)也變?yōu)榭蛇x。

3.1 極端的Kappa

Kappa架構(gòu)的實(shí)際使用中，也有部分企業(yè)使用了另一個(gè)更極端的Kappa架構(gòu)的變體。架構(gòu)圖如圖 4 Kappa架構(gòu)變體所示，該變體完全拋棄了數(shù)倉(cāng)，將所有數(shù)據(jù)都保存在Kafka中。當(dāng)需要計(jì)算歷史數(shù)據(jù)時(shí)，對(duì)Kafka進(jìn)行數(shù)據(jù)重放即可。

這種架構(gòu)完全拋棄了離線計(jì)算，能夠降低架構(gòu)復(fù)雜度和維護(hù)工作量，但并不適用于所有場(chǎng)景。主要原因在于，此架構(gòu)在計(jì)算歷史數(shù)據(jù)時(shí)需要對(duì)kafka數(shù)據(jù)進(jìn)行重放，而重放的計(jì)算效率比較低，會(huì)消耗大量的計(jì)算資源和時(shí)間。因此，若業(yè)務(wù)需要對(duì)歷史數(shù)據(jù)進(jìn)行計(jì)算，就不適合應(yīng)用本架構(gòu)。本架構(gòu)中對(duì)歷史數(shù)據(jù)的計(jì)算更多的用于偶發(fā)錯(cuò)誤的糾偏，而不適用于周期或頻繁的業(yè)務(wù)數(shù)據(jù)計(jì)算的場(chǎng)景中。

Kappa可以看成lambda架構(gòu)的變體。那么為何Lambda架構(gòu)提出時(shí)，沒(méi)有將兩套引擎合并成一個(gè)呢？

Lambda架構(gòu)是由Storm的發(fā)起者、Twitter工程師Nathan Marz提出。在實(shí)時(shí)處理的前期，只有Storm一套實(shí)時(shí)計(jì)算平臺(tái)，人們對(duì)實(shí)時(shí)計(jì)算的認(rèn)知還處在早期，大家普遍認(rèn)為實(shí)時(shí)計(jì)算和離線計(jì)算就是涇渭分明的兩種計(jì)算方式。直到Storm Trident的推出，第一次提出了微批的概念，將流計(jì)算認(rèn)為是批處理的特例，因此可以使用批處理的方式來(lái)處理流數(shù)據(jù)。而到了2013年Spark stream的推出，才真正將流處理和批處理都統(tǒng)一到了Spark中。

使用微批處理流數(shù)據(jù)的優(yōu)點(diǎn)顯而易見(jiàn)，可以將離線和實(shí)時(shí)統(tǒng)一到一套計(jì)算引擎中，這為Kappa的興起帶來(lái)了契機(jī)，但同時(shí)，微批處理的方式也造成了延遲高的缺陷。

而隨著人們認(rèn)知的提升，F(xiàn)link再次顛覆了人們的認(rèn)知。與微批思路的不同，F(xiàn)link將批處理視為流處理的特例，因此只需要實(shí)現(xiàn)流處理即可。于是，Flink橫空出世，更進(jìn)一步降低了實(shí)時(shí)處理的延遲。

縱觀流處理的歷史，不難發(fā)現(xiàn)人們認(rèn)知的改變帶來(lái)了技術(shù)的變革。在Lambda架構(gòu)提出的時(shí)候，流處理和批處理尚未統(tǒng)一，因此也不難理解為何當(dāng)時(shí)需要設(shè)計(jì)兩套計(jì)算引擎。當(dāng)然，人們認(rèn)知的改變也并不一定是先進(jìn)的，即使到現(xiàn)在，Lambda架構(gòu)依然有著非常大量的使用場(chǎng)景。造成這個(gè)現(xiàn)象的主要原因，在于技術(shù)的發(fā)展并沒(méi)有能夠?qū)崿F(xiàn)一套架構(gòu)處理所有問(wèn)題。目前的流處理技術(shù)，對(duì)于大數(shù)據(jù)量的歷史數(shù)據(jù)的處理，還是非常吃力的。

這就對(duì)架構(gòu)師提出了更高要求，一招鮮吃遍天并不適用于架構(gòu)領(lǐng)域。“沒(méi)有銀彈”這句話在流處理的歷史中也頻繁展現(xiàn)其威力，那么，作為架構(gòu)師我們應(yīng)該如何應(yīng)對(duì)這種挑戰(zhàn)呢？

我認(rèn)為，需要用洞察的視角透過(guò)現(xiàn)象看本質(zhì)。放到本文中，我們?cè)俅位氐轿恼麻_(kāi)始提到的：在由Hadoop構(gòu)筑的離線計(jì)算大廈上空，卻也飄著幾朵烏云，其中一朵就是高延遲讓我們用洞察的視角再來(lái)觀看整個(gè)流處理的歷史進(jìn)程。

4.1 低延遲與高吞吐的矛盾

文章開(kāi)頭提到了Hadoop設(shè)計(jì)之初的設(shè)計(jì)目標(biāo)是高吞吐、高容錯(cuò)、易擴(kuò)展。在數(shù)據(jù)處理領(lǐng)域，高吞吐和低延遲是矛盾的，因此Hadoop在設(shè)計(jì)之初就無(wú)法支持低延遲的實(shí)時(shí)處理場(chǎng)景。Storm被發(fā)明出來(lái)解決這個(gè)問(wèn)題，Storm通過(guò)全新的架構(gòu)設(shè)計(jì)支持了低延遲，但同時(shí)也沒(méi)有逃脫低延遲與高吞吐的矛盾，低吞吐也就成為了Storm的一個(gè)缺陷。

微批處理方案的出現(xiàn)，將流數(shù)據(jù)視為一系列非常小的批組成的集合，一次處理一個(gè)微批。這種方案在一定程度上改善了吞吐率。但也在實(shí)時(shí)性上帶來(lái)了一些問(wèn)題，因此其延遲相比較于Storm會(huì)變高。

Flink將批數(shù)據(jù)視為流數(shù)據(jù)的特例，因此其采用流處理引擎來(lái)處理批數(shù)據(jù)。這也為Flink帶來(lái)了低延遲的特性，并且由于其具備了處理批數(shù)據(jù)的能力，因此其吞吐量獲得了一定的提高。但看似實(shí)現(xiàn)了低延遲和高吞吐同時(shí)滿足的情況，這其實(shí)只是相比較而言的，面對(duì)真正的大數(shù)據(jù)量而言，F(xiàn)link依舊無(wú)能無(wú)力，因此在很多場(chǎng)景下依然需要Lambda架構(gòu)。

其實(shí)，無(wú)論是Lambda架構(gòu)還是Kappa架構(gòu)，本質(zhì)上就是低延遲和高吞吐之間的選擇。在有些場(chǎng)景下，追求低延遲并不需要高吞吐，這種場(chǎng)景就可以選擇Kappa架構(gòu)，其他場(chǎng)景就需要選擇Lambda架構(gòu)。

本文向讀者介紹了流處理產(chǎn)生的背景及兩種常用的流處理架構(gòu)，同時(shí)向讀者剖析了兩種架構(gòu)的本質(zhì)——低延遲和高吞吐的矛盾，這為讀者在未來(lái)選擇何種架構(gòu)提供了理論指導(dǎo)。

最后，Kappa架構(gòu)本質(zhì)上是一個(gè)流批一體架構(gòu)，關(guān)于流批一體更詳細(xì)的內(nèi)容，請(qǐng)關(guān)注下期專題文章。