大家好，今天我們來介紹一個用于億級實時數(shù)據(jù)分析架構(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)查詢。

我們舉個這樣的例子：假如用戶A的電腦暫時借給用戶B使用了一下，而用戶B瀏覽了一些新的網(wǎng)站類型（與用戶A不同）。這種情況下，我們無法判斷用戶A實際上是否對這類型的廣告感興趣，所以不能根據(jù)這些新的瀏覽記錄給用戶A推送廣告。那么我們?nèi)绾巫龅郊饶軐崟r分析用戶新的網(wǎng)站瀏覽行為又能兼顧到用戶的網(wǎng)站瀏覽行為歷史呢？這就可以利用Lambda架構(gòu)。

所有的新用戶行為數(shù)據(jù)都可以同時流入批處理層和速度層。批處理層會永久保存數(shù)據(jù)并且對數(shù)據(jù)進(jìn)行預(yù)處理，得到我們想要的用戶行為模型并寫入服務(wù)層。而速度層也同時對新用戶行為數(shù)據(jù)進(jìn)行處理，得到實時的用戶行為模型。

而當(dāng)“應(yīng)該對用戶投放什么樣的廣告”作為一個查詢（Query）來到時，我們從服務(wù)層既查詢服務(wù)層中保存好的批處理輸出模型，也對速度層中處理的實時行為進(jìn)行查詢，這樣我們就可以得到一個完整的用戶行為歷史了。

一個查詢就如下圖所示，既通過批處理層兼顧了數(shù)據(jù)的完整性，也可以通過速度層彌補批處理層的高延時性，讓整個查詢具有實時性。

Lambda架構(gòu)在硅谷一線大公司的應(yīng)用已經(jīng)十分廣泛，我來帶你一起看看一些實際的應(yīng)用場景。

Twitter的數(shù)據(jù)分析案例

Twitter在歐美十分受歡迎，而Twitter中人們所發(fā)Tweet里面的Hashtag也常常能引爆一些熱搜詞匯，也就是Most Popular Hashtags。下面我來給你講述一下如何利用Lambda架構(gòu)來實時分析這些Hashtags。

在這個實際案例里，我們先用twitter4J的流處理API抓取實時的Twitter推文，同時利用Apache Kafka將抓取到的數(shù)據(jù)保存并實時推送給批處理層和速度層。

因為Apache Spark平臺中既有批處理架構(gòu)也兼容了流處理架構(gòu)，所以我們選擇在批處理層和速度層都采用Apache Spark來讀取來自Apache Kafka的數(shù)據(jù)。

批處理層和速度層在分析處理好數(shù)據(jù)后會將數(shù)據(jù)視圖輸出存儲在服務(wù)層中，我們將使用Apache Cassandra平臺來存儲他們的數(shù)據(jù)視圖。Apache Cassandra將批處理層的視圖數(shù)據(jù)和速度層的實時視圖數(shù)據(jù)結(jié)合起來，就可以得到一系列有趣的數(shù)據(jù)。

例如，我們根據(jù)每一條Tweet中元數(shù)據(jù)（Metadata）里的location field，可以得知發(fā)推文的人的所在地。而服務(wù)層中的邏輯可以根據(jù)這個地址信息進(jìn)行分組，然后統(tǒng)計在不同地區(qū)的人所關(guān)心的Hashtag是什么。

時間長達(dá)幾周或者的幾個月的數(shù)據(jù)，我們可以結(jié)合批處理層和速度層的數(shù)據(jù)視圖來得出，而快至幾個小時的數(shù)據(jù)我們又可以根據(jù)速度層的數(shù)據(jù)視圖來獲知，怎么樣？這個架構(gòu)是不是十分靈活？

看到這里，你可能會問，我在上面所講的例子都是來自些科技巨頭公司，如果我在開發(fā)中面對的數(shù)據(jù)場景沒有這么巨大，又或者說我的公司還在創(chuàng)業(yè)起步階段，我是否可以用到Lambda架構(gòu)呢？

答案是肯定的！我們一起來看一個在硅谷舊金山創(chuàng)業(yè)公司的App后臺架構(gòu)。

Smart Parking案例分析

在硅谷地區(qū)上班生活，找停車位是一大難題。這里地少車多，每次出行，特別是周末，找停車位都要繞個好幾十分鐘才能找得到。

智能停車App就是在這樣的背景下誕生的。這個App可以根據(jù)大規(guī)模數(shù)據(jù)所構(gòu)建的視圖推薦最近的車位給用戶。

