去年我們發(fā)布了Answers，至今移動社區(qū)產(chǎn)生了驚人的使用量，讓我們感到興奮不已。現(xiàn)在Answers每天處理50億次會話，并且這個數(shù)量在持續(xù)增加。上億設(shè)備每秒向Answers端點發(fā)送數(shù)以百萬計的請求。在你已經(jīng)閱讀到此處的這段時間里，Answers后臺收到并處理了一千萬次分析事件。

其中的挑戰(zhàn)是如何利用這些信息向移動開發(fā)者提供可靠的、實時的、有實際價值的洞見(視角)去了解他們的移動應(yīng)用。

在高層，我們依靠 組件解耦、異步通信、在應(yīng)對災(zāi)難性故障時優(yōu)雅地服務(wù)降級等原則來幫助架構(gòu)決策。我們使用Lambda架構(gòu)將數(shù)據(jù)完整性和實時數(shù)據(jù)更新結(jié)合起來。

在實踐過程中，我們需要設(shè)計一個能夠接收并保存事件、執(zhí)行離線和實時計算且能將上述兩種計算結(jié)果整合成相關(guān)信息的系統(tǒng)。這些行為全部都要以百萬次每秒的規(guī)模執(zhí)行。

讓我們從第一個挑戰(zhàn)開始：接受并處理這些事件。

事件接收

在設(shè)計設(shè)備-服務(wù)器通信的時候，我們的目標(biāo)是：減少對電池和網(wǎng)絡(luò)使用的影響;確保數(shù)據(jù)的可靠性;接近實時地獲取數(shù)據(jù)。為了減少對設(shè)備的影響，我們批量地發(fā)送分析數(shù)據(jù)并且在發(fā)送前對數(shù)據(jù)進行壓縮。為了保證這些寶貴的數(shù)據(jù)始終能夠到達我們的服務(wù)器，在傳輸失敗隨機退避后以及達到設(shè)備存儲達到上限時，設(shè)備會進行重傳。為了確保數(shù)據(jù)能夠盡快到達服務(wù)器，我們設(shè)置來多個觸發(fā)器來使設(shè)備嘗試發(fā)送：當(dāng)程序運行于前臺的時候，事件觸發(fā)器每分鐘觸發(fā)一次;一個消息數(shù)量觸發(fā)器和程序轉(zhuǎn)入后臺觸發(fā)器。

這樣的通信協(xié)議導(dǎo)致設(shè)備每秒發(fā)送來數(shù)以萬計壓縮過的有效載荷。每一個載荷都包含數(shù)十條事件。為了能夠可靠的、易于線性伸縮的方式去處理載荷，接收事件的服務(wù)必須極度簡單。

這個服務(wù)使用GO語言編寫，這個服務(wù)使用了亞馬遜彈性負載均衡器(ELB)，并將每一個消息負荷放入一個持久化的Kafka隊列。

存儲

Kafka是一個持久存儲器，因為它把收到的消息寫入磁盤并且每個消息都有多份冗余。因此一旦我們知道信息到了Kafka隊列，我們就可以通過延遲處理、再處理來容忍下游延遲和下游失敗。然而，Kafka不是我們歷史數(shù)據(jù)的永久真理之源——按照上文提到的速度，僅僅是幾天的數(shù)據(jù)，我們也需要數(shù)以百計的box來存儲。因此我們把Kafka集群配置為將消息只保留幾個小時(這些時間足夠我們處理不期而至的重大故障)并且將數(shù)據(jù)盡快地存入永久存儲——亞馬遜簡易存儲服務(wù)(Amazon S3)。

我們廣泛地使用Storm來進行實時數(shù)據(jù)處理，第一個相關(guān)的Topology就是從Kafka讀取信息并存儲到Amazon S3上。

批量計算

一旦這些數(shù)據(jù)存到了S3上，我們可以使用亞馬遜彈性MapReduce(Amazon EMR)來計算我們的數(shù)據(jù)能夠計算的任何東西。這既包括要展示在客戶的儀表盤上的數(shù)據(jù)，也包括我們?yōu)榱碎_發(fā)新功能而開發(fā)的實驗性的任務(wù)。

我們使用Cascading框架編寫、Amazon EMR執(zhí)行MapReduce程序。 Amazon EMR將我們存儲到S3上的數(shù)據(jù)作為輸入，處理完畢后，再將結(jié)果存入S3。我們通過運行在Storm上的調(diào)度topology來探測程序執(zhí)行完畢，并將結(jié)果灌入Cassandra集群，這樣結(jié)果就能用于亞秒級查詢API。

#p#

實時計算

迄今，我們描述的是一個能夠執(zhí)行分析計算的持久的容錯的框架。然而，存在一個顯眼的問題——這個框架不是實時的。一些計算每小時計算一次，有的計算需要一整天的數(shù)據(jù)作為輸入。計算時間從幾分鐘到幾小時不等，把S3上的輸出導(dǎo)入到服務(wù)層也需要這么多時間。因此，在最好情況下，我們的數(shù)據(jù)也總是拖后幾個小時，顯然不能滿足實時和可操作的目標(biāo)。

