典型互聯(lián)網(wǎng)大數(shù)據(jù)平臺架構

首先我們來看一個典型的互聯(lián)網(wǎng)大數(shù)據(jù)平臺的架構，如下圖所示： 

在這張架構圖中，大數(shù)據(jù)平臺里面向用戶的在線業(yè)務處理組件用褐色標示出來，這部分是屬于互聯(lián)網(wǎng)在線應用的部分，其他藍色的部分屬于大數(shù)據(jù)相關組件，使用開源大數(shù)據(jù)產(chǎn)品或者自己開發(fā)相關大數(shù)據(jù)組件。

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

數(shù)據(jù)采集

將應用程序產(chǎn)生的數(shù)據(jù)和日志等同步到大數(shù)據(jù)系統(tǒng)中，由于數(shù)據(jù)源不同，這里的數(shù)據(jù)同步系統(tǒng)實際上是多個相關系統(tǒng)的組合。數(shù)據(jù)庫同步通常用 Sqoop，日志同步可以選擇 Flume，打點采集的數(shù)據(jù)經(jīng)過格式化轉換后通過 Kafka 等消息隊列進行傳遞。

不同的數(shù)據(jù)源產(chǎn)生的數(shù)據(jù)質量可能差別很大，數(shù)據(jù)庫中的數(shù)據(jù)也許可以直接導入大數(shù)據(jù)系統(tǒng)就可以使用了，而日志和爬蟲產(chǎn)生的數(shù)據(jù)就需要進行大量的清洗、轉化處理才能有效使用。

數(shù)據(jù)處理

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

MapReduce、Hive、Spark 等進行的計算處理被稱作是離線計算，HDFS 存儲的數(shù)據(jù)被稱為離線數(shù)據(jù)。在大數(shù)據(jù)系統(tǒng)上進行的離線計算通常針對(某一方面的)全體數(shù)據(jù)，比如針對歷史上所有訂單進行商品的關聯(lián)性挖掘，這時候數(shù)據(jù)規(guī)模非常大，需要較長的運行時間，這類計算就是離線計算。

除了離線計算，還有一些場景，數(shù)據(jù)規(guī)模也比較大，但是要求處理的時間卻比較短。比如淘寶要統(tǒng)計每秒產(chǎn)生的訂單數(shù)，以便進行監(jiān)控和宣傳。這種場景被稱為大數(shù)據(jù)流式計算，通常用 Storm、Spark Steaming 等流式大數(shù)據(jù)引擎來完成，可以在秒級甚至毫秒級時間內(nèi)完成計算。

數(shù)據(jù)輸出與展示

大數(shù)據(jù)計算產(chǎn)生的數(shù)據(jù)還是寫入到 HDFS 中，但應用程序不可能到 HDFS 中讀取數(shù)據(jù)，所以必須要將 HDFS 中的數(shù)據(jù)導出到數(shù)據(jù)庫中。數(shù)據(jù)同步導出相對比較容易，計算產(chǎn)生的數(shù)據(jù)都比較規(guī)范，稍作處理就可以用 Sqoop 之類的系統(tǒng)導出到數(shù)據(jù)庫。

這時，應用程序就可以直接訪問數(shù)據(jù)庫中的數(shù)據(jù)，實時展示給用戶，比如展示給用戶關聯(lián)推薦的商品。

除了給用戶訪問提供數(shù)據(jù)，大數(shù)據(jù)還需要給運營和決策層提供各種統(tǒng)計報告，這些數(shù)據(jù)也寫入數(shù)據(jù)庫，被相應的后臺系統(tǒng)訪問。很多運營和管理人員，每天一上班，就是登錄后臺數(shù)據(jù)系統(tǒng)，查看前一天的數(shù)據(jù)報表，看業(yè)務是否正常。如果數(shù)據(jù)正常甚至上升，就可以稍微輕松一點;如果數(shù)據(jù)下跌，焦躁而忙碌的一天馬上就要開始了。

將上面三個部分整合起來的是任務調度管理系統(tǒng)，不同的數(shù)據(jù)何時開始同步，各種 MapReduce、Spark 任務如何合理調度才能使資源利用最合理、等待的時間又不至于太久，同時臨時的重要任務還能夠盡快執(zhí)行，這些都需要任務調度管理系統(tǒng)來完成。

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

Lambda 架構

