首先我們來(lái)看看什么是Lambda架構(gòu)，Lambda演算在編程語(yǔ)言之中是一個(gè)編程范式，它遵循如下幾個(gè)特點(diǎn)：

1. 數(shù)據(jù)的不可變性，任何對(duì)于數(shù)據(jù)的操作是沒(méi)有副作用。
2. 數(shù)據(jù)的無(wú)依賴性，即對(duì)函數(shù)提供同樣的輸入，那么函數(shù)總是返回同樣的結(jié)果。
3. 函數(shù)是First Class，函數(shù)與其他數(shù)據(jù)類型一樣，處于平等地位，可以賦值給其他變量，也可以作為參數(shù)，傳入另一個(gè)函數(shù)，或者作為別的函數(shù)的返回值。

[[244455]]

來(lái)自Twitter的Nathan Marz，Marz認(rèn)為進(jìn)行計(jì)算處理的大數(shù)據(jù)框架的本質(zhì)邏輯與函數(shù)式編程的思路是不謀而合，所以Marz根據(jù)自己多年進(jìn)行分布式數(shù)據(jù)系統(tǒng)開(kāi)發(fā)的經(jīng)驗(yàn)總結(jié)提出了Lambda架構(gòu)。(Marz大神是AFS***項(xiàng)目Storm的作者，Storm作為一個(gè)優(yōu)秀的分布式流處理系統(tǒng))所以接下來(lái)我們來(lái)看看Marz所提出的Lambda架構(gòu)是怎么樣:

Lambda架構(gòu)說(shuō)起來(lái)也很簡(jiǎn)單，就是通過(guò)分布式系統(tǒng)的組件搭建，設(shè)計(jì)出一個(gè)具有魯棒性，可擴(kuò)展，低延時(shí)的分布式計(jì)算系統(tǒng)。之所以稱之為L(zhǎng)ambda架構(gòu)，就是它最為核心的點(diǎn)就是理由了數(shù)據(jù)處理過(guò)程之中的不可變性與無(wú)依賴性。下圖展現(xiàn)了一個(gè)典型的Lambda架構(gòu)的分層邏輯：

由上圖可以看到，一個(gè)典型的Lambda架構(gòu)的核心分為三個(gè)層次：Batch Layer，Speed Layer和Serving Layer。

• Batch Layer
• Speed Layer
• Serving Layer

我們來(lái)梳理一下他們是如何分工協(xié)助的：首先new data作為整個(gè)數(shù)據(jù)系統(tǒng)的數(shù)據(jù)源頭，Batch Layer作為數(shù)據(jù)的批處理層次對(duì)原始數(shù)據(jù)進(jìn)行加工與處理，并且將處理的數(shù)據(jù)結(jié)果的Batch View輸入到Serving Layer。(這里對(duì)應(yīng)的是全量數(shù)據(jù))

Speed Layer對(duì)于實(shí)時(shí)增加的數(shù)據(jù)進(jìn)行處理，生成對(duì)增量數(shù)據(jù)計(jì)算結(jié)果的Realtime Views。(這里對(duì)應(yīng)的是增量數(shù)據(jù))

最終用戶查詢是通過(guò)Batch View與Realtime View相結(jié)合的形式將最終結(jié)果呈現(xiàn)出來(lái)。

并且隨著時(shí)間的推移，Batch View的計(jì)算結(jié)果會(huì)逐漸替代Realtime View,而業(yè)務(wù)層可以低延遲的訪問(wèn)由Serving Layer提供的Batch View，也可以通過(guò)Realtime View實(shí)時(shí)反饋業(yè)務(wù)結(jié)果。

我們可以看到在Lambda架構(gòu)之中，所有的數(shù)據(jù)都需要滿足滿足不可變性與無(wú)依賴性，出現(xiàn)任何數(shù)據(jù)問(wèn)題時(shí)，(如出錯(cuò)，丟失等)只需要重新跑一遍算法就可以恢復(fù)所需的數(shù)據(jù)了。

下面筆者利用一個(gè)業(yè)務(wù)場(chǎng)景簡(jiǎn)單闡述一下Lambda模式，如下的業(yè)務(wù)場(chǎng)景只是基于筆者對(duì)電商推薦的理解所表述的，對(duì)應(yīng)電商未必實(shí)際之中就是采取筆者所闡述的模式：

1：下圖是筆者訪問(wèn)x寶網(wǎng)首頁(yè)所展示的廣告頁(yè)面：

對(duì)于這個(gè)推薦數(shù)據(jù)，可以理解為通過(guò)Batch Layer對(duì)我個(gè)人歷史數(shù)據(jù)進(jìn)行處理之后得出的Batch View推薦。(例如跑Spark Mllib或是Hadoop Mahout對(duì)歷史數(shù)據(jù)進(jìn)行分析推薦的結(jié)果,跑這類算法通常費(fèi)時(shí)費(fèi)力，可以通過(guò)提前計(jì)算的方式存入MySQL等，后續(xù)用戶訪問(wèn)時(shí)可以直接調(diào)用)

