一、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架構，感興趣的小夥伴可以搜尋學習下。