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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)驗(yàn)。

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

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

在 Lambda 架構(gòu)中，每層都有自己所肩負(fù)的任務(wù)。

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

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

速度處理層會(huì)實(shí)時(shí)處理新來(lái)的大數(shù)據(jù)。

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

本質(zhì)上，速度層彌補(bǔ)了批處理層所導(dǎo)致的數(shù)據(jù)視圖滯后。比如說(shuō)，批處理層的每個(gè)任務(wù)都需要 1 個(gè)小時(shí)才能完成，而在這 1 個(gè)小時(shí)里，我們是無(wú)法獲取批處理層中最新任務(wù)給出的數(shù)據(jù)視圖的。而速度層因?yàn)槟軌驅(qū)崟r(shí)處理數(shù)據(jù)給出結(jié)果，就彌補(bǔ)了這 1 個(gè)小時(shí)的滯后。

所有在批處理層和速度層處理完的結(jié)果都輸出存儲(chǔ)在服務(wù)層中，服務(wù)層通過(guò)返回預(yù)先計(jì)算的數(shù)據(jù)視圖或從速度層處理構(gòu)建好數(shù)據(jù)視圖來(lái)響應(yīng)查詢。

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

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

Lambda 架構(gòu)的不足

雖然 Lambda 架構(gòu)使用起來(lái)十分靈活，并且可以適用于很多的應(yīng)用場(chǎng)景，但在實(shí)際應(yīng)用的時(shí)候，Lambda 架構(gòu)也存在著一些不足，主要表現(xiàn)在它的維護(hù)很復(fù)雜。

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

我們都知道，在分布式框架中進(jìn)行編程其實(shí)是十分復(fù)雜的，尤其是我們還會(huì)針對(duì)不同的框架進(jìn)行專(zhuān)門(mén)的優(yōu)化。所以幾乎每一個(gè)架構(gòu)師都認(rèn)同，Lambda 架構(gòu)在實(shí)戰(zhàn)中維護(hù)起來(lái)具有一定的復(fù)雜性。

那要怎么解決這個(gè)問(wèn)題呢?我們先來(lái)思考一下，造成這個(gè)架構(gòu)維護(hù)起來(lái)如此復(fù)雜的根本原因是什么呢?

維護(hù) Lambda 架構(gòu)的復(fù)雜性在于我們要同時(shí)維護(hù)兩套系統(tǒng)架構(gòu)：批處理層和速度層。我們已經(jīng)說(shuō)過(guò)了，在架構(gòu)中加入批處理層是因?yàn)閺呐幚韺拥玫降慕Y(jié)果具有高準(zhǔn)確性，而加入速度層是因?yàn)樗谔幚泶笠?guī)模數(shù)據(jù)時(shí)具有低延時(shí)性。

那我們能不能改進(jìn)其中某一層的架構(gòu)，讓它具有另外一層架構(gòu)的特性呢?

例如，改進(jìn)批處理層的系統(tǒng)讓它具有更低的延時(shí)性，又或者是改進(jìn)速度層的系統(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)思想。克雷普斯是幾個(gè)著名開(kāi)源項(xiàng)目(包括 Apache Kafka 和 Apache Samza 這樣的流處理系統(tǒng))的作者之一，也是現(xiàn)在 Confluent 大數(shù)據(jù)公司的 CEO。

克雷普斯提出了一個(gè)改進(jìn) Lambda 架構(gòu)的觀點(diǎn)：

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

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

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

下面就以 Apache Kafka 為例來(lái)講述整個(gè)全新架構(gòu)的過(guò)程。 

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

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

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

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

第三步，當(dāng)這個(gè)新的數(shù)據(jù)視圖處理過(guò)的數(shù)據(jù)進(jìn)度趕上了舊的數(shù)據(jù)視圖時(shí)，我們的應(yīng)用便可以切換到從新的數(shù)據(jù)視圖中讀取。

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

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

在講述完 Kappa 架構(gòu)之后，我想強(qiáng)調(diào)一下，Kappa 架構(gòu)也是有著它自身的不足的。

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

還有一點(diǎn)，Kappa 架構(gòu)的批處理和流處理都放在了速度層上，這導(dǎo)致了這種架構(gòu)是使用同一套代碼來(lái)處理算法邏輯的。所以 Kappa 架構(gòu)并不適用于批處理和流處理代碼邏輯不一致的場(chǎng)景。

小結(jié)

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

如果你所面對(duì)的業(yè)務(wù)邏輯是設(shè)計(jì)一種穩(wěn)健的機(jī)器學(xué)習(xí)模型來(lái)預(yù)測(cè)即將發(fā)生的事情，那么你應(yīng)該優(yōu)先考慮使用 Lambda 架構(gòu)，因?yàn)樗鼡碛信幚韺雍退俣葘觼?lái)確保更少的錯(cuò)誤。

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