首先我們來看一個典型的網際網路大資料平臺的架構，如下圖所示：

在這張架構圖中，大資料平臺裡面向用戶的線上業務處理元件用褐色標示出來，這部分是屬於網際網路線上應用的部分，其他藍色的部分屬於大資料相關元件，使用開源大資料產品或者自己開發相關大資料元件。

你可以看到，大資料平臺由上到下，可分為三個部分：資料採集、資料處理、資料輸出與展示。

資料採集

將應用程式產生的資料和日誌等同步到大資料系統中，由於資料來源不同，這裡的資料同步系統實際上是多個相關係統的組合。資料庫同步通常用 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 架構