大數據處理中的Lambda架構和Kappa架構

首先咱們來看一個典型的互聯網大數據平臺的架構，以下圖所示：

在這張架構圖中，大數據平臺裏面向用戶的在線業務處理組件用褐色標示出來，這部分是屬於互聯網在線應用的部分，其餘藍色的部分屬於大數據相關組件，使用開源大數據產品或者本身開發相關大數據組件。

你能夠看到，大數據平臺由上到下，可分爲三個部分：數據採集、數據處理、數據輸出與展現。

數據採集

將應用程序產生的數據和日誌等同步到大數據系統中，因爲數據源不一樣，這裏的數據同步系統其實是多個相關係統的組合。數據庫同步一般用 Sqoop，日誌同步能夠選擇 Flume，打點採集的數據通過格式化轉換後經過 Kafka 等消息隊列進行傳遞。

不一樣的數據源產生的數據質量可能差異很大，數據庫中的數據也許能夠直接導入大數據系統就可使用了，而日誌和爬蟲產生的數據就須要進行大量的清洗、轉化處理纔能有效使用。
數據處理

這部分是大數據存儲與計算的核心，數據同步系統導入的數據存儲在 HDFS。MapReduce、Hive、Spark 等計算任務讀取 HDFS 上的數據進行計算，再將計算結果寫入 HDFS。

MapReduce、Hive、Spark 等進行的計算處理被稱做是離線計算，HDFS 存儲的數據被稱爲離線數據。在大數據系統上進行的離線計算一般針對（某一方面的）全體數據，好比針對歷史上全部訂單進行商品的關聯性挖掘，這時候數據規模很是大，須要較長的運行時間，這類計算就是離線計算。

除了離線計算，還有一些場景，數據規模也比較大，可是要求處理的時間卻比較短。好比淘寶要統計每秒產生的訂單數，以便進行監控和宣傳。這種場景被稱爲大數據流式計算，一般用 Storm、Spark Steaming 等流式大數據引擎來完成，能夠在秒級甚至毫秒級時間內完成計算。

數據輸出與展現

大數據計算產生的數據仍是寫入到 HDFS 中，但應用程序不可能到 HDFS 中讀取數據，因此必需要將 HDFS 中的數據導出到數據庫中。數據同步導出相對比較容易，計算產生的數據都比較規範，稍做處理就能夠用 Sqoop 之類的系統導出到數據庫。

這時，應用程序就能夠直接訪問數據庫中的數據，實時展現給用戶，好比展現給用戶關聯推薦的商品。

除了給用戶訪問提供數據，大數據還須要給運營和決策層提供各類統計報告，這些數據也寫入數據庫，被相應的後臺系統訪問。不少運營和管理人員，天天一上班，就是登陸後臺數據系統，查看前一天的數據報表，看業務是否正常。若是數據正常甚至上升，就能夠稍微輕鬆一點；若是數據下跌，焦躁而忙碌的一天立刻就要開始了。

將上面三個部分整合起來的是任務調度管理系統，不一樣的數據什麼時候開始同步，各類 MapReduce、Spark 任務如何合理調度才能使資源利用最合理、等待的時間又不至於過久，同時臨時的重要任務還可以儘快執行，這些都須要任務調度管理系統來完成。

上面講的這種大數據平臺架構也叫 Lambda 架構，是構建大數據平臺的一種常規架構原型方案。Lambda 架構原型請看下面的圖。

Lambda 架構

Lambda 架構（Lambda Architecture）是由 Twitter 工程師南森·馬茨（Nathan Marz）提出的大數據處理架構。這一架構的提出基於馬茨在 BackType 和 Twitter 上的分佈式數據處理系統的經驗。

Lambda 架構使開發人員可以構建大規模分佈式數據處理系統。它具備很好的靈活性和可擴展性，也對硬件故障和人爲失誤有很好的容錯性。

Lambda 架構總共由三層系統組成：批處理層（Batch Layer），速度處理層（Speed Layer），以及用於響應查詢的服務層（Serving Layer）。

在 Lambda 架構中，每層都有本身所肩負的任務。

批處理層存儲管理主數據集（不可變的數據集）和預先批處理計算好的視圖。

批處理層使用可處理大量數據的分佈式處理系統預先計算結果。它經過處理全部的已有歷史數據來實現數據的準確性。這意味着它是基於完整的數據集來從新計算的，可以修復任何錯誤，而後更新現有的數據視圖。輸出一般存儲在只讀數據庫中，更新則徹底取代現有的預先計算好的視圖。

速度處理層會實時處理新來的大數據。

速度層經過提供最新數據的實時視圖來最小化延遲。速度層所生成的數據視圖可能不如批處理層最終生成的視圖那樣準確或完整，但它們幾乎在收到數據後當即可用。而當一樣的數據在批處理層處理完成後，在速度層的數據就能夠被替代掉了。

本質上，速度層彌補了批處理層所致使的數據視圖滯後。好比說，批處理層的每一個任務都須要 1 個小時才能完成，而在這 1 個小時裏，咱們是沒法獲取批處理層中最新任務給出的數據視圖的。而速度層由於可以實時處理數據給出結果，就彌補了這 1 個小時的滯後。

全部在批處理層和速度層處理完的結果都輸出存儲在服務層中，服務層經過返回預先計算的數據視圖或從速度層處理構建好數據視圖來響應查詢。

例如廣告投放預測這種推薦系統通常都會用到Lambda架構。通常能作精準廣告投放的公司都會擁有海量用戶特徵、用戶歷史瀏覽記錄和網頁類型分類這些歷史數據的。業界比較流行的作法有在批處理層用Alternating Least Squares (ALS)算法，也就是Collaborative Filtering協同過濾算法，能夠得出與用戶特性一致其餘用戶感興趣的廣告類型，也能夠得出和用戶感興趣類型的廣告類似的廣告，而用k-means也能夠對客戶感興趣的廣告類型進行分類。

