一、Lambda架構需求

Lambda架構背后的需求是由于MR架構的延遲問題。MR雖然實現了分布式、可擴展數據處理系統的目的，但是在處理數據時延遲比較嚴重。實際上如果內存和CPU足夠強大，MR也可以實現近實時運算，但實際業務環境并非如此，因此我們需要權衡，選擇實時處理和批處理所需要數據量和恰當的資源。

2012年Storm的作者Nathan Marz提出的Lambda數據處理框架。Lambda架構的目標是設計出一個能滿足實時大數據系統關鍵特性的架構，包括有：高容錯、低延時和可擴展等。Lambda架構整合離線計算和實時計算，融合不可變性（Immunability），讀寫分離和復雜性隔離等一系列架構原則，可集成Hadoop，Kafka，Storm，Spark，Hbase等各類大數據組件。

二、Lambda架構的關鍵

橫向擴容

可擴展性意味著為滿足日益增長的用戶服務需求，同時不用對底層架構或者代碼，可以通過現有機器添加內存或者磁盤資源來實現（垂直擴展），或者可以通過在集群中添加機器實現（水平擴展）。無論是實時或者批處理，都應該能夠不停服務的情況下，可以實施水平擴展。

故障容錯

系統需要妥善處理故障，確保系統在某些組件發生故障的情況下，整個系統服務的可用性。可能部分組件故障會導致集群中部分節點宕機，影響了整理的SLA，但是系統還是可以相應的，系統不能有單點故障。

低延遲

很多應用對于讀和寫操作的延時要求非常高，要求對更新和查詢的響應是低延時的。

可擴展

系統需要足夠靈活，能夠實現新增和修改需求，又不需要重構整個系統。實時處理和批處理隔離開，能夠靈活修改需求。

易維護

開發部署不能夠太復雜。

三、Lambda架構的分層

在Lambda架構中新數據到達時，會被同時分派到批處理層和快速處理層。一旦數據到達批處理層，按照常規批處理時間間隔，每次都從頭開始重新計算并生成批處理視圖。類似地，只要新數據到達快速處理層，快速處理層就會使用新數據生成快速視圖。在查詢到達服務層時，它會合并快速視圖和批處理視圖來生成適當的查詢結果。生成批處理視圖后，快速視圖將被丟棄，除非有新數據抵達，否則只需要查詢批處理視圖，因為此時批處理層中擁有所有的數據。

Lambda架構定義主要層以及每個組件之間的集成。注意分為以下層：

數據源

數據源指外部的數據庫、消息隊列、文件等，可以開發數據消費層，隱藏來自不同訪問數據的復雜性，定義好數據格式。

數據消費層

負責封裝不能數據源獲取數據的復雜性，將其轉換可由批處理或者流處理進一步使用同一的格式進行消費。

批處理層

這是Lambda架構核心層之一，批處理接受數據，持久化到用戶定義好的數據結構中，維護著主數據。數據結構一般不做改變，只是追加數據。批處理還負責創建和維護批處理視圖。比如我們常做的Hive ETL ，統計一些數據，最后將結果保存在hive表中，或者數據庫中，就屬于批處理層。

實時層

這是Lambda另一個核心層。批處理在很多場景下能夠滿足需求，但是隨著業務需求“苛刻性”，他們希望能夠及時看到數據，而不是等到第二天才看指標變化和分析結果。所以引入了實時處理。實時層解決了一個問題，即只存儲可立即向用戶提供的一組數據，這樣就不需要對全量數據進行處理，大大提供處理效率。比如流處理僅僅存儲最近5分鐘的數據，處理計算并形成結果，這就是我們用spark streaming中要有的時間窗口。

服務層

這是Lambda架構的最后一層，服務層的職責是獲取批處理和流處理的結果，向用戶提供統一查詢視圖服務。

四、Lambda架構總結

Lambda數據架構曾經成為每一個公司大數據平臺必備的架構，它解決了一個公司大數據批量離線處理和實時數據處理的需求。

數據從底層的數據源開始，經過各種各樣的格式進入大數據平臺，在大數據平臺中經過Kafka、Flume等數據組件進行收集，然后分成兩條線進行計算。一條線是進入流式計算平臺（例如 Storm、Flink或者Spark Streaming），去計算實時的一些指標;另一條線進入批量數據處理離線計算平臺（例如Mapreduce、Hive，Spark SQL），去計算T+1的相關業務指標，這些指標需要隔日才能看見。

Lambda架構經歷多年的發展，非常穩定，對于實時計算部分的計算成本可控，批量處理可以用晚上的時間來整體批量計算，這樣把實時計算和離線計算高峰分開，這種架構支撐了數據行業的早期發展，但是它也有一些致命缺點：

實時與批量計算結果不一致

因為批量和實時計算走的是兩個計算框架和計算程序，算出的結果往往不同，經常看到一個數字當天看是一個數據，第二天看昨天的數據反而發生了變化。

批處理的健壯性

隨著數據量級越來越大，經常發現夜間只有4、5個小時的時間窗口，已經無法完成白天20多個小時累計的數據，保證早上上班前準時出數據已成為每個大數據團隊頭疼的問題，同時做個任務并行執行對于大數據集群的穩定性也是巨大的考驗，經常會有任務因為資源不足沒有定時啟動或者報錯。

開發和維護的復雜

Lambda 架構中對同樣的業務邏輯進行兩次編程：一次為批量計算的ETL系統，一次為流式計算的Streaming系統。針對同一個業務問題產生了兩個代碼庫，各有不同的漏洞。

存儲增長快

數據倉庫的設計不合理，會產生大量的中間結果表，造成數據急速膨脹，加大服務器存儲壓力。比如我們經常糾結于數據倉庫到底怎么分層，是直接ODS層到應用呢？還是ODS層要景觀DWS、DW等，最后才到應用呢？

Lambda架構雖然有缺點，但是在很多公司依然適用，有時候我們沒有那么大的業務量，實時業務需求并沒有那么明顯，用著Lambda架構依然很爽。對于超大數據量的業務或者實時業務同樣多的情況，可以探索改良Lambda，業內也提出了Kappa架構，感興趣的小伙伴可以搜索學習下。
責編AJX