Lambda 架構(Lambda Architecture)是由 Twitter 工程師南森·馬茨(Nathan Marz)提出的大數(shù)據(jù)處理架構。這一架構的提出基于馬茨在 BackType 和 Twitter 上的分布式數(shù)據(jù)處理系統(tǒng)的經(jīng)驗。

Lambda 架構使開發(fā)人員能夠構建大規(guī)模分布式數(shù)據(jù)處理系統(tǒng)。它具有很好的靈活性和可擴展性，也對硬件故障和人為失誤有很好的容錯性。 

Lambda 架構總共由三層系統(tǒng)組成：批處理層(Batch Layer)，速度處理層(Speed Layer)，以及用于響應查詢的服務層(Serving Layer)。

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

批處理層存儲管理主數(shù)據(jù)集(不可變的數(shù)據(jù)集)和預先批處理計算好的視圖。

批處理層使用可處理大量數(shù)據(jù)的分布式處理系統(tǒng)預先計算結果。它通過處理所有的已有歷史數(shù)據(jù)來實現(xiàn)數(shù)據(jù)的準確性。這意味著它是基于完整的數(shù)據(jù)集來重新計算的，能夠修復任何錯誤，然后更新現(xiàn)有的數(shù)據(jù)視圖。輸出通常存儲在只讀數(shù)據(jù)庫中，更新則完全取代現(xiàn)有的預先計算好的視圖。

速度處理層會實時處理新來的大數(shù)據(jù)。

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

本質上，速度層彌補了批處理層所導致的數(shù)據(jù)視圖滯后。比如說，批處理層的每個任務都需要 1 個小時才能完成，而在這 1 個小時里，我們是無法獲取批處理層中最新任務給出的數(shù)據(jù)視圖的。而速度層因為能夠實時處理數(shù)據(jù)給出結果，就彌補了這 1 個小時的滯后。

所有在批處理層和速度層處理完的結果都輸出存儲在服務層中，服務層通過返回預先計算的數(shù)據(jù)視圖或從速度層處理構建好數(shù)據(jù)視圖來響應查詢。

例如廣告投放預測這種推薦系統(tǒng)一般都會用到Lambda架構。一般能做精準廣告投放的公司都會擁有海量用戶特征、用戶歷史瀏覽記錄和網(wǎng)頁類型分類這些歷史數(shù)據(jù)的。業(yè)界比較流行的做法有在批處理層用Alternating Least Squares (ALS)算法，也就是Collaborative Filtering協(xié)同過濾算法，可以得出與用戶特性一致其他用戶感興趣的廣告類型，也可以得出和用戶感興趣類型的廣告相似的廣告，而用k-means也可以對客戶感興趣的廣告類型進行分類。

這里的結果是批處理層的結果。在速度層中根據(jù)用戶的實時瀏覽網(wǎng)頁類型在之前分好類的廣告中尋找一些top K的廣告出來。最終服務層可以結合速度層的top K廣告和批處理層中分類好的點擊率高的相似廣告，做出選擇投放給用戶。

Lambda 架構的不足

雖然 Lambda 架構使用起來十分靈活，并且可以適用于很多的應用場景，但在實際應用的時候，Lambda 架構也存在著一些不足，主要表現(xiàn)在它的維護很復雜。

使用 Lambda 架構時，架構師需要維護兩個復雜的分布式系統(tǒng)，并且保證他們邏輯上產(chǎn)生相同的結果輸出到服務層中。

我們都知道，在分布式框架中進行編程其實是十分復雜的，尤其是我們還會針對不同的框架進行專門的優(yōu)化。所以幾乎每一個架構師都認同，Lambda 架構在實戰(zhàn)中維護起來具有一定的復雜性。

那要怎么解決這個問題呢?我們先來思考一下，造成這個架構維護起來如此復雜的根本原因是什么呢?

維護 Lambda 架構的復雜性在于我們要同時維護兩套系統(tǒng)架構：批處理層和速度層。我們已經(jīng)說過了，在架構中加入批處理層是因為從批處理層得到的結果具有高準確性，而加入速度層是因為它在處理大規(guī)模數(shù)據(jù)時具有低延時性。

那我們能不能改進其中某一層的架構，讓它具有另外一層架構的特性呢?

