大資料進行中的Lambda架構和Kappa架構 - XIAO的部落格

大資料進行中的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 架構。