用于實(shí)時(shí)大數(shù)據(jù)處理的Lambda架構(gòu)
1.Lambda架構(gòu)背景介紹
Lambda架構(gòu)是由Storm的作者Nathan Marz提出的一個(gè)實(shí)時(shí)大數(shù)據(jù)處理框架。Marz在Twitter工作期間開(kāi)發(fā)了著名的實(shí)時(shí)大數(shù)據(jù)處理框架Storm，Lambda架構(gòu)是其根據(jù)多年進(jìn)行分布式大數(shù)據(jù)系統(tǒng)的經(jīng)驗(yàn)總結(jié)提煉而成。
Lambda架構(gòu)的目標(biāo)是設(shè)計(jì)出一個(gè)能滿(mǎn)足實(shí)時(shí)大數(shù)據(jù)系統(tǒng)關(guān)鍵特性的架構(gòu)，包括有：高容錯(cuò)、低延時(shí)和可擴(kuò)展等。Lambda架構(gòu)整合離線計(jì)算和實(shí)時(shí)計(jì)算，融合不可變性（Immunability），讀寫(xiě)分離和復(fù)雜性隔離等一系列架構(gòu)原則，可集成Hadoop，Kafka，Storm，Spark，Hbase等各類(lèi)大數(shù)據(jù)組件。
2.大數(shù)據(jù)系統(tǒng)的關(guān)鍵特性
Marz認(rèn)為大數(shù)據(jù)系統(tǒng)應(yīng)具有以下的關(guān)鍵特性：
- Robust and fault-tolerant（容錯(cuò)性和魯棒性）：對(duì)大規(guī)模分布式系統(tǒng)來(lái)說(shuō)，機(jī)器是不可靠的，可能會(huì)當(dāng)機(jī)，但是系統(tǒng)需要是健壯、行為正確的，即使是遇到機(jī)器錯(cuò)誤。除了機(jī)器錯(cuò)誤，人更可能會(huì)犯錯(cuò)誤。在軟件開(kāi)發(fā)中難免會(huì)有一些Bug，系統(tǒng)必須對(duì)有Bug的程序?qū)懭氲腻e(cuò)誤數(shù)據(jù)有足夠的適應(yīng)能力，所以比機(jī)器容錯(cuò)性更加重要的容錯(cuò)性是人為操作容錯(cuò)性。對(duì)于大規(guī)模的分布式系統(tǒng)來(lái)說(shuō)，人和機(jī)器的錯(cuò)誤每天都可能會(huì)發(fā)生，如何應(yīng)對(duì)人和機(jī)器的錯(cuò)誤，讓系統(tǒng)能夠從錯(cuò)誤中快速恢復(fù)尤其重要。
- Low latency reads and updates（低延時(shí)）：很多應(yīng)用對(duì)于讀和寫(xiě)操作的延時(shí)要求非常高，要求對(duì)更新和查詢(xún)的響應(yīng)是低延時(shí)的。
- Scalable（橫向擴(kuò)容）：當(dāng)數(shù)據(jù)量/負(fù)載增大時(shí)，可擴(kuò)展性的系統(tǒng)通過(guò)增加更多的機(jī)器資源來(lái)維持性能。也就是常說(shuō)的系統(tǒng)需要線性可擴(kuò)展，通常采用scale out（通過(guò)增加機(jī)器的個(gè)數(shù)）而不是scale up（通過(guò)增強(qiáng)機(jī)器的性能）。
- General（通用性）：系統(tǒng)需要能夠適應(yīng)廣泛的應(yīng)用，包括金融領(lǐng)域、社交網(wǎng)絡(luò)、電子商務(wù)數(shù)據(jù)分析等。
- Extensible（可擴(kuò)展）：需要增加新功能、新特性時(shí)，可擴(kuò)展的系統(tǒng)能以最小的開(kāi)發(fā)代價(jià)來(lái)增加新功能。
- Allows ad hoc queries（方便查詢(xún)）：數(shù)據(jù)中蘊(yùn)含有價(jià)值，需要能夠方便、快速的查詢(xún)出所需要的數(shù)據(jù)。
- Minimal maintenance（易于維護(hù)）：系統(tǒng)要想做到易于維護(hù)，其關(guān)鍵是控制其復(fù)雜性，越是復(fù)雜的系統(tǒng)越容易出錯(cuò)、越難維護(hù)。
- Debuggable（易調(diào)試）：當(dāng)出問(wèn)題時(shí)，系統(tǒng)需要有足夠的信息來(lái)調(diào)試錯(cuò)誤，找到問(wèn)題的根源。其關(guān)鍵是能夠追根溯源到每個(gè)數(shù)據(jù)生成點(diǎn)。
3.數(shù)據(jù)系統(tǒng)的本質(zhì)
為了設(shè)計(jì)出能滿(mǎn)足前述的大數(shù)據(jù)關(guān)鍵特性的系統(tǒng)，我們需要對(duì)數(shù)據(jù)系統(tǒng)有本質(zhì)性的理解。我們可將數(shù)據(jù)系統(tǒng)簡(jiǎn)化為：
數(shù)據(jù)系統(tǒng) = 數(shù)據(jù) + 查詢(xún)
從而從數(shù)據(jù)和查詢(xún)兩方面來(lái)認(rèn)識(shí)大數(shù)據(jù)系統(tǒng)的本質(zhì)。
3.1.數(shù)據(jù)的本質(zhì)
3.1.1.數(shù)據(jù)的特性：When & What
我們先從“數(shù)據(jù)”的特性談起。數(shù)據(jù)是一個(gè)不可分割的單位，數(shù)據(jù)有兩個(gè)關(guān)鍵的性質(zhì)：When和What。
- When是指數(shù)據(jù)是與時(shí)間相關(guān)的，數(shù)據(jù)一定是在某個(gè)時(shí)間點(diǎn)產(chǎn)生的。比如Log日志就隱含著按照時(shí)間先后順序產(chǎn)生的數(shù)據(jù)，Log前面的日志數(shù)據(jù)一定先于Log后面的日志數(shù)據(jù)產(chǎn)生；消息系統(tǒng)中消息的接受者一定是在消息的發(fā)送者發(fā)送消息后接收到的消息。相比于數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)中表的記錄就丟失了時(shí)間先后順序的信息，中間某條記錄可能是在***一條記錄產(chǎn)生后發(fā)生更新的。對(duì)于分布式系統(tǒng)，數(shù)據(jù)的時(shí)間特性尤其重要。分布式系統(tǒng)中數(shù)據(jù)可能產(chǎn)生于不同的系統(tǒng)中，時(shí)間決定了數(shù)據(jù)發(fā)生的全局先后順序。比如對(duì)一個(gè)值做算術(shù)運(yùn)算，先+2，后*3，與先*3，后+2，得到的結(jié)果完全不同。數(shù)據(jù)的時(shí)間性質(zhì)決定了數(shù)據(jù)的全局發(fā)生先后，也就決定了數(shù)據(jù)的結(jié)果。
- What是指數(shù)據(jù)的本身。由于數(shù)據(jù)跟某個(gè)時(shí)間點(diǎn)相關(guān)，所以數(shù)據(jù)的本身是不可變的(immutable)，過(guò)往的數(shù)據(jù)已經(jīng)成為事實(shí)（Fact），你不可能回到過(guò)去的某個(gè)時(shí)間點(diǎn)去改變數(shù)據(jù)事實(shí)。這也就意味著對(duì)數(shù)據(jù)的操作其實(shí)只有兩種：讀取已存在的數(shù)據(jù)和添加更多的新數(shù)據(jù)。采用數(shù)據(jù)庫(kù)的記法，CRUD就變成了CR，Update和Delete本質(zhì)上其實(shí)是新產(chǎn)生的數(shù)據(jù)信息，用C來(lái)記錄。
3.1.2.數(shù)據(jù)的存儲(chǔ)：Store Everything Rawly and Immutably
根據(jù)上述對(duì)數(shù)據(jù)本質(zhì)特性的分析，Lamba架構(gòu)中對(duì)數(shù)據(jù)的存儲(chǔ)采用的方式是：數(shù)據(jù)不可變，存儲(chǔ)所有數(shù)據(jù)。
通過(guò)采用不可變方式存儲(chǔ)所有的數(shù)據(jù)，可以有如下好處：
- 簡(jiǎn)單。采用不可變的數(shù)據(jù)模型，存儲(chǔ)數(shù)據(jù)時(shí)只需要簡(jiǎn)單的往主數(shù)據(jù)集后追加數(shù)據(jù)即可。相比于采用可變的數(shù)據(jù)模型，為了Update操作，數(shù)據(jù)通常需要被索引，從而能快速找到要更新的數(shù)據(jù)去做更新操作。
- 應(yīng)對(duì)人為和機(jī)器的錯(cuò)誤。前述中提到人和機(jī)器每天都可能會(huì)出錯(cuò)，如何應(yīng)對(duì)人和機(jī)器的錯(cuò)誤，讓系統(tǒng)能夠從錯(cuò)誤中快速恢復(fù)極其重要。不可變性（Immutability）和重新計(jì)算（Recomputation）則是應(yīng)對(duì)人為和機(jī)器錯(cuò)誤的常用方法。采用可變數(shù)據(jù)模型，引發(fā)錯(cuò)誤的數(shù)據(jù)有可能被覆蓋而丟失。相比于采用不可變的數(shù)據(jù)模型，因?yàn)樗械臄?shù)據(jù)都在，引發(fā)錯(cuò)誤的數(shù)據(jù)也在。修復(fù)的方法就可以簡(jiǎn)單的是遍歷數(shù)據(jù)集上存儲(chǔ)的所有的數(shù)據(jù)，丟棄錯(cuò)誤的數(shù)據(jù)，重新計(jì)算得到Views（View的概念參考4.1.2）。重新計(jì)算的關(guān)鍵點(diǎn)在于利用數(shù)據(jù)的時(shí)間特性決定的全局次序，依次順序重新執(zhí)行，必然能得到正確的結(jié)果。
當(dāng)前業(yè)界有很多采用不可變數(shù)據(jù)模型來(lái)存儲(chǔ)所有數(shù)據(jù)的例子。比如分布式數(shù)據(jù)庫(kù)Datomic，基于不可變數(shù)據(jù)模型來(lái)存儲(chǔ)數(shù)據(jù)，從而簡(jiǎn)化了設(shè)計(jì)。分布式消息中間件Kafka，基于Log日志，以追加append-only的方式來(lái)存儲(chǔ)消息。
3.2.查詢(xún)
查詢(xún)是個(gè)什么概念？Marz給查詢(xún)?nèi)缦乱粋€(gè)簡(jiǎn)單的定義：
Query = Function(All Data)
該等式的含義是：查詢(xún)是應(yīng)用于數(shù)據(jù)集上的函數(shù)。該定義看似簡(jiǎn)單，卻幾乎囊括了數(shù)據(jù)庫(kù)和數(shù)據(jù)系統(tǒng)的所有領(lǐng)域：RDBMS、索引、OLAP、OLTP、MapReduce、EFL、分布式文件系統(tǒng)、NoSQL等都可以用這個(gè)等式來(lái)表示。
讓我們進(jìn)一步深入看一下函數(shù)的特性，從而挖掘函數(shù)自身的特點(diǎn)來(lái)執(zhí)行查詢(xún)。
有一類(lèi)稱(chēng)為Monoid特性的函數(shù)應(yīng)用非常廣泛。Monoid的概念來(lái)源于范疇學(xué)（Category Theory），其一個(gè)重要特性是滿(mǎn)足結(jié)合律。如整數(shù)的加法就滿(mǎn)足Monoid特性：
(a+b)+c=a+(b+c)
不滿(mǎn)足Monoid特性的函數(shù)很多時(shí)候可以轉(zhuǎn)化成多個(gè)滿(mǎn)足Monoid特性的函數(shù)的運(yùn)算。如多個(gè)數(shù)的平均值A(chǔ)vg函數(shù)，多個(gè)平均值沒(méi)法直接通過(guò)結(jié)合來(lái)得到最終的平均值，但是可以拆成分母除以分子，分母和分子都是整數(shù)的加法，從而滿(mǎn)足Monoid特性。
Monoid的結(jié)合律特性在分布式計(jì)算中極其重要，滿(mǎn)足Monoid特性意味著我們可以將計(jì)算分解到多臺(tái)機(jī)器并行運(yùn)算，然后再結(jié)合各自的部分運(yùn)算結(jié)果得到最終結(jié)果。同時(shí)也意味著部分運(yùn)算結(jié)果可以?xún)?chǔ)存下來(lái)被別的運(yùn)算共享利用（如果該運(yùn)算也包含相同的部分子運(yùn)算），從而減少重復(fù)運(yùn)算的工作量。
4.Lambda架構(gòu)
有了上面對(duì)數(shù)據(jù)系統(tǒng)本質(zhì)的探討，下面我們來(lái)討論大數(shù)據(jù)系統(tǒng)的關(guān)鍵問(wèn)題：如何實(shí)時(shí)地在任意大數(shù)據(jù)集上進(jìn)行查詢(xún)？大數(shù)據(jù)再加上實(shí)時(shí)計(jì)算，問(wèn)題的難度比較大。
最簡(jiǎn)單的方法是，根據(jù)前述的查詢(xún)等式Query = Function(All Data)，在全體數(shù)據(jù)集上在線運(yùn)行查詢(xún)函數(shù)得到結(jié)果。但如果數(shù)據(jù)量比較大，該方法的計(jì)算代價(jià)太大了，所以不現(xiàn)實(shí)。
Lambda架構(gòu)通過(guò)分解的三層架構(gòu)來(lái)解決該問(wèn)題：Batch Layer，Speed Layer和Serving Layer。
4.1.Batch Layer
Batch Layer的功能主要有兩點(diǎn)：
- 存儲(chǔ)數(shù)據(jù)集
- 在數(shù)據(jù)集上預(yù)先計(jì)算查詢(xún)函數(shù)，構(gòu)建查詢(xún)所對(duì)應(yīng)的View
4.1.1.儲(chǔ)存數(shù)據(jù)集
根據(jù)前述對(duì)數(shù)據(jù)When&What特性的討論，Batch Layer采用不可變模型存儲(chǔ)所有的數(shù)據(jù)。因?yàn)閿?shù)據(jù)量比較大，可以采用HDFS之類(lèi)的大數(shù)據(jù)儲(chǔ)存方案。如果需要按照數(shù)據(jù)產(chǎn)生的時(shí)間先后順序存放數(shù)據(jù)，可以考慮如InfluxDB之類(lèi)的時(shí)間序列數(shù)據(jù)庫(kù)（TSDB）存儲(chǔ)方案。
4.1.2.構(gòu)建查詢(xún)View
上面說(shuō)到根據(jù)等式Query = Function(All Data)，在全體數(shù)據(jù)集上在線運(yùn)行查詢(xún)函數(shù)得到結(jié)果的代價(jià)太大。但如果我們預(yù)先在數(shù)據(jù)集上計(jì)算并保存查詢(xún)函數(shù)的結(jié)果，查詢(xún)的時(shí)候就可以直接返回結(jié)果（或通過(guò)簡(jiǎn)單的加工運(yùn)算就可得到結(jié)果）而無(wú)需重新進(jìn)行完整費(fèi)時(shí)的計(jì)算了。這兒可以把Batch Layer看成是一個(gè)數(shù)據(jù)預(yù)處理的過(guò)程。我們把針對(duì)查詢(xún)預(yù)先計(jì)算并保存的結(jié)果稱(chēng)為View，View是Lamba架構(gòu)的一個(gè)核心概念，它是針對(duì)查詢(xún)的優(yōu)化，通過(guò)View即可以快速得到查詢(xún)結(jié)果。
如果采用HDFS來(lái)儲(chǔ)存數(shù)據(jù)，我們就可以使用MapReduce來(lái)在數(shù)據(jù)集上構(gòu)建查詢(xún)的View。Batch Layer的工作可以簡(jiǎn)單的用如下偽碼表示：
該工作看似簡(jiǎn)單，實(shí)質(zhì)非常強(qiáng)大。任何人為或機(jī)器發(fā)生的錯(cuò)誤，都可以通過(guò)修正錯(cuò)誤后重新計(jì)算來(lái)恢復(fù)得到正確結(jié)果。
對(duì)View的理解：
View是一個(gè)和業(yè)務(wù)關(guān)聯(lián)性比較大的概念，View的創(chuàng)建需要從業(yè)務(wù)自身的需求出發(fā)。一個(gè)通用的數(shù)據(jù)庫(kù)查詢(xún)系統(tǒng)，查詢(xún)對(duì)應(yīng)的函數(shù)千變?nèi)f化，不可能窮舉。但是如果從業(yè)務(wù)自身的需求出發(fā)，可以發(fā)現(xiàn)業(yè)務(wù)所需要的查詢(xún)常常是有限的。Batch Layer需要做的一件重要的工作就是根據(jù)業(yè)務(wù)的需求，考察可能需要的各種查詢(xún)，根據(jù)查詢(xún)定義其在數(shù)據(jù)集上對(duì)應(yīng)的Views。
4.2.Speed Layer
Batch Layer可以很好的處理離線數(shù)據(jù)，但有很多場(chǎng)景數(shù)據(jù)不斷實(shí)時(shí)生成，并且需要實(shí)時(shí)查詢(xún)處理。Speed Layer正是用來(lái)處理增量的實(shí)時(shí)數(shù)據(jù)。
Speed Layer和Batch Layer比較類(lèi)似，對(duì)數(shù)據(jù)進(jìn)行計(jì)算并生成Realtime View，其主要區(qū)別在于：
- Speed Layer處理的數(shù)據(jù)是最近的增量數(shù)據(jù)流，Batch Layer處理的全體數(shù)據(jù)集
- Speed Layer為了效率，接收到新數(shù)據(jù)時(shí)不斷更新Realtime View，而B(niǎo)atch Layer根據(jù)全體離線數(shù)據(jù)集直接得到Batch View。
Lambda架構(gòu)將數(shù)據(jù)處理分解為Batch Layer和Speed Layer有如下優(yōu)點(diǎn)：
- 容錯(cuò)性。Speed Layer中處理的數(shù)據(jù)也不斷寫(xiě)入Batch Layer，當(dāng)Batch Layer中重新計(jì)算的數(shù)據(jù)集包含Speed Layer處理的數(shù)據(jù)集后，當(dāng)前的Realtime View就可以丟棄，這也就意味著Speed Layer處理中引入的錯(cuò)誤，在Batch Layer重新計(jì)算時(shí)都可以得到修正。這點(diǎn)也可以看成是CAP理論中的最終一致性（Eventual Consistency）的體現(xiàn)。
- 復(fù)雜性隔離。Batch Layer處理的是離線數(shù)據(jù)，可以很好的掌控。Speed Layer采用增量算法處理實(shí)時(shí)數(shù)據(jù)，復(fù)雜性比Batch Layer要高很多。通過(guò)分開(kāi)Batch Layer和Speed Layer，把復(fù)雜性隔離到Speed Layer，可以很好的提高整個(gè)系統(tǒng)的魯棒性和可靠性。
4.3.Serving Layer
Lambda架構(gòu)的Serving Layer用于響應(yīng)用戶(hù)的查詢(xún)請(qǐng)求，合并Batch View和Realtime View中的結(jié)果數(shù)據(jù)集到最終的數(shù)據(jù)集。
這兒涉及到數(shù)據(jù)如何合并的問(wèn)題。前面我們討論了查詢(xún)函數(shù)的Monoid性質(zhì)，如果查詢(xún)函數(shù)滿(mǎn)足Monoid性質(zhì)，即滿(mǎn)足結(jié)合率，只需要簡(jiǎn)單的合并Batch View和Realtime View中的結(jié)果數(shù)據(jù)集即可。否則的話(huà)，可以把查詢(xún)函數(shù)轉(zhuǎn)換成多個(gè)滿(mǎn)足Monoid性質(zhì)的查詢(xún)函數(shù)的運(yùn)算，單獨(dú)對(duì)每個(gè)滿(mǎn)足Monoid性質(zhì)的查詢(xún)函數(shù)進(jìn)行Batch View和Realtime View中的結(jié)果數(shù)據(jù)集合并，然后再計(jì)算得到最終的結(jié)果數(shù)據(jù)集。另外也可以根據(jù)業(yè)務(wù)自身的特性，運(yùn)用業(yè)務(wù)自身的規(guī)則來(lái)對(duì)Batch View和Realtime View中的結(jié)果數(shù)據(jù)集合并。
5.Big Picture
上面分別討論了Lambda架構(gòu)的三層：Batch Layer，Speed Layer和Serving Layer。下圖給出了Lambda架構(gòu)的一個(gè)完整視圖和流程。
數(shù)據(jù)流進(jìn)入系統(tǒng)后，同時(shí)發(fā)往Batch Layer和Speed Layer處理。Batch Layer以不可變模型離線存儲(chǔ)所有數(shù)據(jù)集，通過(guò)在全體數(shù)據(jù)集上不斷重新計(jì)算構(gòu)建查詢(xún)所對(duì)應(yīng)的Batch Views。Speed Layer處理增量的實(shí)時(shí)數(shù)據(jù)流，不斷更新查詢(xún)所對(duì)應(yīng)的Realtime Views。Serving Layer響應(yīng)用戶(hù)的查詢(xún)請(qǐng)求，合并Batch View和Realtime View中的結(jié)果數(shù)據(jù)集到最終的數(shù)據(jù)集。
5.1.Lambda架構(gòu)組件選型
下圖給出了Lambda架構(gòu)中各個(gè)層常用的組件。數(shù)據(jù)流存儲(chǔ)可選用基于不可變?nèi)罩镜姆植际较⑾到y(tǒng)Kafka；Batch Layer數(shù)據(jù)集的存儲(chǔ)可選用Hadoop的HDFS，或者是阿里云的ODPS；Batch View的預(yù)計(jì)算可以選用MapReduce或Spark；Batch View自身結(jié)果數(shù)據(jù)的存儲(chǔ)可使用MySQL（查詢(xún)少量的最近結(jié)果數(shù)據(jù)），或HBase（查詢(xún)大量的歷史結(jié)果數(shù)據(jù)）。Speed Layer增量數(shù)據(jù)的處理可選用Storm或Spark Streaming；Realtime View增量結(jié)果數(shù)據(jù)集為了滿(mǎn)足實(shí)時(shí)更新的效率，可選用Redis等內(nèi)存NoSQL。
5.2.Lambda架構(gòu)組件選型原則
Lambda架構(gòu)是個(gè)通用框架，各個(gè)層選型時(shí)不要局限時(shí)上面給出的組件，特別是對(duì)于View的選型。從我對(duì)Lambda架構(gòu)的實(shí)踐來(lái)看，因?yàn)閂iew是個(gè)和業(yè)務(wù)關(guān)聯(lián)性非常大的概念，View選擇組件時(shí)關(guān)鍵是要根據(jù)業(yè)務(wù)的需求，來(lái)選擇最適合查詢(xún)的組件。不同的View組件的選擇要深入挖掘數(shù)據(jù)和計(jì)算自身的特點(diǎn)，從而選擇出最適合數(shù)據(jù)和計(jì)算自身特點(diǎn)的組件，同時(shí)不同的View可以選擇不同的組件。
6.Lambda架構(gòu) vs. Event Sourcing vs. CQRS
在Lambda架構(gòu)身上可以看到很多現(xiàn)有設(shè)計(jì)思想和架構(gòu)的影子，如Event Sourcing和CQRS，這兒我們把它們和Lambda架構(gòu)做一結(jié)合對(duì)比，從而去更深入的理解Lambda架構(gòu)。
6.1.事件溯源（Event Sourcing）vs. Lambda架構(gòu)
事件溯源（Event Sourcing）是由大名鼎鼎的Martin Flower大叔提出來(lái)的架構(gòu)模式。Event Sourcing本質(zhì)上是一種數(shù)據(jù)持久化的方式，它將引發(fā)變化的事件（Event）本身存儲(chǔ)下來(lái)。相比于傳統(tǒng)數(shù)據(jù)是持久化方式，存儲(chǔ)的是事件引發(fā)的結(jié)果，而非事件本身，這樣我們?cè)诒４娼Y(jié)果的同時(shí)，實(shí)際上失去了追溯導(dǎo)致結(jié)果原因的機(jī)會(huì)。
這兒可以看到Lambda架構(gòu)中數(shù)據(jù)集的存儲(chǔ)和Event Sourcing中的思想是完全一致的，本質(zhì)都是采用不可變的數(shù)據(jù)模型存儲(chǔ)引發(fā)變化的事件而非變化產(chǎn)生的結(jié)果。從而在發(fā)生錯(cuò)誤的時(shí)候，能夠追本溯源，找到發(fā)生錯(cuò)誤的根源，通過(guò)重新計(jì)算丟棄錯(cuò)誤的信息來(lái)恢復(fù)系統(tǒng)，達(dá)到系統(tǒng)的容錯(cuò)性。
6.2.CQRS vs. Lambda架構(gòu)
CQRS (Command Query Responsibility Segregation)將對(duì)數(shù)據(jù)的修改操作和查詢(xún)操作分離，其本質(zhì)和Lambda架構(gòu)一樣，也是一種形式的讀寫(xiě)分離。在Lambda架構(gòu)中，數(shù)據(jù)以不可變的方式存儲(chǔ)下來(lái)（寫(xiě)操作），轉(zhuǎn)換成查詢(xún)所對(duì)應(yīng)的Views，查詢(xún)從View中直接得到結(jié)果數(shù)據(jù)（讀操作）。
讀寫(xiě)分離將讀和寫(xiě)兩個(gè)視角進(jìn)行分離，帶來(lái)的好處是復(fù)雜性的隔離，從而簡(jiǎn)化系統(tǒng)的設(shè)計(jì)。相比于傳統(tǒng)做法中的將讀和寫(xiě)操作放在一起的處理方式，對(duì)于讀寫(xiě)操作業(yè)務(wù)非常復(fù)雜的系統(tǒng)，只會(huì)使系統(tǒng)變得異常復(fù)雜，難以維護(hù)。
7.總結(jié)
本文介紹了Lambda架構(gòu)的基本概念。Lambda架構(gòu)通過(guò)對(duì)數(shù)據(jù)和查詢(xún)的本質(zhì)認(rèn)識(shí)，融合了不可變性（Immunability），讀寫(xiě)分離和復(fù)雜性隔離等一系列架構(gòu)原則，將大數(shù)據(jù)處理系統(tǒng)劃分為Batch Layer, Speed Layer和Serving Layer三層，從而設(shè)計(jì)出一個(gè)能滿(mǎn)足實(shí)時(shí)大數(shù)據(jù)系統(tǒng)關(guān)鍵特性（如高容錯(cuò)、低延時(shí)和可擴(kuò)展等）的架構(gòu)。Lambda架構(gòu)作為一個(gè)通用的大數(shù)據(jù)處理框架，可以很方便的集成Hadoop，Kafka，Storm，Spark，Hbase等各類(lèi)大數(shù)據(jù)組件。
