這篇文章主要介紹了Twitter的實時信息分析服務Answers的架構,Answers的核心軟件采用Go語言編寫并且結合了Storm和Kafka的運用,實時處理能力相當驚人,需要的朋友可以參考下

2014年Twitter發布了Answers，至今移動社區產生了驚人的使用量，讓Twitter感到興奮不已?，F在Answers每天處理50億次會話，并且這個數量在持續增加。上億設備每秒向Answers端點發送數以百萬計的請求。在你已經閱讀到此處的這段時間里，Answers后臺收到并處理了一千萬次分析事件。

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

在高層，Twitter依靠 組件解耦、異步通信、在應對災難性故障時優雅地服務降級等原則來幫助架構決策。Twitter使用Lambda架構將數據完整性和實時數據更新結合起來。

在實踐過程中，Twitter需要設計一個能夠接收并保存事件、執行離線和實時計算且能將上述兩種計算結果整合成相關信息的系統。這些行為全部都要以百萬次每秒的規模執行。

讓Twitter從第一個挑戰開始：接受并處理這些事件。

事件接收

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

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

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

存儲

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

Twitter廣泛地使用Storm來進行實時數據處理，第一個相關的Topology就是從Kafka讀取信息并存儲到Amazon S3上。

批量計算

一旦這些數據存到了S3上，Twitter可以使用亞馬遜彈性MapReduce(Amazon EMR)來計算Twitter的數據能夠計算的任何東西。這既包括要展示在客戶的儀表盤上的數據，也包括Twitter為了開發新功能而開發的實驗性的任務。

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

實時計算

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

為了達成實時的目標，數據涌入后進行存檔的同時，Twitter對數據進行流式計算。

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

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

合并

現在Twitter擁有兩個獨立生產出的數據集(批處理和實時處理)，Twitter怎么將二者合并才能得到一個一致的結果?

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

因為批量計算是可重現的，且相對于實時計算來說更容錯，Twitter的API總是傾向于使用批量產生的數據。例如，API接到了一個三十天的時間序列的日活躍用戶數量數據請求，它首先會到批量數據Cassandra集群里查詢全范圍的數據。如果這是一個歷史數據檢索，所有的數據都已經得到。然而，查詢的請求更可能會包含當天，批量產生的數據填充了大部分結果，只有近一兩天的數據會被實時數據填充。

錯誤處理

讓Twitter來溫習幾個失效的場景，看一下這樣的架構在處理錯誤的時候， 是如何避免宕機或者損失數據，取之以優雅地降級。

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

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

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

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

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

Answer的目標是創建一個儀表盤，這個儀表盤能夠把了解你的用戶群變得非常簡單。因此你可以將時間花費在打造令人驚嘆的用戶體驗上，而不是用來掘穿數據。