1.Lambda架構(gòu)背景介紹

Lambda架構(gòu)是由Storm的作者Nathan Marz提出的一個實時大數(shù)據(jù)處理框架。Marz在Twitter工作期間開發(fā)了著名的實時大數(shù)據(jù)處理框架Storm，Lambda架構(gòu)是其根據(jù)多年進(jìn)行分布式大數(shù)據(jù)系統(tǒng)的經(jīng)驗總結(jié)提煉而成。

Lambda架構(gòu)的目標(biāo)是設(shè)計出一個能滿足實時大數(shù)據(jù)系統(tǒng)關(guān)鍵特性的架構(gòu)，包括有：高容錯、低延時和可擴(kuò)展等。Lambda架構(gòu)整合離線計算和實時計算，融合不可變性（Immunability），讀寫分離和復(fù)雜性隔離等一系列架構(gòu)原則，可集成Hadoop，Kafka，Storm，Spark，Hbase等各類大數(shù)據(jù)組件。

2.大數(shù)據(jù)系統(tǒng)的關(guān)鍵特性

Marz認(rèn)為大數(shù)據(jù)系統(tǒng)應(yīng)具有以下的關(guān)鍵特性：

• Robust and fault-tolerant（容錯性和魯棒性）：對大規(guī)模分布式系統(tǒng)來說，機(jī)器是不可靠的，可能會當(dāng)機(jī)，但是系統(tǒng)需要是健壯、行為正確的，即使是遇到機(jī)器錯誤。除了機(jī)器錯誤，人更可能會犯錯誤。在軟件開發(fā)中難免會有一些Bug，系統(tǒng)必須對有Bug的程序?qū)懭氲腻e誤數(shù)據(jù)有足夠的適應(yīng)能力，所以比機(jī)器容錯性更加重要的容錯性是人為操作容錯性。對于大規(guī)模的分布式系統(tǒng)來說，人和機(jī)器的錯誤每天都可能會發(fā)生，如何應(yīng)對人和機(jī)器的錯誤，讓系統(tǒng)能夠從錯誤中快速恢復(fù)尤其重要。
• Low latency reads and updates（低延時）：很多應(yīng)用對于讀和寫操作的延時要求非常高，要求對更新和查詢的響應(yīng)是低延時的。
• Scalable（橫向擴(kuò)容）：當(dāng)數(shù)據(jù)量/負(fù)載增大時，可擴(kuò)展性的系統(tǒng)通過增加更多的機(jī)器資源來維持性能。也就是常說的系統(tǒng)需要線性可擴(kuò)展，通常采用scale out（通過增加機(jī)器的個數(shù)）而不是scale up（通過增強(qiáng)機(jī)器的性能）。
• General（通用性）：系統(tǒng)需要能夠適應(yīng)廣泛的應(yīng)用，包括金融領(lǐng)域、社交網(wǎng)絡(luò)、電子商務(wù)數(shù)據(jù)分析等。
• Extensible（可擴(kuò)展）：需要增加新功能、新特性時，可擴(kuò)展的系統(tǒng)能以最小的開發(fā)代價來增加新功能。
• Allows ad hoc queries（方便查詢）：數(shù)據(jù)中蘊(yùn)含有價值，需要能夠方便、快速的查詢出所需要的數(shù)據(jù)。
• Minimal maintenance（易于維護(hù)）：系統(tǒng)要想做到易于維護(hù)，其關(guān)鍵是控制其復(fù)雜性，越是復(fù)雜的系統(tǒng)越容易出錯、越難維護(hù)。
• Debuggable（易調(diào)試）：當(dāng)出問題時，系統(tǒng)需要有足夠的信息來調(diào)試錯誤，找到問題的根源。其關(guān)鍵是能夠追根溯源到每個數(shù)據(jù)生成點。

3.數(shù)據(jù)系統(tǒng)的本質(zhì)

為了設(shè)計出能滿足前述的大數(shù)據(jù)關(guān)鍵特性的系統(tǒng)，我們需要對數(shù)據(jù)系統(tǒng)有本質(zhì)性的理解。我們可將數(shù)據(jù)系統(tǒng)簡化為：

數(shù)據(jù)系統(tǒng) = 數(shù)據(jù) + 查詢

從而從數(shù)據(jù)和查詢兩方面來認(rèn)識大數(shù)據(jù)系統(tǒng)的本質(zhì)。

3.1.數(shù)據(jù)的本質(zhì)

3.1.1.數(shù)據(jù)的特性：When & What

我們先從“數(shù)據(jù)”的特性談起。數(shù)據(jù)是一個不可分割的單位，數(shù)據(jù)有兩個關(guān)鍵的性質(zhì)：When和What。

