典型互聯網大數據平臺架構

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

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

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

數據采集

將應用程序產生的數據和日志等同步到大數據系統中，由于數據源不同，這里的數據同步系統實際上是多個相關系統的組合。數據庫同步通常用 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 架構。