首先我們來看一個典型的互聯(lián)網(wǎng)大數(shù)據(jù)平臺的架構(gòu)，如下圖所示：
在這張架構(gòu)圖中，大數(shù)據(jù)平臺里面向用戶的在線業(yè)務(wù)處理組件用褐色標(biāo)示出來，這部分是屬于互聯(lián)網(wǎng)在線應(yīng)用的部分，其他藍色的部分屬于大數(shù)據(jù)相關(guān)組件，使用開源大數(shù)據(jù)產(chǎn)品或者自己開發(fā)相關(guān)大數(shù)據(jù)組件。
你可以看到，大數(shù)據(jù)平臺由上到下，可分為三個部分：數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)輸出與展示。
數(shù)據(jù)采集
將應(yīng)用程序產(chǎn)生的數(shù)據(jù)和日志等同步到大數(shù)據(jù)系統(tǒng)中，由于數(shù)據(jù)源不同，這里的數(shù)據(jù)同步系統(tǒng)實際上是多個相關(guān)系統(tǒng)的組合。數(shù)據(jù)庫同步通常用 Sqoop，日志同步可以選擇 Flume，打點采集的數(shù)據(jù)經(jīng)過格式化轉(zhuǎn)換后通過 Kafka 等消息隊列進行傳遞。
不同的數(shù)據(jù)源產(chǎn)生的數(shù)據(jù)質(zhì)量可能差別很大，數(shù)據(jù)庫中的數(shù)據(jù)也許可以直接導(dǎo)入大數(shù)據(jù)系統(tǒng)就可以使用了，而日志和爬蟲產(chǎn)生的數(shù)據(jù)就需要進行大量的清洗、轉(zhuǎn)化處理才能有效使用。
數(shù)據(jù)處理
這部分是大數(shù)據(jù)存儲與計算的核心，數(shù)據(jù)同步系統(tǒng)導(dǎo)入的數(shù)據(jù)存儲在 HDFS。MapReduce、Hive、Spark等計算任務(wù)讀取 HDFS 上的數(shù)據(jù)進行計算，再將計算結(jié)果寫入HDFS。
MapReduce、Hive、Spark 等進行的計算處理被稱作是離線計算，HDFS 存儲的數(shù)據(jù)被稱為離線數(shù)據(jù)。在大數(shù)據(jù)系統(tǒng)上進行的離線計算通常針對（某一方面的）全體數(shù)據(jù)，比如針對歷史上所有訂單進行商品的關(guān)聯(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 中，但應(yīng)用程序不可能到 HDFS 中讀取數(shù)據(jù)，所以必須要將 HDFS 中的數(shù)據(jù)導(dǎo)出到數(shù)據(jù)庫中。數(shù)據(jù)同步導(dǎo)出相對比較容易，計算產(chǎn)生的數(shù)據(jù)都比較規(guī)范，稍作處理就可以用 Sqoop 之類的系統(tǒng)導(dǎo)出到數(shù)據(jù)庫。
這時，應(yīng)用程序就可以直接訪問數(shù)據(jù)庫中的數(shù)據(jù)，實時展示給用戶，比如展示給用戶關(guān)聯(lián)推薦的商品。
除了給用戶訪問提供數(shù)據(jù)，大數(shù)據(jù)還需要給運營和決策層提供各種統(tǒng)計報告，這些數(shù)據(jù)也寫入數(shù)據(jù)庫，被相應(yīng)的后臺系統(tǒng)訪問。很多運營和管理人員，每天一上班，就是登錄后臺數(shù)據(jù)系統(tǒng)，查看前一天的數(shù)據(jù)報表，看業(yè)務(wù)是否正常。如果數(shù)據(jù)正常甚至上升，就可以稍微輕松一點；如果數(shù)據(jù)下跌，焦躁而忙碌的一天馬上就要開始了。
將上面三個部分整合起來的是任務(wù)調(diào)度管理系統(tǒng)，不同的數(shù)據(jù)何時開始同步，各種MapReduce、Spark 任務(wù)如何合理調(diào)度才能使資源利用最合理、等待的時間又不至于太久，同時臨時的重要任務(wù)還能夠盡快執(zhí)行，這些都需要任務(wù)調(diào)度管理系統(tǒng)來完成。
上面講的這種大數(shù)據(jù)平臺架構(gòu)也叫 Lambda 架構(gòu)，是構(gòu)建大數(shù)據(jù)平臺的一種常規(guī)架構(gòu)原型方案。Lambda 架構(gòu)原型請看下面的圖。
Lambda 架構(gòu)
Lambda 架構(gòu)（Lambda Architecture）是由 Twitter 工程師南森·馬茨（Nathan Marz）提出的大數(shù)據(jù)處理架構(gòu)。這一架構(gòu)的提出基于馬茨在 BackType 和 Twitter 上的分布式數(shù)據(jù)處理系統(tǒng)的經(jīng)驗。
Lambda 架構(gòu)使開發(fā)人員能夠構(gòu)建大規(guī)模分布式數(shù)據(jù)處理系統(tǒng)。它具有很好的靈活性和可擴展性，也對硬件故障和人為失誤有很好的容錯性。
Lambda 架構(gòu)總共由三層系統(tǒng)組成：批處理層（Batch Layer），速度處理層（Speed Layer），以及用于響應(yīng)查詢的服務(wù)層（Serving Layer）。
在 Lambda 架構(gòu)中，每層都有自己所肩負(fù)的任務(wù)。
批處理層存儲管理主數(shù)據(jù)集（不可變的數(shù)據(jù)集）和預(yù)先批處理計算好的視圖。
批處理層使用可處理大量數(shù)據(jù)的分布式處理系統(tǒng)預(yù)先計算結(jié)果。它通過處理所有的已有歷史數(shù)據(jù)來實現(xiàn)數(shù)據(jù)的準(zhǔn)確性。這意味著它是基于完整的數(shù)據(jù)集來重新計算的，能夠修復(fù)任何錯誤，然后更新現(xiàn)有的數(shù)據(jù)視圖。輸出通常存儲在只讀數(shù)據(jù)庫中，更新則完全取代現(xiàn)有的預(yù)先計算好的視圖。
速度處理層會實時處理新來的大數(shù)據(jù)。
速度層通過提供最新數(shù)據(jù)的實時視圖來最小化延遲。速度層所生成的數(shù)據(jù)視圖可能不如批處理層最終生成的視圖那樣準(zhǔn)確或完整，但它們幾乎在收到數(shù)據(jù)后立即可用。而當(dāng)同樣的數(shù)據(jù)在批處理層處理完成后，在速度層的數(shù)據(jù)就可以被替代掉了。
本質(zhì)上，速度層彌補了批處理層所導(dǎo)致的數(shù)據(jù)視圖滯后。比如說，批處理層的每個任務(wù)都需要 1 個小時才能完成，而在這 1 個小時里，我們是無法獲取批處理層中最新任務(wù)給出的數(shù)據(jù)視圖的。而速度層因為能夠?qū)崟r處理數(shù)據(jù)給出結(jié)果，就彌補了這 1 個小時的滯后。
所有在批處理層和速度層處理完的結(jié)果都輸出存儲在服務(wù)層中，服務(wù)層通過返回預(yù)先計算的數(shù)據(jù)視圖或從速度層處理構(gòu)建好數(shù)據(jù)視圖來響應(yīng)查詢。
例如廣告投放預(yù)測這種推薦系統(tǒng)一般都會用到Lambda架構(gòu)。一般能做精準(zhǔn)廣告投放的公司都會擁有海量用戶特征、用戶歷史瀏覽記錄和網(wǎng)頁類型分類這些歷史數(shù)據(jù)的。業(yè)界比較流行的做法有在批處理層用Alternating Least Squares (ALS)算法，也就是CollaborativeFiltering協(xié)同過濾算法，可以得出與用戶特性一致其他用戶感興趣的廣告類型，也可以得出和用戶感興趣類型的廣告相似的廣告，而用k-means也可以對客戶感興趣的廣告類型進行分類。
這里的結(jié)果是批處理層的結(jié)果。在速度層中根據(jù)用戶的實時瀏覽網(wǎng)頁類型在之前分好類的廣告中尋找一些top K的廣告出來。最終服務(wù)層可以結(jié)合速度層的top K廣告和批處理層中分類好的點擊率高的相似廣告，做出選擇投放給用戶。
Lambda 架構(gòu)的不足
雖然 Lambda 架構(gòu)使用起來十分靈活，并且可以適用于很多的應(yīng)用場景，但在實際應(yīng)用的時候，Lambda 架構(gòu)也存在著一些不足，主要表現(xiàn)在它的維護很復(fù)雜。
使用 Lambda 架構(gòu)時，架構(gòu)師需要維護兩個復(fù)雜的分布式系統(tǒng)，并且保證他們邏輯上產(chǎn)生相同的結(jié)果輸出到服務(wù)層中。
我們都知道，在分布式框架中進行編程其實是十分復(fù)雜的，尤其是我們還會針對不同的框架進行專門的優(yōu)化。所以幾乎每一個架構(gòu)師都認(rèn)同，Lambda 架構(gòu)在實戰(zhàn)中維護起來具有一定的復(fù)雜性。
那要怎么解決這個問題呢？我們先來思考一下，造成這個架構(gòu)維護起來如此復(fù)雜的根本原因是什么呢？
維護 Lambda 架構(gòu)的復(fù)雜性在于我們要同時維護兩套系統(tǒng)架構(gòu)：批處理層和速度層。我們已經(jīng)說過了，在架構(gòu)中加入批處理層是因為從批處理層得到的結(jié)果具有高準(zhǔn)確性，而加入速度層是因為它在處理大規(guī)模數(shù)據(jù)時具有低延時性。
那我們能不能改進其中某一層的架構(gòu)，讓它具有另外一層架構(gòu)的特性呢？
例如，改進批處理層的系統(tǒng)讓它具有更低的延時性，又或者是改進速度層的系統(tǒng)，讓它產(chǎn)生的數(shù)據(jù)視圖更具準(zhǔn)確性和更加接近歷史數(shù)據(jù)呢？
另外一種在大規(guī)模數(shù)據(jù)處理中常用的架構(gòu)——Kappa 架構(gòu)（Kappa Architecture），便是在這樣的思考下誕生的。
Kappa 架構(gòu)
Kappa 架構(gòu)是由 LinkedIn 的前首席工程師杰伊·克雷普斯（Jay Kreps）提出的一種架構(gòu)思想。克雷普斯是幾個著名開源項目（包括 ApacheKafka 和 Apache Samza 這樣的流處理系統(tǒng)）的作者之一，也是現(xiàn)在 Confluent 大數(shù)據(jù)公司的 CEO。
克雷普斯提出了一個改進 Lambda 架構(gòu)的觀點：
我們能不能改進 Lambda 架構(gòu)中速度層的系統(tǒng)性能，使得它也可以處理好數(shù)據(jù)的完整性和準(zhǔn)確性問題呢？我們能不能改進 Lambda 架構(gòu)中的速度層，使它既能夠進行實時數(shù)據(jù)處理，同時也有能力在業(yè)務(wù)邏輯更新的情況下重新處理以前處理過的歷史數(shù)據(jù)呢？
他根據(jù)自身多年的架構(gòu)經(jīng)驗發(fā)現(xiàn)，我們是可以做到這樣的改進的。
像 Apache Kafka 這樣的流處理平臺是具有永久保存數(shù)據(jù)日志的功能的，通過平臺的這一特性，我們可以重新處理部署于速度層架構(gòu)中的歷史數(shù)據(jù)。
下面就以 Apache Kafka 為例來講述整個全新架構(gòu)的過程。
第一步，部署 Apache Kafka，并設(shè)置數(shù)據(jù)日志的保留期（Retention Period）。這里的保留期指的是你希望能夠重新處理的歷史數(shù)據(jù)的時間區(qū)間。
例如，如果你希望重新處理最多一年的歷史數(shù)據(jù)，那就可以把 Apache Kafka中的保留期設(shè)置為 365 天。如果你希望能夠處理所有的歷史數(shù)據(jù)，那就可以把 Apache Kafka 中的保留期設(shè)置為“永久（Forever）”。
第二步，如果我們需要改進現(xiàn)有的邏輯算法，那就表示我們需要對歷史數(shù)據(jù)進行重新處理。
我們需要做的就是重新啟動一個 Apache Kafka 作業(yè)實例（Instance）。這個作業(yè)實例將從頭開始，重新計算保留好的歷史數(shù)據(jù)，并將結(jié)果輸出到一個新的數(shù)據(jù)視圖中。我們知道 Apache Kafka 的底層是使用 Log Offset 來判斷現(xiàn)在已經(jīng)處理到哪個數(shù)據(jù)塊了，所以只需要將 Log Offset 設(shè)置為 0，新的作業(yè)實例就會從頭開始處理歷史數(shù)據(jù)。
第三步，當(dāng)這個新的數(shù)據(jù)視圖處理過的數(shù)據(jù)進度趕上了舊的數(shù)據(jù)視圖時，我們的應(yīng)用便可以切換到從新的數(shù)據(jù)視圖中讀取。
第四步，停止舊版本的作業(yè)實例，并刪除舊的數(shù)據(jù)視圖。
與 Lambda 架構(gòu)不同的是，Kappa架構(gòu)去掉了批處理層這一體系結(jié)構(gòu)，而只保留了速度層。你只需要在業(yè)務(wù)邏輯改變又或者是代碼更改的時候進行數(shù)據(jù)的重新處理。
在講述完 Kappa 架構(gòu)之后，我想強調(diào)一下，Kappa 架構(gòu)也是有著它自身的不足的。
因為 Kappa 架構(gòu)只保留了速度層而缺少批處理層，在速度層上處理大規(guī)模數(shù)據(jù)可能會有數(shù)據(jù)更新出錯的情況發(fā)生，這就需要我們花費更多的時間在處理這些錯誤異常上面。
還有一點，Kappa 架構(gòu)的批處理和流處理都放在了速度層上，這導(dǎo)致了這種架構(gòu)是使用同一套代碼來處理算法邏輯的。所以 Kappa 架構(gòu)并不適用于批處理和流處理代碼邏輯不一致的場景。
小結(jié)
在本文中，我們簡述了 Lambda 架構(gòu)和 Kappa 架構(gòu)這兩種大規(guī)模數(shù)據(jù)處理架構(gòu)，它們都各自有著自身的優(yōu)缺點。我們需要按照實際情況來權(quán)衡利弊，看看在業(yè)務(wù)中到底需要使用到哪種架構(gòu)。
如果你所面對的業(yè)務(wù)邏輯是設(shè)計一種穩(wěn)健的機器學(xué)習(xí)模型來預(yù)測即將發(fā)生的事情，那么你應(yīng)該優(yōu)先考慮使用 Lambda 架構(gòu)，因為它擁有批處理層和速度層來確保更少的錯誤。
如果你所面對的業(yè)務(wù)邏輯是希望實時性比較高，而且客戶端又是根據(jù)運行時發(fā)生的實時事件來做出回應(yīng)的，那么你就應(yīng)該優(yōu)先考慮使用 Kappa 架構(gòu)。