• When是指數(shù)據(jù)是與時間相關(guān)的，數(shù)據(jù)一定是在某個時間點產(chǎn)生的。比如Log日志就隱含著按照時間先后順序產(chǎn)生的數(shù)據(jù)，Log前面的日志數(shù)據(jù)一定先于Log后面的日志數(shù)據(jù)產(chǎn)生；消息系統(tǒng)中消息的接受者一定是在消息的發(fā)送者發(fā)送消息后接收到的消息。相比于數(shù)據(jù)庫，數(shù)據(jù)庫中表的記錄就丟失了時間先后順序的信息，中間某條記錄可能是在***一條記錄產(chǎn)生后發(fā)生更新的。對于分布式系統(tǒng)，數(shù)據(jù)的時間特性尤其重要。分布式系統(tǒng)中數(shù)據(jù)可能產(chǎn)生于不同的系統(tǒng)中，時間決定了數(shù)據(jù)發(fā)生的全局先后順序。比如對一個值做算術(shù)運(yùn)算，先+2，后*3，與先*3，后+2，得到的結(jié)果完全不同。數(shù)據(jù)的時間性質(zhì)決定了數(shù)據(jù)的全局發(fā)生先后，也就決定了數(shù)據(jù)的結(jié)果。
• What是指數(shù)據(jù)的本身。由于數(shù)據(jù)跟某個時間點相關(guān)，所以數(shù)據(jù)的本身是不可變的(immutable)，過往的數(shù)據(jù)已經(jīng)成為事實（Fact），你不可能回到過去的某個時間點去改變數(shù)據(jù)事實。這也就意味著對數(shù)據(jù)的操作其實只有兩種：讀取已存在的數(shù)據(jù)和添加更多的新數(shù)據(jù)。采用數(shù)據(jù)庫的記法，CRUD就變成了CR，Update和Delete本質(zhì)上其實是新產(chǎn)生的數(shù)據(jù)信息，用C來記錄。

3.1.2.數(shù)據(jù)的存儲：Store Everything Rawly and Immutably

根據(jù)上述對數(shù)據(jù)本質(zhì)特性的分析，Lamba架構(gòu)中對數(shù)據(jù)的存儲采用的方式是：數(shù)據(jù)不可變，存儲所有數(shù)據(jù)。

通過采用不可變方式存儲所有的數(shù)據(jù)，可以有如下好處：

• 簡單。采用不可變的數(shù)據(jù)模型，存儲數(shù)據(jù)時只需要簡單的往主數(shù)據(jù)集后追加數(shù)據(jù)即可。相比于采用可變的數(shù)據(jù)模型，為了Update操作，數(shù)據(jù)通常需要被索引，從而能快速找到要更新的數(shù)據(jù)去做更新操作。
• 應(yīng)對人為和機(jī)器的錯誤。前述中提到人和機(jī)器每天都可能會出錯，如何應(yīng)對人和機(jī)器的錯誤，讓系統(tǒng)能夠從錯誤中快速恢復(fù)極其重要。不可變性（Immutability）和重新計算（Recomputation）則是應(yīng)對人為和機(jī)器錯誤的常用方法。采用可變數(shù)據(jù)模型，引發(fā)錯誤的數(shù)據(jù)有可能被覆蓋而丟失。相比于采用不可變的數(shù)據(jù)模型，因為所有的數(shù)據(jù)都在，引發(fā)錯誤的數(shù)據(jù)也在。修復(fù)的方法就可以簡單的是遍歷數(shù)據(jù)集上存儲的所有的數(shù)據(jù)，丟棄錯誤的數(shù)據(jù)，重新計算得到Views（View的概念參考4.1.2）。重新計算的關(guān)鍵點在于利用數(shù)據(jù)的時間特性決定的全局次序，依次順序重新執(zhí)行，必然能得到正確的結(jié)果。

當(dāng)前業(yè)界有很多采用不可變數(shù)據(jù)模型來存儲所有數(shù)據(jù)的例子。比如分布式數(shù)據(jù)庫Datomic，基于不可變數(shù)據(jù)模型來存儲數(shù)據(jù)，從而簡化了設(shè)計。分布式消息中間件Kafka，基于Log日志，以追加append-only的方式來存儲消息。

3.2.查詢

查詢是個什么概念？Marz給查詢?nèi)缦乱粋€簡單的定義：

Query = Function(All Data)

