大數據小視角4：小議Lambda 與 Kappa 架構，不可變數據的計算探索

這個系列文章以前由於私事荒廢了好久，繼續更新～～以前與老大談論架構時，老大和我聊了聊分佈式數據處理之中的Lambda結構，以前在《Designing Data-Intensive Applications》這本書之中，做者 Martin Kleppmann也在文中涉及到了經過重型批處理與靈活的流處理相結合的方式來構建分佈式計算系統。因此此次也是借這個機會從新梳理Lambda架構與後續由Jay Kreps提出改進的Kappa架構，結合我的對於數據系統的思考，展開聊一聊分佈式計算系統的一些設計思路。由不足之處，望多多指教........

1.Lambda架構

首先咱們來看看什麼是Lambda架構，Lambda演算在編程語言之中是一個編程範式，它遵循以下幾個特色：

• 一、數據的不可變性，任何對於數據的操做是沒有反作用。
• 二、數據的無依賴性，即對函數提供一樣的輸入，那麼函數老是返回一樣的結果。
• 三、函數是First Class，函數與其餘數據類型同樣，處於平等地位，能夠賦值給其餘變量，也能夠做爲參數，傳入另外一個函數，或者做爲別的函數的返回值。

來自Twitter的Nathan Marz，Marz認爲進行計算處理的大數據框架的本質邏輯與函數式編程的思路是不謀而合，因此Marz根據本身多年進行分佈式數據系統開發的經驗總結提出了Lambda架構。（Marz大神是AFS頂級項目Storm的做者，Storm做爲一個優秀的分佈式流處理系統）因此接下來咱們來看看Marz所提出的Lambda架構是怎麼樣:

Lambda架構提及來也很簡單，就是經過分佈式系統的組件搭建，設計出一個具備魯棒性，可擴展，低延時的分佈式計算系統。之因此稱之爲Lambda架構，就是它最爲核心的點就是理由了數據處理過程之中的不可變性與無依賴性。下圖展示了一個典型的Lambda架構的分層邏輯：

由上圖能夠看到，一個典型的Lambda架構的核心分爲三個層次：Batch Layer，Speed Layer和Serving Layer。

• Batch Layer
• Speed Layer
• Serving Layer

咱們來梳理一下他們是如何分工協助的：首先new data做爲整個數據系統的數據源頭，Batch Layer做爲數據的批處理層次對原始數據進行加工與處理，而且將處理的數據結果的Batch View輸入到Serving Layer。(這裏對應的是全量數據)
Speed Layer對於實時增長的數據進行處理，生成對增量數據計算結果的Realtime Views。（這裏對應的是增量數據）
最終用戶查詢是經過Batch View與Realtime View相結合的形式將最終結果呈現出來。

而且隨着時間的推移，Batch View的計算結果會逐漸替代Realtime View,而業務層能夠低延遲的訪問由Serving Layer提供的Batch View，也能夠經過Realtime View實時反饋業務結果。

咱們能夠看到在Lambda架構之中，全部的數據都須要知足知足不可變性與無依賴性，出現任何數據問題時，（如出錯，丟失等）只須要從新跑一遍算法就能夠恢復所需的數據了。

業務場景理解

下面筆者利用一個業務場景簡單闡述一下Lambda模式，以下的業務場景只是基於筆者對電商推薦的理解所表述的，對應電商未必實際之中就是採起筆者所闡述的模式：

1：下圖是筆者訪問x寶網首頁所展現的廣告頁面：

對於這個推薦數據，能夠理解爲經過Batch Layer對我我的歷史數據進行處理以後得出的Batch View推薦。（例如跑Spark Mllib或是Hadoop Mahout對歷史數據進行分析推薦的結果,跑這類算法一般費時費力，能夠經過提早計算的方式存入MySQL等，後續用戶訪問時能夠直接調用）

2：接下來筆者在x寶網搜索了MacBook pro和ThinkPad x207，對於實時搜索的數據，能夠做爲流數據實時的經過Speed Layer進行處理。（例如Storm這樣的流處理器）

3: 筆者切換回到x寶網的首頁，發現多了一個推薦廣告項目：Dell 8代CPU專業級顯卡，曬單還送愛奇藝半年卡。顯然實時流的Realtime View與Batch View共同組成的x寶網的推薦首頁內容，很好的反饋了用戶的實時需求：

小結

Lambda架構結合了實時處理與批處理的結果，很好的反饋了查詢需求，而且在速度和可靠性之間求取了平衡，具備足夠的擴展性。在Lambda架構之中，全部的查詢均可以定位成一個函數：

Query = Function（Data）

而Lambda架構將數據和計算系統進行細分：

Query = Batch（Old_Data） + RealTime（New_Data）

可是這種架構一樣存在一些問題：須要運維兩套不一樣的計算系統，而且合併查詢結果，這必定程序上帶來了複雜性的增長

2.Kappa架構

Lambda架構誕生以後，來自Linkedln的技術主管Jay Kreps提出了一些質疑，並在Lambda架構之上提出本身的改進版本，將其命名爲Kappa架構。

Lambda架構最麻煩的問題就在於：新的邏輯須要兩次編碼，而且在兩個系統中運行和調試代碼，須要多運維一個額外的系統。因此Kreps認爲Lambda架構試圖在兩個不一樣編程範式的頂部創建一個抽象層是很是難的。

而Kappa架構嘗試經過一個流處理系統來處理上述兩種邏輯，咱們來看看Kappa架構是怎麼樣去設計的：

Kappa架構經過流處理系統的並行機制，來提升並行以實現重複處理。可是不少人會以爲流式處理對於歷史數據的高吞吐量會力不從心，這裏Kreps給出的解決方案是：僅僅重複處理的完整日誌數據。加入須要重複處理30天數據，就利用Kafka保留到30天。

因此這裏是開闢另個流式處理來處理新的數據，輸出數據是直接輸出到一個新的輸出表。當這第二個流式處理完成以後，切換到新的表中進行讀取，而後中止舊的流式處理，再刪除舊的輸出表。

一樣的，筆者上文舉的例子，一樣也能經過Kappa架構來實現購物的廣告展現。Kappa架構最爲核心的是經過一個範式解決須要共同解決的問題。同時不須要引入額外計算系統進行運維。

3.小結

到此爲止，筆者也大體聊完兩種不一樣分佈式計算系統的架構。筆者認爲Lambda架構是一個優秀的解決分佈式計算的架構，但須要處理運維不一樣的大數據系統，而且額外編碼邏輯，對於開發者與運維人員都是一個較大的考驗。而Kappa架構簡化了這個模型，可是對於數據處理總歸很難拿出重型的批處理作一個完整數據計算，因此計算結果的準確性是有所限縮的。（也就是對於業務場景是挑剔的，我想也沒有一種架構是解決問題的銀彈，之間的取捨須要咱們開發人員進行完整的評估～～） 而Spark可以經過一個計算框架同時解決批處理計算與流計算的問題，是很值得開發與運維人員所關注的.........