引言
Twitter實時處理大約4000億事件，并每天生成一個PB（petabyte）的資料。Twitter從多種事件源消費資料，例如分布式資料庫、Kafka、Twitter事件總線等。
Twitter訂閱源中的事件調用示例
在這篇文章中，我們将嘗試了解：
1.Twitter過去是如何處理事件的，以及那種方法存在哪些問題？2.是什麼業務和客戶影響促使Twitter遷移到新架構？3.新架構4.舊架構和新架構的性能比較。
為了處理事件，Twitter有自己的一套内部工具，例如：
1.Scalding是Twitter用于批處理的工具。2.Heron是Twitter自己的流處理引擎。3.TimeSeriesAggregator（TSAR）用于批處理和實時處理。
在我們深入了解事件系統如何演變之前，讓我們簡要了解一下這四種内部工具。
1.ScaldingScalding是一個Scala庫，可以輕松指定Hadoop MapReduce作業。Scalding建立在Cascading之上，Cascading是一個抽象了底層Hadoop細節的Java庫。Scalding與Pig相當，但提供了與Scala的緊密內建，将Scala的優勢帶入MapReduce作業中。2.HeronApache Heron是Twitter自己的流處理引擎，由于需要處理PB級别的資料，提高開發人員的生産力并簡化調試而開發。Heron中的流應用程式稱為拓撲。拓撲是一個有向無環圖，其節點表示資料計算元素，邊表示資料流動的流。有兩種類型的節點：1.Spouts：它們連接配接到資料源并将資料注入流中2.Bolts：它們處理傳入的資料并發出資料
想了解更多，請參考：https://blog.x.com/engineering/en_us/a/2015/flying-faster-with-twitter-heron
1.TimeSeriesAggregator
Twitter的資料工程團隊面臨着每天處理數十億事件的挑戰，無論是批處理還是實時處理。TSAR是一個健壯的、可擴充的、實時事件時間序列聚合架構，主要用于監控參與度：聚合與推文的互動，按多種次元（如裝置、參與類型等）進行分段。
讓我們在非常高的層次上檢查Twitter的工作原理。所有Twitter功能都由遍布全球的微服務支援，包括超過10萬個執行個體。它們負責生成事件，這些事件被發送到事件聚合層，該層由Meta的一個開源項目建構。這一層負責對這些事件進行分組，運作聚合作業，并将資料存儲在HDFS中。然後處理這些事件，并進行格式轉換，重新壓縮資料，以建立格式良好的資料集。
舊架構
Twitter的舊架構基于lambda架構，它包括批處理層、速度層和服務層。批處理部分是由用戶端生成的日志，并在事件處理後存儲在Hadoop分布式檔案系統（HDFS）上。Twitter建構了幾個擴充管道，用于預處理原始日志，并将它們作為離線源攝入到Summingbird平台中。速度層的實時元件源是Kafka主題。
一旦資料被處理，批處理資料就存儲在Manhattan分布式系統中，而實時資料則存儲在Twitter自己的分布式緩存Nighthawk中。TSAR系統，如TSAR查詢服務，查詢緩存和資料庫，是服務層的一部分。
Twitter在三個不同的資料中心有實時管道和查詢服務。為了減少批處理計算成本，Twitter在一個資料中心運作批處理管道，并将資料複制到其他兩個資料中心。
你能想到為什麼實時資料會存儲在緩存中而不是資料庫中嗎？
舊架構中的挑戰
讓我們嘗試了解這種架構在實時事件進行中可能遇到的挑戰。
讓我們用一個例子來了解這一點：
假設有一個大事件，如FIFA世界杯。推文源将開始向推文拓撲發送大量事件。解析推文的bolts無法及時處理事件，拓撲内部出現了背壓。當系統長時間處于背壓狀态時，heron bolts可能會積累spout滞後，這表明系統延遲高。Twitter觀察到，當這種情況發生時，拓撲滞後的下降需要很長時間。
團隊使用的操作解決方案是重新開機Heron容器以重新開始處理流。這可能導緻操作期間事件丢失，進而導緻緩存中聚合計數的不準确。
現在讓我們嘗試了解批處理事件的例子。Twitter有幾個重計算管道處理PB級别的資料，并每小時運作一次，以将資料同步到Manhattan資料庫中。現在讓我們想象一下，如果同步作業需要超過一個小時，而下一個作業已經安排開始。這可能導緻系統的背壓增加，并可能導緻資料丢失。
正如我們所看到的，TSAR查詢服務整合了Manhattan和緩存服務，為客戶提供資料。由于實時資料可能丢失，TSAR服務可能會向客戶提供不準确的名額。
讓我們嘗試了解促使他們解決這個問題的客戶和業務影響：
1.Twitter廣告服務是Twitter最主要的收入模式之一，如果其性能受到影響，直接影響他們的商業模式。2.Twitter提供各種資料産品服務來檢索印象和參與度名額的資訊；這些服務會因資料不準确而受到影響。3.另一個問題是，從事件建立到可用于使用可能需要幾個小時，因為批處理作業。這意味着用戶端進行的資料分析或任何其他操作将不會擁有最新資料。可能會有幾個小時的時間滞後。
現在，這意味着如果我們想根據使用者生成的事件更新使用者的時間線，或者根據使用者與Twitter系統的互動進行使用者行為分析，客戶将無法做到，因為他們需要等待批處理完成。
新架構
新架建構立在Twitter資料中心服務和Google Cloud平台上。Twitter建構了一個事件處理管道，将kafa主題轉換為pub sub主題，然後發送到Google Cloud。在Google Cloud上，流資料流作業執行實時聚合，并将資料沉入BigTable中。
對于服務層，Twitter使用了一個在Twitter資料中心前端和Bigtable及Bigquery後端的LDC查詢服務。整個系統可以以低延遲（約10毫秒）流式處理每秒數百萬事件，并且在高流量期間可以輕松擴充。
這種新架構節省了建構批處理管道的成本，對于實時管道，Twitter能夠實作更高的聚合精度和穩定的低延遲。此外，他們不需要在多個資料中心維護不同的實時事件聚合。
性能比較
與舊架構中的Heron拓撲相比，新架構提供了更低的延遲，并提供了更高的吞吐量。此外，新架構處理了延遲事件計數，并且在進行實時聚合時不會丢失事件。更重要的是，新架構中沒有批處理元件，是以簡化了設計并減少了舊架構中存在的計算成本。
結論
通過将基于TSAR的舊架構遷移到Twitter資料中心和Google Cloud平台的混合架構，Twitter能夠實時處理數十億事件，并實作低延遲、高精度、穩定性、架構簡化和降低工程師的營運成本。