該等式的含義是：查詢是應(yīng)用于數(shù)據(jù)集上的函數(shù)。該定義看似簡單，卻幾乎囊括了數(shù)據(jù)庫和數(shù)據(jù)系統(tǒng)的所有領(lǐng)域：RDBMS、索引、OLAP、OLTP、MapReduce、EFL、分布式文件系統(tǒng)、NoSQL等都可以用這個等式來表示。

讓我們進(jìn)一步深入看一下函數(shù)的特性，從而挖掘函數(shù)自身的特點來執(zhí)行查詢。

有一類稱為Monoid特性的函數(shù)應(yīng)用非常廣泛。Monoid的概念來源于范疇學(xué)（Category Theory），其一個重要特性是滿足結(jié)合律。如整數(shù)的加法就滿足Monoid特性：

(a+b)+c=a+(b+c)

不滿足Monoid特性的函數(shù)很多時候可以轉(zhuǎn)化成多個滿足Monoid特性的函數(shù)的運(yùn)算。如多個數(shù)的平均值A(chǔ)vg函數(shù)，多個平均值沒法直接通過結(jié)合來得到最終的平均值，但是可以拆成分母除以分子，分母和分子都是整數(shù)的加法，從而滿足Monoid特性。

Monoid的結(jié)合律特性在分布式計算中極其重要，滿足Monoid特性意味著我們可以將計算分解到多臺機(jī)器并行運(yùn)算，然后再結(jié)合各自的部分運(yùn)算結(jié)果得到最終結(jié)果。同時也意味著部分運(yùn)算結(jié)果可以儲存下來被別的運(yùn)算共享利用（如果該運(yùn)算也包含相同的部分子運(yùn)算），從而減少重復(fù)運(yùn)算的工作量。

4.Lambda架構(gòu)

有了上面對數(shù)據(jù)系統(tǒng)本質(zhì)的探討，下面我們來討論大數(shù)據(jù)系統(tǒng)的關(guān)鍵問題：如何實時地在任意大數(shù)據(jù)集上進(jìn)行查詢？大數(shù)據(jù)再加上實時計算，問題的難度比較大。

最簡單的方法是，根據(jù)前述的查詢等式Query = Function(All Data)，在全體數(shù)據(jù)集上在線運(yùn)行查詢函數(shù)得到結(jié)果。但如果數(shù)據(jù)量比較大，該方法的計算代價太大了，所以不現(xiàn)實。

Lambda架構(gòu)通過分解的三層架構(gòu)來解決該問題：Batch Layer，Speed Layer和Serving Layer。

4.1.Batch Layer

Batch Layer的功能主要有兩點：

• 存儲數(shù)據(jù)集
• 在數(shù)據(jù)集上預(yù)先計算查詢函數(shù)，構(gòu)建查詢所對應(yīng)的View

4.1.1.儲存數(shù)據(jù)集

根據(jù)前述對數(shù)據(jù)When&What特性的討論，Batch Layer采用不可變模型存儲所有的數(shù)據(jù)。因為數(shù)據(jù)量比較大，可以采用HDFS之類的大數(shù)據(jù)儲存方案。如果需要按照數(shù)據(jù)產(chǎn)生的時間先后順序存放數(shù)據(jù)，可以考慮如InfluxDB之類的時間序列數(shù)據(jù)庫（TSDB）存儲方案。

4.1.2.構(gòu)建查詢View

上面說到根據(jù)等式Query = Function(All Data)，在全體數(shù)據(jù)集上在線運(yùn)行查詢函數(shù)得到結(jié)果的代價太大。但如果我們預(yù)先在數(shù)據(jù)集上計算并保存查詢函數(shù)的結(jié)果，查詢的時候就可以直接返回結(jié)果（或通過簡單的加工運(yùn)算就可得到結(jié)果）而無需重新進(jìn)行完整費時的計算了。這兒可以把Batch Layer看成是一個數(shù)據(jù)預(yù)處理的過程。我們把針對查詢預(yù)先計算并保存的結(jié)果稱為View，View是Lamba架構(gòu)的一個核心概念，它是針對查詢的優(yōu)化，通過View即可以快速得到查詢結(jié)果。

如果采用HDFS來儲存數(shù)據(jù)，我們就可以使用MapReduce來在數(shù)據(jù)集上構(gòu)建查詢的View。Batch Layer的工作可以簡單的用如下偽碼表示：

該工作看似簡單，實質(zhì)非常強(qiáng)大。任何人為或機(jī)器發(fā)生的錯誤，都可以通過修正錯誤后重新計算來恢復(fù)得到正確結(jié)果。

