一、Lambda架構需求

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

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

二、Lambda架構的關鍵

橫向擴容

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

故障容錯

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

低延遲

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

可擴展

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

易維護

開發(fā)部署不能夠太復雜。

三、Lambda架構的分層

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

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

數(shù)據(jù)源

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

數(shù)據(jù)消費層

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

批處理層

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

實時層

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

服務層

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

四、Lambda架構總結

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

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

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

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

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

批處理的健壯性

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

開發(fā)和維護的復雜

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

存儲增長快

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

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

作者：數(shù)據(jù)社 專注MPP數(shù)據(jù)庫研究、流處理計算、數(shù)據(jù)倉庫架構和數(shù)據(jù)分析