2014年Twitter發(fā)布了Answers，至今移動社區(qū)產(chǎn)生了驚人的使用量，讓Twitter感到興奮不已?，F(xiàn)在Answers每天處理50億次會話，并且這個數(shù)量在持續(xù)增加。上億設備每秒向Answers端點發(fā)送數(shù)以百萬計的請求。在你已經(jīng)閱讀到此處的這段時間里，Answers后臺收到并處理了一千萬次分析事件。
其中的挑戰(zhàn)是如何利用這些信息向移動開發(fā)者提供可靠的、實時的、有實際價值的洞見（視角）去了解他們的移動應用。
在高層，Twitter依靠 組件解耦、異步通信、在應對災難性故障時優(yōu)雅地服務降級等原則來幫助架構(gòu)決策。Twitter使用Lambda架構(gòu)將數(shù)據(jù)完整性和實時數(shù)據(jù)更新結(jié)合起來。
在實踐過程中，Twitter需要設計一個能夠接收并保存事件、執(zhí)行離線和實時計算且能將上述兩種計算結(jié)果整合成相關信息的系統(tǒng)。這些行為全部都要以百萬次每秒的規(guī)模執(zhí)行。
讓Twitter從第一個挑戰(zhàn)開始：接受并處理這些事件。
事件接收
在設計設備-服務器通信的時候，Twitter的目標是：減少對電池和網(wǎng)絡使用的影響；確保數(shù)據(jù)的可靠性；接近實時地獲取數(shù)據(jù)。為了減少對設備的影響，Twitter批量地發(fā)送分析數(shù)據(jù)并且在發(fā)送前對數(shù)據(jù)進行壓縮。為了保證這些寶貴的數(shù)據(jù)始終能夠到達Twitter的服務器，在傳輸失敗隨機退避后以及達到設備存儲達到上限時，設備會進行重傳。為了確保數(shù)據(jù)能夠盡快到達服務器，Twitter設置來多個觸發(fā)器來使設備嘗試發(fā)送：當程序運行于前臺的時候，事件觸發(fā)器每分鐘觸發(fā)一次；一個消息數(shù)量觸發(fā)器和程序轉(zhuǎn)入后臺觸發(fā)器。
這樣的通信協(xié)議導致設備每秒發(fā)送來數(shù)以萬計壓縮過的有效載荷。每一個載荷都包含數(shù)十條事件。為了能夠可靠的、易于線性伸縮的方式去處理載荷，接收事件的服務必須極度簡單。
這個服務使用GO語言編寫，這個服務使用了亞馬遜彈性負載均衡器（ELB），并將每一個消息負荷放入一個持久化的Kafka隊列。
存儲
Kafka是一個持久存儲器，因為它把收到的消息寫入磁盤并且每個消息都有多份冗余。因此一旦Twitter知道信息到了Kafka隊列，Twitter就可以通過延遲處理、再處理來容忍下游延遲和下游失敗。然而，Kafka不是Twitter歷史數(shù)據(jù)的永久真理之源——按照上文提到的速度，僅僅是幾天的數(shù)據(jù)，Twitter也需要數(shù)以百計的box來存儲。因此Twitter把Kafka集群配置為將消息只保留幾個小時（這些時間足夠Twitter處理不期而至的重大故障）并且將數(shù)據(jù)盡快地存入永久存儲——亞馬遜簡易存儲服務（Amazon S3）。
Twitter廣泛地使用Storm來進行實時數(shù)據(jù)處理，第一個相關的Topology就是從Kafka讀取信息并存儲到Amazon S3上。
批量計算
一旦這些數(shù)據(jù)存到了S3上，Twitter可以使用亞馬遜彈性MapReduce（Amazon EMR）來計算Twitter的數(shù)據(jù)能夠計算的任何東西。這既包括要展示在客戶的儀表盤上的數(shù)據(jù)，也包括Twitter為了開發(fā)新功能而開發(fā)的實驗性的任務。
Twitter使用Cascading框架編寫、Amazon EMR執(zhí)行MapReduce程序。 Amazon EMR將Twitter存儲到S3上的數(shù)據(jù)作為輸入，處理完畢后，再將結(jié)果存入S3。Twitter通過運行在Storm上的調(diào)度topology來探測程序執(zhí)行完畢，并將結(jié)果灌入Cassandra集群，這樣結(jié)果就能用于亞秒級查詢API。
實時計算
迄今，Twitter描述的是一個能夠執(zhí)行分析計算的持久的容錯的框架。然而，存在一個顯眼的問題——這個框架不是實時的。一些計算每小時計算一次，有的計算需要一整天的數(shù)據(jù)作為輸入。計算時間從幾分鐘到幾小時不等，把S3上的輸出導入到服務層也需要這么多時間。因此，在最好情況下，Twitter的數(shù)據(jù)也總是拖后幾個小時，顯然不能滿足實時和可操作的目標。
為了達成實時的目標，數(shù)據(jù)涌入后進行存檔的同時，Twitter對數(shù)據(jù)進行流式計算。
就像Twitter的存儲Topology讀取數(shù)據(jù)一樣，一個獨立的Storm Topology實時地從Kafka Topic中讀取數(shù)據(jù)然后進行實時計算，計算的邏輯和MapReduce任務一樣。這些實時計算的結(jié)果放在另一個獨立的Cassandra集群里以供實時查詢。
為了彌補Twitter在時間以及在資源方面可能的不足，Twitter沒有在批量處理層中而是在實時計算層中使用了一些概率算法，如布隆過濾器、HyperLogLog（也有一些自己開發(fā)的算法）。相對于那些蠻力替代品，這些算法在空間和時間復雜度上有數(shù)量級的優(yōu)勢，同時只有可忽略的精確度損失。
合并
現(xiàn)在Twitter擁有兩個獨立生產(chǎn)出的數(shù)據(jù)集（批處理和實時處理），Twitter怎么將二者合并才能得到一個一致的結(jié)果？
Twitter在API的邏輯中，根據(jù)特定的情況分別使用兩個數(shù)據(jù)集然后合并它們。
因為批量計算是可重現(xiàn)的，且相對于實時計算來說更容錯，Twitter的API總是傾向于使用批量產(chǎn)生的數(shù)據(jù)。例如，API接到了一個三十天的時間序列的日活躍用戶數(shù)量數(shù)據(jù)請求，它首先會到批量數(shù)據(jù)Cassandra集群里查詢?nèi)秶臄?shù)據(jù)。如果這是一個歷史數(shù)據(jù)檢索，所有的數(shù)據(jù)都已經(jīng)得到。然而，查詢的請求更可能會包含當天，批量產(chǎn)生的數(shù)據(jù)填充了大部分結(jié)果，只有近一兩天的數(shù)據(jù)會被實時數(shù)據(jù)填充。
錯誤處理
讓Twitter來溫習幾個失效的場景，看一下這樣的架構(gòu)在處理錯誤的時候， 是如何避免宕機或者損失數(shù)據(jù)，取之以優(yōu)雅地降級。
Twitter在上文中已經(jīng)討論過設備上的回退重試策略。在設備端網(wǎng)絡中斷、服務器端短時無服務情況下，重試保證數(shù)據(jù)最終能夠到達服務器。隨機回退確保設備不會在某區(qū)域網(wǎng)絡中斷或者后端服務器短時間不可用之后，不會壓垮（DDos攻擊）服務器。
當實時處理層失效時，會發(fā)生什么？Twitter待命的工程師會受到通知并去解決問題。因為實時處理層的輸入是存儲在持久化的Kafka集群里，所以沒有數(shù)據(jù)會丟失；等實時處理恢復之后，它會趕上處理那些停機期間應該處理的數(shù)據(jù)。
因為實時處理和批處理是完全解耦的，批處理層完全不會受到影響。因此唯一的影響就是實時處理層失效期間，對數(shù)據(jù)點實時更新的延遲。
如果批處理層有問題或者嚴重延遲的話，會發(fā)生什么？Twitter的API會無縫地多獲取實時處理的數(shù)據(jù)。一個時間序列數(shù)據(jù)的查詢，可能先前只取一天的實時處理結(jié)果，現(xiàn)在就需要查詢兩到三天的實時處理結(jié)果。因為實時處理和批處理是完全解耦的，實時處理不受影響繼續(xù)運行。同時，Twitter的待命工程師會得到消息并且解決批處理層的問題。一旦批處理層恢復正常，它會執(zhí)行那些延遲的數(shù)據(jù)處理任務，API也會無縫切換到使用現(xiàn)在可以得到的批處理的結(jié)果。
Twitter系統(tǒng)后端架構(gòu)由四大組件構(gòu)成：事件接收，事件存儲，實時計算和批量計算。各個組件之間的持久化隊列確保任意組件的失效不會擴散到其他組件，并且后續(xù)可以從中斷中恢復。API可以在計算層延遲或者失效時無縫地優(yōu)雅降級，在服務恢復后重新恢復；這些都是由API內(nèi)部的檢索邏輯來保證的。
Answer的目標是創(chuàng)建一個儀表盤，這個儀表盤能夠把了解你的用戶群變得非常簡單。因此你可以將時間花費在打造令人驚嘆的用戶體驗上，而不是用來掘穿數(shù)據(jù)。