對View的理解：
View是一個和業(yè)務(wù)關(guān)聯(lián)性比較大的概念，View的創(chuàng)建需要從業(yè)務(wù)自身的需求出發(fā)。一個通用的數(shù)據(jù)庫查詢系統(tǒng)，查詢對應(yīng)的函數(shù)千變?nèi)f化，不可能窮舉。但是如果從業(yè)務(wù)自身的需求出發(fā)，可以發(fā)現(xiàn)業(yè)務(wù)所需要的查詢常常是有限的。Batch Layer需要做的一件重要的工作就是根據(jù)業(yè)務(wù)的需求，考察可能需要的各種查詢，根據(jù)查詢定義其在數(shù)據(jù)集上對應(yīng)的Views。

4.2.Speed Layer

Batch Layer可以很好的處理離線數(shù)據(jù)，但有很多場景數(shù)據(jù)不斷實時生成，并且需要實時查詢處理。Speed Layer正是用來處理增量的實時數(shù)據(jù)。

Speed Layer和Batch Layer比較類似，對數(shù)據(jù)進(jìn)行計算并生成Realtime View，其主要區(qū)別在于：

• Speed Layer處理的數(shù)據(jù)是最近的增量數(shù)據(jù)流，Batch Layer處理的全體數(shù)據(jù)集
• Speed Layer為了效率，接收到新數(shù)據(jù)時不斷更新Realtime View，而Batch Layer根據(jù)全體離線數(shù)據(jù)集直接得到Batch View。

Lambda架構(gòu)將數(shù)據(jù)處理分解為Batch Layer和Speed Layer有如下優(yōu)點：

• 容錯性。Speed Layer中處理的數(shù)據(jù)也不斷寫入Batch Layer，當(dāng)Batch Layer中重新計算的數(shù)據(jù)集包含Speed Layer處理的數(shù)據(jù)集后，當(dāng)前的Realtime View就可以丟棄，這也就意味著Speed Layer處理中引入的錯誤，在Batch Layer重新計算時都可以得到修正。這點也可以看成是CAP理論中的最終一致性（Eventual Consistency）的體現(xiàn)。
•  
• 復(fù)雜性隔離。Batch Layer處理的是離線數(shù)據(jù)，可以很好的掌控。Speed Layer采用增量算法處理實時數(shù)據(jù)，復(fù)雜性比Batch Layer要高很多。通過分開Batch Layer和Speed Layer，把復(fù)雜性隔離到Speed Layer，可以很好的提高整個系統(tǒng)的魯棒性和可靠性。

4.3.Serving Layer

Lambda架構(gòu)的Serving Layer用于響應(yīng)用戶的查詢請求，合并Batch View和Realtime View中的結(jié)果數(shù)據(jù)集到最終的數(shù)據(jù)集。

這兒涉及到數(shù)據(jù)如何合并的問題。前面我們討論了查詢函數(shù)的Monoid性質(zhì)，如果查詢函數(shù)滿足Monoid性質(zhì)，即滿足結(jié)合率，只需要簡單的合并Batch View和Realtime View中的結(jié)果數(shù)據(jù)集即可。否則的話，可以把查詢函數(shù)轉(zhuǎn)換成多個滿足Monoid性質(zhì)的查詢函數(shù)的運(yùn)算，單獨對每個滿足Monoid性質(zhì)的查詢函數(shù)進(jìn)行Batch View和Realtime View中的結(jié)果數(shù)據(jù)集合并，然后再計算得到最終的結(jié)果數(shù)據(jù)集。另外也可以根據(jù)業(yè)務(wù)自身的特性，運(yùn)用業(yè)務(wù)自身的規(guī)則來對Batch View和Realtime View中的結(jié)果數(shù)據(jù)集合并。

5.Big Picture

上面分別討論了Lambda架構(gòu)的三層：Batch Layer，Speed Layer和Serving Layer。下圖給出了Lambda架構(gòu)的一個完整視圖和流程。

數(shù)據(jù)流進(jìn)入系統(tǒng)后，同時發(fā)往Batch Layer和Speed Layer處理。Batch Layer以不可變模型離線存儲所有數(shù)據(jù)集，通過在全體數(shù)據(jù)集上不斷重新計算構(gòu)建查詢所對應(yīng)的Batch Views。Speed Layer處理增量的實時數(shù)據(jù)流，不斷更新查詢所對應(yīng)的Realtime Views。Serving Layer響應(yīng)用戶的查詢請求，合并Batch View和Realtime View中的結(jié)果數(shù)據(jù)集到最終的數(shù)據(jù)集。

5.1.Lambda架構(gòu)組件選型