例如，改進批處理層的系統(tǒng)讓它具有更低的延時性，又或者是改進速度層的系統(tǒng)，讓它產(chǎn)生的數(shù)據(jù)視圖更具準確性和更加接近歷史數(shù)據(jù)呢?

另外一種在大規(guī)模數(shù)據(jù)處理中常用的架構——Kappa 架構(Kappa Architecture)，便是在這樣的思考下誕生的。

Kappa 架構

Kappa 架構是由 LinkedIn 的前首席工程師杰伊·克雷普斯(Jay Kreps)提出的一種架構思想。克雷普斯是幾個著名開源項目(包括 Apache Kafka 和 Apache Samza 這樣的流處理系統(tǒng))的作者之一，也是現(xiàn)在 Confluent 大數(shù)據(jù)公司的 CEO。

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

• 我們能不能改進 Lambda 架構中速度層的系統(tǒng)性能，使得它也可以處理好數(shù)據(jù)的完整性和準確性問題呢?我們能不能改進 Lambda 架構中的速度層，使它既能夠進行實時數(shù)據(jù)處理，同時也有能力在業(yè)務邏輯更新的情況下重新處理以前處理過的歷史數(shù)據(jù)呢?

他根據(jù)自身多年的架構經(jīng)驗發(fā)現(xiàn)，我們是可以做到這樣的改進的。

像 Apache Kafka 這樣的流處理平臺是具有永久保存數(shù)據(jù)日志的功能的，通過平臺的這一特性，我們可以重新處理部署于速度層架構中的歷史數(shù)據(jù)。

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

第一步，部署 Apache Kafka，并設置數(shù)據(jù)日志的保留期(Retention Period)。這里的保留期指的是你希望能夠重新處理的歷史數(shù)據(jù)的時間區(qū)間。

例如，如果你希望重新處理最多一年的歷史數(shù)據(jù)，那就可以把 Apache Kafka 中的保留期設置為 365 天。如果你希望能夠處理所有的歷史數(shù)據(jù)，那就可以把 Apache Kafka 中的保留期設置為“永久(Forever)”。

第二步，如果我們需要改進現(xiàn)有的邏輯算法，那就表示我們需要對歷史數(shù)據(jù)進行重新處理。

我們需要做的就是重新啟動一個 Apache Kafka 作業(yè)實例(Instance)。這個作業(yè)實例將從頭開始，重新計算保留好的歷史數(shù)據(jù)，并將結果輸出到一個新的數(shù)據(jù)視圖中。我們知道 Apache Kafka 的底層是使用 Log Offset 來判斷現(xiàn)在已經(jīng)處理到哪個數(shù)據(jù)塊了，所以只需要將 Log Offset 設置為 0，新的作業(yè)實例就會從頭開始處理歷史數(shù)據(jù)。

第三步，當這個新的數(shù)據(jù)視圖處理過的數(shù)據(jù)進度趕上了舊的數(shù)據(jù)視圖時，我們的應用便可以切換到從新的數(shù)據(jù)視圖中讀取。

第四步，停止舊版本的作業(yè)實例，并刪除舊的數(shù)據(jù)視圖。

與 Lambda 架構不同的是，Kappa 架構去掉了批處理層這一體系結構，而只保留了速度層。你只需要在業(yè)務邏輯改變又或者是代碼更改的時候進行數(shù)據(jù)的重新處理。

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

因為 Kappa 架構只保留了速度層而缺少批處理層，在速度層上處理大規(guī)模數(shù)據(jù)可能會有數(shù)據(jù)更新出錯的情況發(fā)生，這就需要我們花費更多的時間在處理這些錯誤異常上面。

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

小結

在本文中，我們簡述了 Lambda 架構和 Kappa 架構這兩種大規(guī)模數(shù)據(jù)處理架構，它們都各自有著自身的優(yōu)缺點。我們需要按照實際情況來權衡利弊，看看在業(yè)務中到底需要使用到哪種架構。

如果你所面對的業(yè)務邏輯是設計一種穩(wěn)健的機器學習模型來預測即將發(fā)生的事情，那么你應該優(yōu)先考慮使用 Lambda 架構，因為它擁有批處理層和速度層來確保更少的錯誤。

如果你所面對的業(yè)務邏輯是希望實時性比較高，而且客戶端又是根據(jù)運行時發(fā)生的實時事件來做出回應的，那么你就應該優(yōu)先考慮使用 Kappa 架構。