[[384949]]

【51CTO.com快譯】如今，物聯(lián)網(wǎng)(IoT)、社交媒體、應(yīng)用程序、以及分析設(shè)備，都在持續(xù)產(chǎn)生著各種類型的海量數(shù)據(jù)。而我們的業(yè)務(wù)系統(tǒng)需要每天接收各種大數(shù)據(jù)，并完成各項處理任務(wù)。因此，在日常處理這些持續(xù)增長的數(shù)據(jù)時，數(shù)據(jù)系統(tǒng)會面臨延遲和準確性兩個方面的挑戰(zhàn)。

Lambda架構(gòu)的介紹

針對上述挑戰(zhàn)，Nathan Marz和James Warren于2015年首發(fā)了Lambda體系架構(gòu)。它在邏輯上將數(shù)據(jù)系統(tǒng)分為三個層面，即：批處理(batch)層、速度(speed)層和服務(wù)(serving)層。而作為一種大數(shù)據(jù)的范例，它可以讓用戶通過構(gòu)建數(shù)據(jù)系統(tǒng)，以克服上述數(shù)據(jù)延遲與準確性等問題。

由于Lambda體系架構(gòu)可以被水平擴展，因此如果您的數(shù)據(jù)集過大，或所需的數(shù)據(jù)視圖過多，則可以通過添加更多的主機來參與處理。不過，Lambda會將系統(tǒng)中最復(fù)雜的部分，限制在速度層中。而由于該層面的輸出是臨時的，因此如果您需要對數(shù)據(jù)進行改進或校正，則可以每隔幾小時清空一次。

Lambda體系架構(gòu)的工作原理

• Lambda體系架構(gòu)的第一層--批處理層 ，既可以存儲整個數(shù)據(jù)集，又能夠計算出批處理的視圖。由于此處的存儲數(shù)據(jù)集不可被改變，因此只能被追加。也就是說，新的數(shù)據(jù)會不斷地被傳入，而原有舊的數(shù)據(jù)則會始終保持不變。同時，批處理層會通過對整個數(shù)據(jù)集的查詢，或功能性計算，得出各種視圖。查詢這些視圖時，我們雖然可以在整個數(shù)據(jù)集中低延遲地找到答案，但是其缺點是系統(tǒng)需要花費大量的時間，來進行計算。
• Lambda體系架構(gòu)的第二層--服務(wù)層，能夠批量加載視圖。與傳統(tǒng)數(shù)據(jù)庫相似，它通過對視圖的只讀查詢操作，來提供低延遲的響應(yīng)。一旦批處理層準備好一組新的視圖，服務(wù)層就會將當(dāng)前已過時的批處理視圖予以替換。
• 流到批處理層的數(shù)據(jù)，同樣也會流入Lambda體系架構(gòu)的第三層--速度層。其主要區(qū)別在于，盡管批處理層從開始就保留了所有數(shù)據(jù)，但是速度層僅關(guān)心從最后一批視圖完成以來到達的數(shù)據(jù)。也就是說，速度層通過處理那些批處理視圖尚未計入的最新數(shù)據(jù)查詢，來彌補計算視圖時的高延遲。具體原理如下圖所示：

比方說明三個層面

為了更好地理解上述概念，讓我們來打個比方：在一位老人的​​豪宅里，每個房間都有一個時鐘。但是，除了廚房里的時鐘外，其他時鐘都是不準的。他需要以廚房里的時鐘為基準去校準其他時鐘。不過，由于記憶力差，他必須將廚房時鐘上的當(dāng)前時間(上午9:04)記在一張紙上。然后，他以緩慢的步伐走向各個房間，將所有時鐘設(shè)定為上午9:04。而當(dāng)他最后到達東廂房時，實際時間已經(jīng)是上午9:51了。顯然，他后續(xù)在各個房間時鐘上設(shè)置的上午9:04，都是錯誤。

同理，如果數(shù)據(jù)系統(tǒng)只有批處理層，那么我們就會遇到類似的問題—由于需要花費一段時間才能得到某個問題的答案，因此該答案對于持續(xù)涌入的數(shù)據(jù)并非最新。

讓我們回到剛才的例子，幸虧這位老人手上有一只秒表。次日上午9:04，他同樣從廚房開始，在一張紙上記下時間，并啟動秒表(也就是他的“速度層”)。當(dāng)最后到達東廂房時，他的秒表上顯示為“47分16秒”。通過基本數(shù)學(xué)計算，他可以知道當(dāng)前的時鐘應(yīng)該被設(shè)置為9:51 AM。