2：接下來(lái)筆者在x寶網(wǎng)搜索了MacBook pro和ThinkPad x207，對(duì)于實(shí)時(shí)搜索的數(shù)據(jù)，可以作為流數(shù)據(jù)實(shí)時(shí)的通過(guò)Speed Layer進(jìn)行處理。(例如Storm這樣的流處理器)

3: 筆者切換回到x寶網(wǎng)的首頁(yè)，發(fā)現(xiàn)多了一個(gè)推薦廣告項(xiàng)目：Dell 8代CPU專業(yè)級(jí)顯卡，曬單還送愛(ài)奇藝半年卡。顯然實(shí)時(shí)流的Realtime View與Batch View共同組成的x寶網(wǎng)的推薦首頁(yè)內(nèi)容，很好的反饋了用戶的實(shí)時(shí)需求：

Lambda架構(gòu)結(jié)合了實(shí)時(shí)處理與批處理的結(jié)果，很好的反饋了查詢需求，并且在速度和可靠性之間求取了平衡，具有足夠的擴(kuò)展性。在Lambda架構(gòu)之中，所有的查詢都可以定位成一個(gè)函數(shù)：

而Lambda架構(gòu)將數(shù)據(jù)和計(jì)算系統(tǒng)進(jìn)行細(xì)分：

但是這種架構(gòu)同樣存在一些問(wèn)題：需要運(yùn)維兩套不同的計(jì)算系統(tǒng)，并且合并查詢結(jié)果，這一定程序上帶來(lái)了復(fù)雜性的增加

Lambda架構(gòu)誕生之后，來(lái)自Linkedln的技術(shù)主管Jay Kreps提出了一些質(zhì)疑，并在Lambda架構(gòu)之上提出自己的改進(jìn)版本，將其命名為Kappa架構(gòu)。

Lambda架構(gòu)最麻煩的問(wèn)題就在于：新的邏輯需要兩次編碼，并且在兩個(gè)系統(tǒng)中運(yùn)行和調(diào)試代碼，需要多運(yùn)維一個(gè)額外的系統(tǒng)。所以Kreps認(rèn)為L(zhǎng)ambda架構(gòu)試圖在兩個(gè)不同編程范式的頂部建立一個(gè)抽象層是非常難的。

而Kappa架構(gòu)嘗試通過(guò)一個(gè)流處理系統(tǒng)來(lái)處理上述兩種邏輯，我們來(lái)看看Kappa架構(gòu)是怎么樣去設(shè)計(jì)的：

Kappa架構(gòu)通過(guò)流處理系統(tǒng)的并行機(jī)制，來(lái)提高并行以實(shí)現(xiàn)重復(fù)處理。但是很多人會(huì)覺(jué)得流式處理對(duì)于歷史數(shù)據(jù)的高吞吐量會(huì)力不從心，這里Kreps給出的解決方案是：僅僅重復(fù)處理的完整日志數(shù)據(jù)。加入需要重復(fù)處理30天數(shù)據(jù)，就利用Kafka保留到30天。

所以這里是開(kāi)辟另個(gè)流式處理來(lái)處理新的數(shù)據(jù)，輸出數(shù)據(jù)是直接輸出到一個(gè)新的輸出表。當(dāng)這第二個(gè)流式處理完成之后，切換到新的表中進(jìn)行讀取，然后停止舊的流式處理，再刪除舊的輸出表。

同樣的，筆者上文舉的例子，同樣也能通過(guò)Kappa架構(gòu)來(lái)實(shí)現(xiàn)購(gòu)物的廣告展示。Kappa架構(gòu)最為核心的是通過(guò)一個(gè)范式解決需要共同解決的問(wèn)題。同時(shí)不需要引入額外計(jì)算系統(tǒng)進(jìn)行運(yùn)維。

到此為止，筆者也大致聊完兩種不同分布式計(jì)算系統(tǒng)的架構(gòu)。筆者認(rèn)為L(zhǎng)ambda架構(gòu)是一個(gè)優(yōu)秀的解決分布式計(jì)算的架構(gòu)，但需要處理運(yùn)維不同的大數(shù)據(jù)系統(tǒng)，并且額外編碼邏輯，對(duì)于開(kāi)發(fā)者與運(yùn)維人員都是一個(gè)較大的考驗(yàn)。而Kappa架構(gòu)簡(jiǎn)化了這個(gè)模型，但是對(duì)于數(shù)據(jù)處理總歸很難拿出重型的批處理做一個(gè)完整數(shù)據(jù)計(jì)算，所以計(jì)算結(jié)果的準(zhǔn)確性是有所限縮的。(也就是對(duì)于業(yè)務(wù)場(chǎng)景是挑剔的，我想也沒(méi)有一種架構(gòu)是解決問(wèn)題的銀彈，之間的取舍需要我們開(kāi)發(fā)人員進(jìn)行完整的評(píng)估～～)

而Spark能夠通過(guò)一個(gè)計(jì)算框架同時(shí)解決批處理計(jì)算與流計(jì)算的問(wèn)題，是很值得開(kāi)發(fā)與運(yùn)維人員所關(guān)注的.......