看到這里，我想先請你結(jié)合之前所講到的廣告精準(zhǔn)投放案例，思考一下Lambda架構(gòu)是如何應(yīng)用在這個App里的，然后再聽我娓娓道來。

好，我們來梳理一下各種可以利用到的大數(shù)據(jù)。

首先是可以拿到各類停車場的數(shù)據(jù)。這類數(shù)據(jù)的實時性雖然不一定高，但是數(shù)據(jù)的準(zhǔn)確性高。那我們能不能只通過這類大數(shù)據(jù)來推薦停車位呢？

我舉個極端的例子。假設(shè)在一個區(qū)域有三個停車場，停車場A現(xiàn)在只剩下1個停車位了。

停車場B和C還有非常多的空位。而在這時候距離停車場比A較近的位置有10位車主在使用這個App尋求推薦停車位。如果只通過車主和停車場的距離和停車場剩余停車位來判斷的話，App很有可能會將這個只剩下一個停車位的停車場A同時推薦給這10位用戶。

結(jié)果可想而知，只有一位幸運兒能找到停車位，剩下的9位車主需要重新尋找停車位。

如果附近又出現(xiàn)了只有一個停車位的停車場呢？同理，這個App又會推薦這個停車場給剩下的9位用戶。這時又只能有一位幸運兒找到停車位。

如此反復(fù)循環(huán)，用戶體驗會非常差，甚至?xí)?dǎo)致用戶放棄這個App。

那我們有沒有辦法可以改進(jìn)推薦的準(zhǔn)確度呢？

你可能會想到我們可以利用這些停車場的歷史數(shù)據(jù)，建立一個人工智能的預(yù)測模型，在推薦停車位的時候，不單單考慮到附近停車場的剩余停車位和用戶與停車場的相鄰距離，還能將預(yù)測模型應(yīng)用在推薦里，看看未來的一段時間內(nèi)這個停車場是否有可能會被停滿了。

這時候我們的停車位推薦系統(tǒng)就變成了一個基于分?jǐn)?shù)（Score）來推薦停車位的系統(tǒng)了。

好了，這個時候的系統(tǒng)架構(gòu)是否已經(jīng)達(dá)到最優(yōu)了呢？你有想到應(yīng)用Lambda架構(gòu)嗎？

沒錯，這些停車場的歷史數(shù)據(jù)或者每隔半小時拿到的停車位數(shù)據(jù)，我們可以把它作為批處理層的數(shù)據(jù)。

那速度層的數(shù)據(jù)呢？我們可以將所有用戶的GPS數(shù)據(jù)聚集起來，這些需要每秒收集的GPS數(shù)據(jù)剛好又是速度層所擅長的實時流處理數(shù)據(jù)。從這些用戶的實時GPS數(shù)據(jù)中，我們可以再建立一套預(yù)測模型來預(yù)測附近停車場位置的擁擠程度。

服務(wù)層將從批處理層和速度層得到的分?jǐn)?shù)結(jié)合后將得到最高分?jǐn)?shù)的停車場推薦給用戶。這樣利用了歷史數(shù)據(jù)（停車場數(shù)據(jù)）和實時數(shù)據(jù)（用戶GPS數(shù)據(jù)）能大大提升推薦的準(zhǔn)確率。

總結(jié)

在了解Lambda架構(gòu)后，我們知道Lambda架構(gòu)具有很好的靈活性和可擴展性。我們可以很方便地將現(xiàn)有的開源平臺套用入這個架構(gòu)中，如下圖所示。

當(dāng)開發(fā)者需要遷移平臺時，整體的架構(gòu)不需要改變，只需要將邏輯遷移到新平臺中。

例如，可以將Apache Spark替換成Apache Storm。而因為我們有批處理層這一概念，又有了很好的容錯性。

假如某天開發(fā)者發(fā)現(xiàn)邏輯出現(xiàn)了錯誤，只需要調(diào)整算法對永久保存好的數(shù)據(jù)重新進(jìn)行處理寫入服務(wù)層，經(jīng)過多次迭代后整體的邏輯便可以被糾正過來?，F(xiàn)在有很多的開發(fā)項目可能已經(jīng)有了比較成熟的架構(gòu)或者算法了。

但是如果我們平時能多思考一下現(xiàn)有架構(gòu)的瓶頸，又或者想一想現(xiàn)在的架構(gòu)能不能改善得更好，有了這樣的思考，在學(xué)習(xí)到這些經(jīng)典優(yōu)秀架構(gòu)之后，說不定真的能讓現(xiàn)有的架構(gòu)變得更好。

編輯：黃飛

?