引言

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 能夠實時處理數十億事件，並實現低延遲、高精度、穩定性、架構簡化和降低工程師的運營成本。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/II3UeTlFDNOxNt7F47yvdw