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

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

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

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

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

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

開發部署不能夠太複雜。

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

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

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

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

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

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

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

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!