-9-大數(shù)據(jù)處理中的Lambda架構(gòu)和Kappa架構(gòu)不同的數(shù)據(jù)源產(chǎn)生的數(shù)據(jù)質(zhì)量可能差別很大，數(shù)據(jù)庫中的數(shù)據(jù)或許可以直接導(dǎo)入大數(shù)據(jù)系統(tǒng)就可以使用了，而日志和爬蟲產(chǎn)生的數(shù)據(jù)就需要進(jìn)行大量的清洗、轉(zhuǎn)化處理才能有效使用。首先我們來看一個(gè)典型的互聯(lián)網(wǎng)大數(shù)據(jù)平臺(tái)的架構(gòu)，如下圖所示：

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

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

數(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ù)庫同步通常用Sqoop，日志同步可以選擇Flume，打點(diǎn)采集的數(shù)據(jù)經(jīng)過格式化轉(zhuǎn)換后通過Kafka等消息隊(duì)列進(jìn)行傳遞。

不同的數(shù)據(jù)源產(chǎn)生的數(shù)據(jù)質(zhì)量可能差別很大，數(shù)據(jù)庫中的數(shù)據(jù)或許可以直接導(dǎo)入大數(shù)據(jù)系統(tǒ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é)果寫入HDFS。

MapReduce、Hive、Spark等進(jìn)行的計(jì)算處理被稱作是離線計(jì)算，HDFS存儲(chǔ)的數(shù)據(jù)被稱為離線數(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í)間，這類計(jì)算就是離線計(jì)算。

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

數(shù)據(jù)輸出與展現(xiàn)

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

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

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

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

上面講的這種大數(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)（LambdaArchitecture）是由Twitter工程師南森馬茨（NathanMarz）提出的大數(shù)據(jù)處理架構(gòu)。這一架構(gòu)的提出基于馬茨在BackType和Twitter上的分布式數(shù)據(jù)處理系統(tǒng)的閱歷。

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

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

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

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

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

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

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

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

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

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

這里的結(jié)果是批處理層的結(jié)果。在速度層中依據(jù)用戶的實(shí)時(shí)掃瞄網(wǎng)頁類型在之前分好類的廣告中查找一些topK的廣告出來。最終服務(wù)層可以結(jié)合速度層的topK廣告和批處理層中分類好的點(diǎn)擊率高的相像廣告，做出選擇投放給用戶。

Lambda架構(gòu)的不足

雖然Lambda架構(gòu)使用起來非常敏捷，并且可以適用于許多的應(yīng)用場(chǎng)景，但在實(shí)際應(yīng)用的時(shí)候，Lambda架構(gòu)也存在著一些不足，主要表現(xiàn)在它的維護(hù)很簡(jiǎn)單。

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

我們都知道，在分布式框架中進(jìn)行編程其實(shí)是非常簡(jiǎn)單的，尤其是我們還會(huì)針對(duì)不同的框架進(jìn)行特地的優(yōu)化。所以幾乎每一個(gè)架構(gòu)師都認(rèn)同，Lambda架構(gòu)在實(shí)戰(zhàn)中維護(hù)起來具有肯定的簡(jiǎn)單性。

那要怎么解決這個(gè)問題呢？我們先來思索一下，造成這個(gè)架構(gòu)維護(hù)起來如此簡(jiǎn)單的根本緣由是什么呢？

維護(hù)Lambda架構(gòu)的簡(jiǎn)單性在于我們要同時(shí)維護(hù)兩套系統(tǒng)架構(gòu)：批處理層和速度層。我們已經(jīng)說過了，在架構(gòu)中加入批處理層是由于從批處理層得到的結(jié)果具有高精確?????性，而加入速度層是由于它在處理大規(guī)模數(shù)據(jù)時(shí)具有低延時(shí)性。

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

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

另外一種在大規(guī)模數(shù)據(jù)處理中常用的架構(gòu)Kappa架構(gòu)（KappaArchitecture），便是在這樣的思索下誕生的。

Kappa架構(gòu)

Kappa架構(gòu)是由LinkedIn的前首席工程師杰伊克雷普斯（JayKreps）提出的一種架構(gòu)思想?？死灼账故菐讉€(gè)著名開源項(xiàng)目（包括ApacheKafka和ApacheSamza這樣的流處理系統(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ù)的完整性和精確?????性問題呢？我們能不能改進(jìn)Lambda架構(gòu)中的速度層，使它既能夠進(jìn)行實(shí)時(shí)數(shù)據(jù)處理，同時(shí)也有力量在業(yè)務(wù)規(guī)律更新的狀況下重新處理以前處理過的歷史數(shù)據(jù)呢？

他依據(jù)自身多年的架構(gòu)閱歷發(fā)覺，我們是可以做到這樣的改進(jìn)的。

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

下面就以ApacheKafka為例來敘述整個(gè)全新架構(gòu)的過程。

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

例如，假如你盼望重新處理最多一年的歷史數(shù)據(jù)，那就可以把ApacheKafka中的保留期設(shè)置為365天。假如你盼望能夠處理全部的歷史數(shù)據(jù)，那就可以把ApacheKafka中的保留期設(shè)置為"永久（Forever）'。

其次步，假如我們需要改進(jìn)現(xiàn)有的規(guī)律算法，那就表示我們需要對(duì)歷史數(shù)據(jù)進(jìn)行重新處理。

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

第三步，當(dāng)這個(gè)新的數(shù)據(jù)視圖處理過的數(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ù)規(guī)律轉(zhuǎn)變又或者是代碼更改的時(shí)候進(jìn)行數(shù)據(jù)的重新處理。

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

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

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

小結(jié)

在本文中，我們簡(jiǎn)述了Lambda