【51CTO.com快譯】如今，物聯(lián)網(wǎng)(IoT)、社交媒體、應(yīng)用程序、以及分析設(shè)備，都在持續(xù)產(chǎn)生著各種類型的海量數(shù)據(jù)。而我們的業(yè)務(wù)系統(tǒng)需要每天接收各種大數(shù)據(jù)，并完成各項(xiàng)處理任務(wù)。因此，在日常處理這些持續(xù)增長(zhǎng)的數(shù)據(jù)時(shí)，數(shù)據(jù)系統(tǒng)會(huì)面臨延遲和準(zhǔn)確性兩個(gè)方面的挑戰(zhàn)。
Lambda架構(gòu)的介紹
針對(duì)上述挑戰(zhàn)，Nathan Marz和James Warren于2015年首發(fā)了Lambda體系架構(gòu)。它在邏輯上將數(shù)據(jù)系統(tǒng)分為三個(gè)層面，即：批處理(batch)層、速度(speed)層和服務(wù)(serving)層。而作為一種大數(shù)據(jù)的范例，它可以讓用戶通過(guò)構(gòu)建數(shù)據(jù)系統(tǒng)，以克服上述數(shù)據(jù)延遲與準(zhǔn)確性等問(wèn)題。
由于Lambda體系架構(gòu)可以被水平擴(kuò)展，因此如果您的數(shù)據(jù)集過(guò)大，或所需的數(shù)據(jù)視圖過(guò)多，則可以通過(guò)添加更多的主機(jī)來(lái)參與處理。不過(guò)，Lambda會(huì)將系統(tǒng)中最復(fù)雜的部分，限制在速度層中。而由于該層面的輸出是臨時(shí)的，因此如果您需要對(duì)數(shù)據(jù)進(jìn)行改進(jìn)或校正，則可以每隔幾小時(shí)清空一次。
Lambda體系架構(gòu)的工作原理
- Lambda體系架構(gòu)的第一層--批處理層 ，既可以存儲(chǔ)整個(gè)數(shù)據(jù)集，又能夠計(jì)算出批處理的視圖。由于此處的存儲(chǔ)數(shù)據(jù)集不可被改變，因此只能被追加。也就是說(shuō)，新的數(shù)據(jù)會(huì)不斷地被傳入，而原有舊的數(shù)據(jù)則會(huì)始終保持不變。同時(shí)，批處理層會(huì)通過(guò)對(duì)整個(gè)數(shù)據(jù)集的查詢，或功能性計(jì)算，得出各種視圖。查詢這些視圖時(shí)，我們雖然可以在整個(gè)數(shù)據(jù)集中低延遲地找到答案，但是其缺點(diǎn)是系統(tǒng)需要花費(fèi)大量的時(shí)間，來(lái)進(jìn)行計(jì)算。
- Lambda體系架構(gòu)的第二層--服務(wù)層，能夠批量加載視圖。與傳統(tǒng)數(shù)據(jù)庫(kù)相似，它通過(guò)對(duì)視圖的只讀查詢操作，來(lái)提供低延遲的響應(yīng)。一旦批處理層準(zhǔn)備好一組新的視圖，服務(wù)層就會(huì)將當(dāng)前已過(guò)時(shí)的批處理視圖予以替換。
- 流到批處理層的數(shù)據(jù)，同樣也會(huì)流入Lambda體系架構(gòu)的第三層--速度層。其主要區(qū)別在于，盡管批處理層從開(kāi)始就保留了所有數(shù)據(jù)，但是速度層僅關(guān)心從最后一批視圖完成以來(lái)到達(dá)的數(shù)據(jù)。也就是說(shuō)，速度層通過(guò)處理那些批處理視圖尚未計(jì)入的最新數(shù)據(jù)查詢，來(lái)彌補(bǔ)計(jì)算視圖時(shí)的高延遲。具體原理如下圖所示：
比方說(shuō)明三個(gè)層面
為了更好地理解上述概念，讓我們來(lái)打個(gè)比方：在一位老人的豪宅里，每個(gè)房間都有一個(gè)時(shí)鐘。但是，除了廚房里的時(shí)鐘外，其他時(shí)鐘都是不準(zhǔn)的。他需要以廚房里的時(shí)鐘為基準(zhǔn)去校準(zhǔn)其他時(shí)鐘。不過(guò)，由于記憶力差，他必須將廚房時(shí)鐘上的當(dāng)前時(shí)間(上午9:04)記在一張紙上。然后，他以緩慢的步伐走向各個(gè)房間，將所有時(shí)鐘設(shè)定為上午9:04。而當(dāng)他最后到達(dá)東廂房時(shí)，實(shí)際時(shí)間已經(jīng)是上午9:51了。顯然，他后續(xù)在各個(gè)房間時(shí)鐘上設(shè)置的上午9:04，都是錯(cuò)誤。
同理，如果數(shù)據(jù)系統(tǒng)只有批處理層，那么我們就會(huì)遇到類似的問(wèn)題—由于需要花費(fèi)一段時(shí)間才能得到某個(gè)問(wèn)題的答案，因此該答案對(duì)于持續(xù)涌入的數(shù)據(jù)并非最新。
讓我們回到剛才的例子，幸虧這位老人手上有一只秒表。次日上午9:04，他同樣從廚房開(kāi)始，在一張紙上記下時(shí)間，并啟動(dòng)秒表(也就是他的“速度層”)。當(dāng)最后到達(dá)東廂房時(shí)，他的秒表上顯示為“47分16秒”。通過(guò)基本數(shù)學(xué)計(jì)算，他可以知道當(dāng)前的時(shí)鐘應(yīng)該被設(shè)置為9:51 AM。
在上述類比中，老人是服務(wù)層，其豪宅里各個(gè)房間的時(shí)鐘隨處可以顯示當(dāng)前時(shí)間的批處理視圖。當(dāng)然，他通過(guò)觸發(fā)秒表，讓批處理視圖會(huì)與速度層同步，以獲得最準(zhǔn)確的答案。
為什么要使用Lambda體系架構(gòu)?
在Marz和Warren有關(guān)Lambda架構(gòu)的開(kāi)創(chuàng)性著作--《大數(shù)據(jù)》中，他們列出了大數(shù)據(jù)系統(tǒng)中的八個(gè)理想屬性，也描述了Lambda架構(gòu)如何去滿足每一種屬性：
- 魯棒性和容錯(cuò)能力。由于批處理層被設(shè)計(jì)為追加式，即包含了自開(kāi)始以來(lái)的整體數(shù)據(jù)集，因此該系統(tǒng)具有一定的容錯(cuò)能力。如果任何數(shù)據(jù)被損壞，該架構(gòu)則可以刪除從損壞點(diǎn)以來(lái)的所有數(shù)據(jù)，并替換為正確的數(shù)據(jù)。同時(shí)，批處理視圖也可以被換成完全被重新計(jì)算出的視圖。而且速度層可以被丟棄。此外，在生成一組新的批處理視圖的同時(shí)，該架構(gòu)可以重置整個(gè)系統(tǒng)，使之重新運(yùn)行。
- 可擴(kuò)展性。Lambda體系架構(gòu)的設(shè)計(jì)層是作為分布式系統(tǒng)被構(gòu)建的。因此，通過(guò)簡(jiǎn)單地添加更多的主機(jī)，最終用戶可以輕松地對(duì)系統(tǒng)進(jìn)行水平擴(kuò)展。
- 通用性。由于Lambda體系架構(gòu)是一般范式，因此用戶并不會(huì)被鎖定在計(jì)算批處理視圖的某個(gè)特定方式中。而且批處理視圖和速度層的計(jì)算，可以被設(shè)計(jì)為滿足某個(gè)數(shù)據(jù)系統(tǒng)的特定需求。
- 延展性。隨著新的數(shù)據(jù)類型被導(dǎo)入，數(shù)據(jù)系統(tǒng)也會(huì)產(chǎn)生新的視圖。數(shù)據(jù)系統(tǒng)不會(huì)被鎖定在某類、或一定數(shù)量的批處理視圖中。新的視圖會(huì)在完成編碼之后，被添加到系統(tǒng)中，其對(duì)應(yīng)的資源也會(huì)得到輕松地延展。
- 按需查詢。如有必要，批處理層可以在缺少批處理視圖時(shí)，支持臨時(shí)查詢。如果用戶可以接受臨時(shí)查詢的高延遲，那么批處理層的用途就不僅限于生成的批處理視圖了。
- 最少的維護(hù)。Lambda架構(gòu)的典型模式是：批處理層使用Apache Hadoop，而服務(wù)層使用ElephantDB。顯然，兩者都很容易被維護(hù)。
- 可調(diào)試性。Lambda體系架構(gòu)通過(guò)每一層的輸入和輸出，極大地簡(jiǎn)化了計(jì)算和查詢的調(diào)試。
- 低延遲的讀取和更新。在Lambda體系架構(gòu)中，速度層為大數(shù)據(jù)系統(tǒng)提供了對(duì)于最新數(shù)據(jù)集的實(shí)時(shí)查詢。
Lambda體系架構(gòu)的缺點(diǎn)
事物往往都有兩面性，Lambda架構(gòu)除了具有上述優(yōu)點(diǎn)，也存在著如下缺點(diǎn)：
- 由于所有數(shù)據(jù)都是被追加進(jìn)來(lái)，并且批處理層中的任何數(shù)據(jù)都不會(huì)被丟棄，因此系統(tǒng)的擴(kuò)展成本必然會(huì)隨著時(shí)間的推移而增長(zhǎng)。
- 如前文所述，批處理層可使用Hadoop或Snowflake，而速度層則可以使用Storm或Spark。顯然，這兩層雖然運(yùn)行同一組數(shù)據(jù)，但是它們是在完全不同的系統(tǒng)上構(gòu)建的。因此，用戶需要維護(hù)兩套相互獨(dú)立的系統(tǒng)代碼。這樣不但復(fù)雜，而且極具一定的挑戰(zhàn)性。
機(jī)器學(xué)習(xí)中的Lambda架構(gòu)
在機(jī)器學(xué)習(xí)領(lǐng)域，數(shù)據(jù)量無(wú)疑是多多益善的。但是，對(duì)于機(jī)器學(xué)習(xí)應(yīng)用算法、以及檢測(cè)模式而言，它們需要以一種有意義的方式，去接收數(shù)據(jù)。因此，機(jī)器學(xué)習(xí)可以受益于由Lambda架構(gòu)構(gòu)建的數(shù)據(jù)系統(tǒng)，所處理的各類數(shù)據(jù)。據(jù)此，機(jī)器學(xué)習(xí)算法可以提出各種問(wèn)題，并逐漸對(duì)輸入到系統(tǒng)中的數(shù)據(jù)進(jìn)行模式識(shí)別。
物聯(lián)網(wǎng)的Lambda架構(gòu)
如果說(shuō)機(jī)器學(xué)習(xí)利用的是Lambda架構(gòu)的輸出，那么物聯(lián)網(wǎng)則更多地使用到了數(shù)據(jù)系統(tǒng)的輸入。設(shè)想一下，一個(gè)擁有數(shù)百萬(wàn)輛汽車的城市，每輛汽車都裝有傳感器，并能夠發(fā)送有關(guān)天氣、空氣質(zhì)量、交通狀況、位置信息、以及司機(jī)駕駛習(xí)慣等數(shù)據(jù)。這些海量數(shù)據(jù)流，會(huì)被實(shí)時(shí)饋入Lambda體系架構(gòu)的批處理層和速度層，進(jìn)行后續(xù)處理。可以說(shuō)，物聯(lián)網(wǎng)設(shè)備是合理使用大數(shù)據(jù)源的絕佳示例。
流處理和Lambda架構(gòu)挑戰(zhàn)
速度層也被稱為“流處理層”。其目標(biāo)是提供最新數(shù)據(jù)的低延遲實(shí)時(shí)視圖。雖說(shuō)，速度層僅關(guān)心，自完成最后一組批處理視圖以來(lái)導(dǎo)入的數(shù)據(jù)，但事實(shí)上它不會(huì)存儲(chǔ)這些小部分的數(shù)據(jù)。這些數(shù)據(jù)在流入時(shí)就會(huì)被立即處理，且在完成后被立即丟棄。因此，我們可以認(rèn)為這些數(shù)據(jù)是尚未被批處理視圖所計(jì)入的數(shù)據(jù)。
Lambda體系架構(gòu)在其原始理論中，提到了“最終精度(eventual accuracy)”的概念。它是指：批處理層更關(guān)注精確計(jì)算，而速度層則關(guān)注近似計(jì)算。此類近似計(jì)算最終將由下一組視圖所取代，以便系統(tǒng)向“最終精度”邁進(jìn)。
在實(shí)際應(yīng)用中，由實(shí)時(shí)處理流以毫秒為單位，持續(xù)產(chǎn)生的用于更新視圖的數(shù)據(jù)流，是一個(gè)非常復(fù)雜的過(guò)程。在此，我建議您將基于文檔的數(shù)據(jù)庫(kù)、索引、以及查詢系統(tǒng)配合在一起使用。
Lambda架構(gòu)和Kappa架構(gòu)之間的差異
如上所述，由于Lambda體系架構(gòu)的批處理層和速度層分屬不同的分布式系統(tǒng)，我們需要為相似的處理方式，維護(hù)兩個(gè)單獨(dú)的代碼庫(kù)。而Kappa架構(gòu)則通過(guò)完全刪除批處理層，來(lái)解決該問(wèn)題。
具體而言，Kappa使用單個(gè)流處理層，既通過(guò)最新的數(shù)據(jù)計(jì)算來(lái)產(chǎn)生實(shí)時(shí)視圖，又對(duì)所有數(shù)據(jù)進(jìn)行計(jì)算，以產(chǎn)生批處理視圖。就整個(gè)數(shù)據(jù)集而言，它以追加日志的形式保持原有數(shù)據(jù)不變，并且保證數(shù)據(jù)能夠快速地流過(guò)系統(tǒng)，以產(chǎn)生具有精確計(jì)算的視圖。同時(shí)，來(lái)自Lambda架構(gòu)的原始“速度層”任務(wù)，也會(huì)被保留在Kappa 架構(gòu)中，并持續(xù)為低延遲的視圖提供近似計(jì)算。據(jù)此，這種為單個(gè)系統(tǒng)生成視圖的方式，大幅簡(jiǎn)化了系統(tǒng)的代碼庫(kù)。
通過(guò)Heroku上的容器實(shí)現(xiàn)Lambda體系架構(gòu)
通過(guò)使用Docker，我們可以輕松地在啟動(dòng)和試驗(yàn)階段，完成對(duì)Lambda架構(gòu)所需的各種工具的協(xié)調(diào)和部署。例如，我們可以使用基于容器的云平臺(tái)即服務(wù)(PaaS)--Heroku，來(lái)部署和擴(kuò)展應(yīng)用程序。對(duì)于批處理層，您可以使用Apache Hadoop來(lái)部署一個(gè)Docker容器;針對(duì)速度層，您可以考慮部署Apache Storm或Apache Spark;而對(duì)于服務(wù)層，您可以為Apache Cassandra或MongoDB部署Docker容器，并通過(guò)Elasticsearch來(lái)進(jìn)行索引和查詢。
結(jié)論
綜上所述，Lambda架構(gòu)之類的范例具有一定的擴(kuò)展性和魯棒性。隨著大量數(shù)據(jù)流不斷地被導(dǎo)入數(shù)據(jù)系統(tǒng)，批處理層提供了高延遲的精度，而速度層提供了低延遲近似值。同時(shí)，速度層通過(guò)協(xié)調(diào)兩種視圖，來(lái)為查詢提供最佳的響應(yīng)。當(dāng)然，使用Lambda架構(gòu)來(lái)實(shí)施數(shù)據(jù)系統(tǒng)并非易事，我們往往需要借助適當(dāng)?shù)墓ぞ撸瑏?lái)實(shí)現(xiàn)部署與構(gòu)建。
原文標(biāo)題：An Overview of Lambda Architecture，作者: Michael Bogan
【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】