在上述類比中，老人是服務(wù)層，其豪宅里各個房間的時鐘隨處可以顯示當(dāng)前時間的批處理視圖。當(dāng)然，他通過觸發(fā)秒表，讓批處理視圖會與速度層同步，以獲得最準確的答案。

為什么要使用Lambda體系架構(gòu)?

在Marz和Warren有關(guān)Lambda架構(gòu)的開創(chuàng)性著作--《大數(shù)據(jù)》中，他們列出了大數(shù)據(jù)系統(tǒng)中的八個理想屬性，也描述了Lambda架構(gòu)如何去滿足每一種屬性：

• 魯棒性和容錯能力。由于批處理層被設(shè)計為追加式，即包含了自開始以來的整體數(shù)據(jù)集，因此該系統(tǒng)具有一定的容錯能力。如果任何數(shù)據(jù)被損壞，該架構(gòu)則可以刪除從損壞點以來的所有數(shù)據(jù)，并替換為正確的數(shù)據(jù)。同時，批處理視圖也可以被換成完全被重新計算出的視圖。而且速度層可以被丟棄。此外，在生成一組新的批處理視圖的同時，該架構(gòu)可以重置整個系統(tǒng)，使之重新運行。
• 可擴展性。Lambda體系架構(gòu)的設(shè)計層是作為分布式系統(tǒng)被構(gòu)建的。因此，通過簡單地添加更多的主機，最終用戶可以輕松地對系統(tǒng)進行水平擴展。
• 通用性。由于Lambda體系架構(gòu)是一般范式，因此用戶并不會被鎖定在計算批處理視圖的某個特定方式中。而且批處理視圖和速度層的計算，可以被設(shè)計為滿足某個數(shù)據(jù)系統(tǒng)的特定需求。
• 延展性。隨著新的數(shù)據(jù)類型被導(dǎo)入，數(shù)據(jù)系統(tǒng)也會產(chǎn)生新的視圖。數(shù)據(jù)系統(tǒng)不會被鎖定在某類、或一定數(shù)量的批處理視圖中。新的視圖會在完成編碼之后，被添加到系統(tǒng)中，其對應(yīng)的資源也會得到輕松地延展。
• 按需查詢。如有必要，批處理層可以在缺少批處理視圖時，支持臨時查詢。如果用戶可以接受臨時查詢的高延遲，那么批處理層的用途就不僅限于生成的批處理視圖了。
• 最少的維護。Lambda架構(gòu)的典型模式是：批處理層使用Apache Hadoop，而服務(wù)層使用ElephantDB。顯然，兩者都很容易被維護。
• 可調(diào)試性。Lambda體系架構(gòu)通過每一層的輸入和輸出，極大地簡化了計算和查詢的調(diào)試。
• 低延遲的讀取和更新。在Lambda體系架構(gòu)中，速度層為大數(shù)據(jù)系統(tǒng)提供了對于最新數(shù)據(jù)集的實時查詢。

Lambda體系架構(gòu)的缺點

事物往往都有兩面性，Lambda架構(gòu)除了具有上述優(yōu)點，也存在著如下缺點：

• 由于所有數(shù)據(jù)都是被追加進來，并且批處理層中的任何數(shù)據(jù)都不會被丟棄，因此系統(tǒng)的擴展成本必然會隨著時間的推移而增長。
• 如前文所述，批處理層可使用Hadoop或Snowflake，而速度層則可以使用Storm或Spark。顯然，這兩層雖然運行同一組數(shù)據(jù)，但是它們是在完全不同的系統(tǒng)上構(gòu)建的。因此，用戶需要維護兩套相互獨立的系統(tǒng)代碼。這樣不但復(fù)雜，而且極具一定的挑戰(zhàn)性。

機器學(xué)習(xí)中的Lambda架構(gòu)

在機器學(xué)習(xí)領(lǐng)域，數(shù)據(jù)量無疑是多多益善的。但是，對于機器學(xué)習(xí)應(yīng)用算法、以及檢測模式而言，它們需要以一種有意義的方式，去接收數(shù)據(jù)。因此，機器學(xué)習(xí)可以受益于由Lambda架構(gòu)構(gòu)建的數(shù)據(jù)系統(tǒng)，所處理的各類數(shù)據(jù)。據(jù)此，機器學(xué)習(xí)算法可以提出各種問題，并逐漸對輸入到系統(tǒng)中的數(shù)據(jù)進行模式識別。

物聯(lián)網(wǎng)的Lambda架構(gòu)