這裏的結果是批處理層的結果。在速度層中根據用戶的實時瀏覽網頁類型在以前分好類的廣告中尋找一些top K的廣告出來。最終服務層能夠結合速度層的top K廣告和批處理層中分類好的點擊率高的類似廣告，作出選擇投放給用戶。

Lambda 架構的不足

雖然 Lambda 架構使用起來十分靈活，而且能夠適用於不少的應用場景，但在實際應用的時候，Lambda 架構也存在着一些不足，主要表如今它的維護很複雜。

使用 Lambda 架構時，架構師須要維護兩個複雜的分佈式系統，而且保證他們邏輯上產生相同的結果輸出到服務層中。

咱們都知道，在分佈式框架中進行編程實際上是十分複雜的，尤爲是咱們還會針對不一樣的框架進行專門的優化。因此幾乎每個架構師都認同，Lambda 架構在實戰中維護起來具備必定的複雜性。

那要怎麼解決這個問題呢？咱們先來思考一下，形成這個架構維護起來如此複雜的根本緣由是什麼呢？

維護 Lambda 架構的複雜性在於咱們要同時維護兩套系統架構：批處理層和速度層。咱們已經說過了，在架構中加入批處理層是由於從批處理層獲得的結果具備高準確性，而加入速度層是由於它在處理大規模數據時具備低延時性。

那咱們能不能改進其中某一層的架構，讓它具備另一層架構的特性呢？

例如，改進批處理層的系統讓它具備更低的延時性，又或者是改進速度層的系統，讓它產生的數據視圖更具準確性和更加接近歷史數據呢？

另一種在大規模數據處理中經常使用的架構——Kappa 架構（Kappa Architecture），即是在這樣的思考下誕生的。

Kappa 架構

Kappa 架構是由 LinkedIn 的前首席工程師傑伊·克雷普斯（Jay Kreps）提出的一種架構思想。克雷普斯是幾個著名開源項目（包括 Apache Kafka 和 Apache Samza 這樣的流處理系統）的做者之一，也是如今 Confluent 大數據公司的 CEO。

克雷普斯提出了一個改進 Lambda 架構的觀點：

咱們能不能改進 Lambda 架構中速度層的系統性能，使得它也能夠處理好數據的完整性和準確性問題呢？咱們能不能改進 Lambda 架構中的速度層，使它既可以進行實時數據處理，同時也有能力在業務邏輯更新的狀況下從新處理之前處理過的歷史數據呢？

他根據自身多年的架構經驗發現，咱們是能夠作到這樣的改進的。

像 Apache Kafka 這樣的流處理平臺是具備永久保存數據日誌的功能的，經過平臺的這一特性，咱們能夠從新處理部署於速度層架構中的歷史數據。

下面就以 Apache Kafka 爲例來說述整個全新架構的過程。

及時獲取更多大數據技術分享，請關注個人微信公衆號《大數據技術進階》

第一步，部署 Apache Kafka，並設置數據日誌的保留期（Retention Period）。這裏的保留期指的是你但願可以從新處理的歷史數據的時間區間。

例如，若是你但願從新處理最多一年的歷史數據，那就能夠把 Apache Kafka 中的保留期設置爲 365 天。若是你但願可以處理全部的歷史數據，那就能夠把 Apache Kafka 中的保留期設置爲「永久（Forever）」。

第二步，若是咱們須要改進現有的邏輯算法，那就表示咱們須要對歷史數據進行從新處理。

咱們須要作的就是從新啓動一個 Apache Kafka 做業實例（Instance）。這個做業實例將從頭開始，從新計算保留好的歷史數據，並將結果輸出到一個新的數據視圖中。咱們知道 Apache Kafka 的底層是使用 Log Offset 來判斷如今已經處理到哪一個數據塊了，因此只須要將 Log Offset 設置爲 0，新的做業實例就會從頭開始處理歷史數據。

第三步，當這個新的數據視圖處理過的數據進度遇上了舊的數據視圖時，咱們的應用即可以切換到重新的數據視圖中讀取。

第四步，中止舊版本的做業實例，並刪除舊的數據視圖。

與 Lambda 架構不一樣的是，Kappa 架構去掉了批處理層這一體系結構，而只保留了速度層。你只須要在業務邏輯改變又或者是代碼更改的時候進行數據的從新處理。

在講述完 Kappa 架構以後，我想強調一下，Kappa 架構也是有着它自身的不足的。

由於 Kappa 架構只保留了速度層而缺乏批處理層，在速度層上處理大規模數據可能會有數據更新出錯的狀況發生，這就須要咱們花費更多的時間在處理這些錯誤異常上面。

還有一點，Kappa 架構的批處理和流處理都放在了速度層上，這致使了這種架構是使用同一套代碼來處理算法邏輯的。因此 Kappa 架構並不適用於批處理和流處理代碼邏輯不一致的場景。

小結
在本文中，咱們簡述了 Lambda 架構和 Kappa 架構這兩種大規模數據處理架構，它們都各自有着自身的優缺點。咱們須要按照實際狀況來權衡利弊，看看在業務中到底須要使用到哪一種架構。

若是你所面對的業務邏輯是設計一種穩健的機器學習模型來預測即將發生的事情，那麼你應該優先考慮使用 Lambda 架構，由於它擁有批處理層和速度層來確保更少的錯誤。

若是你所面對的業務邏輯是但願實時性比較高，並且客戶端又是根據運行時發生的實時事件來作出迴應的，那麼你就應該優先考慮使用 Kappa 架構。