下圖給出了Lambda架構(gòu)中各個層常用的組件。數(shù)據(jù)流存儲可選用基于不可變?nèi)罩镜姆植际较⑾到y(tǒng)Kafka；Batch Layer數(shù)據(jù)集的存儲可選用Hadoop的HDFS，或者是阿里云的ODPS；Batch View的預(yù)計算可以選用MapReduce或Spark；Batch View自身結(jié)果數(shù)據(jù)的存儲可使用MySQL（查詢少量的最近結(jié)果數(shù)據(jù)），或HBase（查詢大量的歷史結(jié)果數(shù)據(jù)）。Speed Layer增量數(shù)據(jù)的處理可選用Storm或Spark Streaming；Realtime View增量結(jié)果數(shù)據(jù)集為了滿足實時更新的效率，可選用Redis等內(nèi)存NoSQL。

5.2.Lambda架構(gòu)組件選型原則

Lambda架構(gòu)是個通用框架，各個層選型時不要局限時上面給出的組件，特別是對于View的選型。從我對Lambda架構(gòu)的實踐來看，因為View是個和業(yè)務(wù)關(guān)聯(lián)性非常大的概念，View選擇組件時關(guān)鍵是要根據(jù)業(yè)務(wù)的需求，來選擇最適合查詢的組件。不同的View組件的選擇要深入挖掘數(shù)據(jù)和計算自身的特點，從而選擇出最適合數(shù)據(jù)和計算自身特點的組件，同時不同的View可以選擇不同的組件。

6.Lambda架構(gòu) vs. Event Sourcing vs. CQRS

在Lambda架構(gòu)身上可以看到很多現(xiàn)有設(shè)計思想和架構(gòu)的影子，如Event Sourcing和CQRS，這兒我們把它們和Lambda架構(gòu)做一結(jié)合對比，從而去更深入的理解Lambda架構(gòu)。

6.1.事件溯源（Event Sourcing）vs. Lambda架構(gòu)

事件溯源（Event Sourcing）是由大名鼎鼎的Martin Flower大叔提出來的架構(gòu)模式。Event Sourcing本質(zhì)上是一種數(shù)據(jù)持久化的方式，它將引發(fā)變化的事件（Event）本身存儲下來。相比于傳統(tǒng)數(shù)據(jù)是持久化方式，存儲的是事件引發(fā)的結(jié)果，而非事件本身，這樣我們在保存結(jié)果的同時，實際上失去了追溯導(dǎo)致結(jié)果原因的機(jī)會。

這兒可以看到Lambda架構(gòu)中數(shù)據(jù)集的存儲和Event Sourcing中的思想是完全一致的，本質(zhì)都是采用不可變的數(shù)據(jù)模型存儲引發(fā)變化的事件而非變化產(chǎn)生的結(jié)果。從而在發(fā)生錯誤的時候，能夠追本溯源，找到發(fā)生錯誤的根源，通過重新計算丟棄錯誤的信息來恢復(fù)系統(tǒng)，達(dá)到系統(tǒng)的容錯性。

6.2.CQRS vs. Lambda架構(gòu)

CQRS (Command Query Responsibility Segregation)將對數(shù)據(jù)的修改操作和查詢操作分離，其本質(zhì)和Lambda架構(gòu)一樣，也是一種形式的讀寫分離。在Lambda架構(gòu)中，數(shù)據(jù)以不可變的方式存儲下來（寫操作），轉(zhuǎn)換成查詢所對應(yīng)的Views，查詢從View中直接得到結(jié)果數(shù)據(jù)（讀操作）。

讀寫分離將讀和寫兩個視角進(jìn)行分離，帶來的好處是復(fù)雜性的隔離，從而簡化系統(tǒng)的設(shè)計。相比于傳統(tǒng)做法中的將讀和寫操作放在一起的處理方式，對于讀寫操作業(yè)務(wù)非常復(fù)雜的系統(tǒng)，只會使系統(tǒng)變得異常復(fù)雜，難以維護(hù)。 

7.總結(jié)

本文介紹了Lambda架構(gòu)的基本概念。Lambda架構(gòu)通過對數(shù)據(jù)和查詢的本質(zhì)認(rèn)識，融合了不可變性（Immunability），讀寫分離和復(fù)雜性隔離等一系列架構(gòu)原則，將大數(shù)據(jù)處理系統(tǒng)劃分為Batch Layer, Speed Layer和Serving Layer三層，從而設(shè)計出一個能滿足實時大數(shù)據(jù)系統(tǒng)關(guān)鍵特性（如高容錯、低延時和可擴(kuò)展等）的架構(gòu)。Lambda架構(gòu)作為一個通用的大數(shù)據(jù)處理框架，可以很方便的集成Hadoop，Kafka，Storm，Spark，Hbase等各類大數(shù)據(jù)組件。