上圖就是lambda結構的一個示意, 來自圖書Big Data Principles and best practices of scalable realtime data system, 該書的作者就是lambda架構的創造者Nathan Marz。

大資料的技術手段百花齊放, 各種NoSQL資料庫或者分散式計算框架層出不窮, 但是很少有理論來講一講應該怎麼把這些元件有機地組合起來, lambda框架應運而生, 是一種理論指導大資料專案的頂層設計, 幫助企業以資料來驅動。

從業務的角度來思考對於資料的應用有不同的時效性要求, 有的資料比如 E-commerce ，時效性要求非常高, 有的資料比如客戶畫像分析 對時效性要求比較低. 道理很簡單, 電商的促銷推薦瞬息萬變, 而客戶的行為畫像變得很慢(並不是每天都有人從工薪階層變成百萬富翁，從單身漢突然變成已婚人士)。

lambda架構從這點出發, 有兩套解決辦法, 正如圖上的兩條分支, 一條叫Speed Layer 顧名思義 快速的處理實時資料以供查詢, 而另一條分支, 又分作兩層(Batch Layer & Serving Layer) 處理那些對時效性要求不高的資料。

Speed Layer處理實時資料 代價是對計算資源要求很高, 而且邏輯複雜度也會很高， 通常採用的技術比如 Redis，Storm，Kafka，Spark Streaming等。而另外兩層使用的典型技術比如MR或Spark，Hive。這條路線處理延遲比較大， 結果邏輯相對簡單，往往把它的處理叫做“離線處理”， 與Speed Layer的“實時處理”相對應。這種設計被稱作：Complexity Isolation（複雜度分離）。

兩者其實是相輔相成的, Batch Layer會持續地吸收增量資料加以處理（比如漸變維度，增加索引，劃分分割槽，預計算聚合值等操作）, 當新增資料被Batch Layer處理完成後, 它們的分析就不再由Speed Layer處理了（交由Serving Layer處理），所以保證了Speed Layer處理的歷史資料量永遠不會太大，畢竟對於Speed Layer來說 “快” 是關鍵。

在另一些場景下, 比如在使用者瀏覽購物網站時的推薦系統, 會結合實時分析結果和離線處理結果: 以電商為例, 使用者給購物車加了一件商品，根據這個操作"實時處理"會向用戶做出推薦（使用者把一條裙子加入購物車，立刻推薦這條裙子的搭配商品比如一雙鞋子），但同時也要結合使用者歷史的行為來做推薦（使用者喜歡紅色，腳的尺碼M）, 這依賴於離線處理的結果。兩者結合（該鞋子的紅色款且尺碼M）就是終端使用者在網頁上看到的推薦商品列表。

以上就是Lambda框架的簡介。