為了達成實時的目標(biāo)，數(shù)據(jù)涌入后進行存檔的同時，我們對數(shù)據(jù)進行流式計算。

就像我們的存儲Topology讀取數(shù)據(jù)一樣，一個獨立的Storm Topology實時地從Kafka Topic中讀取數(shù)據(jù)然后進行實時計算，計算的邏輯和MapReduce任務(wù)一樣。這些實時計算的結(jié)果放在另一個獨立的Cassandra集群里以供實時查詢。

為了彌補我們在時間以及在資源方面可能的不足，我們沒有在批量處理層中而是在實時計算層中使用了一些概率算法，如布隆過濾器、 HyperLogLog(也有一些自己開發(fā)的算法)。相對于那些蠻力替代品，這些算法在空間和時間復(fù)雜度上有數(shù)量級的優(yōu)勢，同時只有可忽略的精確度損失。

合并

現(xiàn)在我們擁有兩個獨立生產(chǎn)出的數(shù)據(jù)集(批處理和實時處理)，我們怎么將二者合并才能得到一個一致的結(jié)果?

我們在API的邏輯中，根據(jù)特定的情況分別使用兩個數(shù)據(jù)集然后合并它們。

因為批量計算是可重現(xiàn)的，且相對于實時計算來說更容錯，我們的API總是傾向于使用批量產(chǎn)生的數(shù)據(jù)。例如，API接到了一個三十天的時間序列的日活躍用戶數(shù)量數(shù)據(jù)請求，它首先會到批量數(shù)據(jù)Cassandra集群里查詢?nèi)秶臄?shù)據(jù)。如果這是一個歷史數(shù)據(jù)檢索，所有的數(shù)據(jù)都已經(jīng)得到。然而，查詢的請求更可能會包含當(dāng)天，批量產(chǎn)生的數(shù)據(jù)填充了大部分結(jié)果，只有近一兩天的數(shù)據(jù)會被實時數(shù)據(jù)填充。

錯誤處理

讓我們來溫習(xí)幾個失效的場景，看一下這樣的架構(gòu)在處理錯誤的時候， 是如何避免宕機或者損失數(shù)據(jù)，取之以優(yōu)雅地降級。

我們在上文中已經(jīng)討論過設(shè)備上的回退重試策略。在設(shè)備端網(wǎng)絡(luò)中斷、服務(wù)器端短時無服務(wù)情況下，重試保證數(shù)據(jù)最終能夠到達服務(wù)器。隨機回退確保設(shè)備不會在某區(qū)域網(wǎng)絡(luò)中斷或者后端服務(wù)器短時間不可用之后，不會壓垮(DDos攻擊)服務(wù)器。

當(dāng)實時處理層失效時，會發(fā)生什么?我們待命的工程師會受到通知并去解決問題。因為實時處理層的輸入是存儲在持久化的Kafka集群里，所以沒有數(shù)據(jù)會丟失;等實時處理恢復(fù)之后，它會趕上處理那些停機期間應(yīng)該處理的數(shù)據(jù)。

因為實時處理和批處理是完全解耦的，批處理層完全不會受到影響。因此唯一的影響就是實時處理層失效期間，對數(shù)據(jù)點實時更新的延遲。

如果批處理層有問題或者嚴重延遲的話，會發(fā)生什么?我們的API會無縫地多獲取實時處理的數(shù)據(jù)。一個時間序列數(shù)據(jù)的查詢，可能先前只取一天的實時處理結(jié)果，現(xiàn)在就需要查詢兩到三天的實時處理結(jié)果。因為實時處理和批處理是完全解耦的，實時處理不受影響繼續(xù)運行。同時，我們的待命工程師會得到消息并且解決批處理層的問題。一旦批處理層恢復(fù)正常，它會執(zhí)行那些延遲的數(shù)據(jù)處理任務(wù)，API也會無縫切換到使用現(xiàn)在可以得到的批處理的結(jié)果。

我們系統(tǒng)后端架構(gòu)由四大組件構(gòu)成：事件接收，事件存儲，實時計算和批量計算。各個組件之間的持久化隊列確保任意組件的失效不會擴散到其他組件，并且后續(xù)可以從中斷中恢復(fù)。API可以在計算層延遲或者失效時無縫地優(yōu)雅降級，在服務(wù)恢復(fù)后重新恢復(fù);這些都是由API內(nèi)部的檢索邏輯來保證的。

Answer的目標(biāo)是創(chuàng)建一個儀表盤，這個儀表盤能夠把了解你的用戶群變得非常簡單。因此你可以將時間花費在打造令人驚嘆的用戶體驗上，而不是用來掘穿數(shù)據(jù)。從現(xiàn)在就開始，點擊此處更多了解Answers。

非常感謝致力于將此架構(gòu)實現(xiàn)(付諸現(xiàn)實)的Answers團隊。還有《Big Data》這本書的作者Nathan Marz。

貢獻者

Andrew Jorgensen, Brian Swift, Brian Hatfield, Michael Furtak, Mark Pirri, Cory Dolphin, Jamie Rothfeder, Jeff Seibert, Justin Starry, Kevin Robinson, Kristen Johnson, Marc Richards, Patrick McGee, Rich Paret, Wayne Chang.