如果說機器學(xué)習(xí)利用的是Lambda架構(gòu)的輸出，那么物聯(lián)網(wǎng)則更多地使用到了數(shù)據(jù)系統(tǒng)的輸入。設(shè)想一下，一個擁有數(shù)百萬輛汽車的城市，每輛汽車都裝有傳感器，并能夠發(fā)送有關(guān)天氣、空氣質(zhì)量、交通狀況、位置信息、以及司機駕駛習(xí)慣等數(shù)據(jù)。這些海量數(shù)據(jù)流，會被實時饋入Lambda體系架構(gòu)的批處理層和速度層，進行后續(xù)處理?？梢哉f，物聯(lián)網(wǎng)設(shè)備是合理使用大數(shù)據(jù)源的絕佳示例。

流處理和Lambda架構(gòu)挑戰(zhàn)

速度層也被稱為“流處理層”。其目標是提供最新數(shù)據(jù)的低延遲實時視圖。雖說，速度層僅關(guān)心，自完成最后一組批處理視圖以來導(dǎo)入的數(shù)據(jù)，但事實上它不會存儲這些小部分的數(shù)據(jù)。這些數(shù)據(jù)在流入時就會被立即處理，且在完成后被立即丟棄。因此，我們可以認為這些數(shù)據(jù)是尚未被批處理視圖所計入的數(shù)據(jù)。

Lambda體系架構(gòu)在其原始理論中，提到了“最終精度(eventual accuracy)”的概念。它是指：批處理層更關(guān)注精確計算，而速度層則關(guān)注近似計算。此類近似計算最終將由下一組視圖所取代，以便系統(tǒng)向“最終精度”邁進。

在實際應(yīng)用中，由實時處理流以毫秒為單位，持續(xù)產(chǎn)生的用于更新視圖的數(shù)據(jù)流，是一個非常復(fù)雜的過程。在此，我建議您將基于文檔的數(shù)據(jù)庫、索引、以及查詢系統(tǒng)配合在一起使用。

Lambda架構(gòu)和Kappa架構(gòu)之間的差異

如上所述，由于Lambda體系架構(gòu)的批處理層和速度層分屬不同的分布式系統(tǒng)，我們需要為相似的處理方式，維護兩個單獨的代碼庫。而Kappa架構(gòu)則通過完全刪除批處理層，來解決該問題。

具體而言，Kappa使用單個流處理層，既通過最新的數(shù)據(jù)計算來產(chǎn)生實時視圖，又對所有數(shù)據(jù)進行計算，以產(chǎn)生批處理視圖。就整個數(shù)據(jù)集而言，它以追加日志的形式保持原有數(shù)據(jù)不變，并且保證數(shù)據(jù)能夠快速地流過系統(tǒng)，以產(chǎn)生具有精確計算的視圖。同時，來自Lambda架構(gòu)的原始“速度層”任務(wù)，也會被保留在Kappa 架構(gòu)中，并持續(xù)為低延遲的視圖提供近似計算。據(jù)此，這種為單個系統(tǒng)生成視圖的方式，大幅簡化了系統(tǒng)的代碼庫。

通過Heroku上的容器實現(xiàn)Lambda體系架構(gòu)

通過使用Docker，我們可以輕松地在啟動和試驗階段，完成對Lambda架構(gòu)所需的各種工具的協(xié)調(diào)和部署。例如，我們可以使用基于容器的云平臺即服務(wù)(PaaS)--Heroku，來部署和擴展應(yīng)用程序。對于批處理層，您可以使用Apache Hadoop來部署一個Docker容器;針對速度層，您可以考慮部署Apache Storm或Apache Spark;而對于服務(wù)層，您可以為Apache Cassandra或MongoDB部署Docker容器，并通過Elasticsearch來進行索引和查詢。

結(jié)論

綜上所述，Lambda架構(gòu)之類的范例具有一定的擴展性和魯棒性。隨著大量數(shù)據(jù)流不斷地被導(dǎo)入數(shù)據(jù)系統(tǒng)，批處理層提供了高延遲的精度，而速度層提供了低延遲近似值。同時，速度層通過協(xié)調(diào)兩種視圖，來為查詢提供最佳的響應(yīng)。當(dāng)然，使用Lambda架構(gòu)來實施數(shù)據(jù)系統(tǒng)并非易事，我們往往需要借助適當(dāng)?shù)墓ぞ撸瑏韺崿F(xiàn)部署與構(gòu)建。

原文標題：An Overview of Lambda Architecture，作者: Michael Bogan

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】