Twitter如何升級Hadoop+Kafka架構實現實時處理數十億個事件？

在Twitter，我們每天實時處理大約 4000 億個事件並生成 PB 級資料。我們消費資料的事件源有很多種，它們在不同的平臺和儲存系統中產生，例如 Hadoop、Vertica、Manhattan 分散式資料庫、Kafka、Twitter Eventbus、GCS、BigQuery 和 PubSub。

為了處理這些來源和平臺中的這些型別的資料，Twitter 資料平臺團隊構建了內部工具，例如用於批處理的 Scalding、用於流式處理的 Heron、用於批處理和實時處理的名為 TimeSeries AggregatoR (TSAR) 的整合框架，以及用於資料發現和消費的資料訪問層。然而，隨著資料的快速增長，大規模仍然挑戰著工程師用來執行管道的資料基礎設施。例如，我們有一個互動和參與管道，可以批量和實時處理大規模資料。隨著我們的資料規模快速增長，我們面臨著減少流延遲並提供更高的資料處理準確性以及實時資料服務的高要求。

對於互動和參與管道，我們從各種實時流以及伺服器和客戶端日誌中收集和處理資料，以提取具有各種聚合級別、時間粒度和其他指標維度的推文和使用者互動資料。聚合的互動資料尤其重要，並且是 Twitter 的廣告收入服務和資料產品服務檢索印象和參與度指標資訊的真實來源。此外，我們需要保證跨資料中心對儲存系統中互動資料的快速查詢，低延遲、高準確率。為了構建這樣一個系統，我們將整個工作流拆分為幾個元件，包括預處理、事件聚合和資料服務。

舊架構

舊架構如下圖所示。我們有一個包含批處理和實時處理管道的 lambda 架構，在 Summingbird 平臺內構建並與 TSAR 整合。有關 lambda 架構的更多資訊，請參閱什麼是 Lambda 架構？批處理元件源是儲存在 Hadoop 分散式檔案系統 (HDFS) 上的 Hadoop 日誌，例如客戶端事件、時間線事件和 Tweet 事件。我們構建了幾個 Scalding 管道來預處理原始日誌並將它們作為離線源攝取到 Summingbird Platform 中。實時元件源是 Kafka 主題。 

實時資料儲存在 Twitter Nighthawk 分散式快取中，批量資料儲存在曼哈頓分散式儲存系統中。我們有一個查詢服務來訪問來自兩個商店的實時資料，供客戶服務使用。

目前，我們在 3 個不同的資料中心擁有實時管道和查詢服務。為了降低批量計算成本，我們在一個資料中心執行批量管道並將資料複製到其他 2 個資料中心。 

現有架構的問題與挑戰

由於我們實時處理的資料規模大、吞吐量大，因此實時管道可能會丟失資料和不準確。對於 Heron 拓撲，在需要處理的事件較多且 Heron bolt 無法及時處理的情況下，拓撲內部存在背壓。此外，由於垃圾收整合本高，Heron bolts 會變慢。

當系統長時間處於背壓下時，Heron bolt 會累積 spout 延遲，這表明系統延遲很高。通常發生這種情況時，拓撲滯後需要很長時間才能下降。更常見的是，如我們的 Heron 管道中所見，也有許多 Heron Stream Manager 死亡（Stream Manager 管理拓撲元件之間的元組路由），並且延遲不斷增加。

當前的操作解決方案是重新啟動 Heron 容器以啟動流管理器，以便螺栓可以重新啟動處理流。這可能會導致操作期間的事件丟失，從而導致 Nighthawk 儲存中的聚合計數不準確。

對於批處理元件，我們構建了幾個處理 PB 級資料並每小時執行一次以將資料匯入曼哈頓的繁重計算管道。集中式 TSAR 查詢服務整合曼哈頓和夜鷹資料，為客戶服務提供資料服務。由於潛在的實時資料丟失，TSAR 服務可能向我們的客戶提供較少的聚合指標。

為了克服這個資料丟失問題，減少系統延遲並優化架構，我們建議在 kappa 架構中構建管道，以僅流模式處理事件。有關 kappa 架構的更多資訊，請參閱什麼是 Kappa 架構？在該解決方案中，我們移除了批處理元件並依靠實時元件來提供低延遲和高精度的資料，這簡化了架構並消除了批處理管道中的計算成本。

Kafka 和資料流的新架構

上圖是Kafka 和 Dataflow 的新架構 

新架構建立在 Twitter 資料中心服務和 Google Cloud Platform 之上。在內部，我們構建了預處理和中繼事件處理，將 Kafka 主題事件轉換為具有至少一次語義的釋出訂閱主題事件。在 Google Cloud 上，我們使用流式 Dataflow 作業來應用重複資料刪除，然後執行實時聚合並將資料匯入 BigTable。

第一步，我們構建了幾個事件遷移器作為預處理管道，它們執行轉換和重新對映欄位，然後將事件傳送到 Kafka 主題。我們使用基於 Kafka 的內部定製流框架為至少一次語義建立了這些流管道。作為第二步，我們構建了事件處理器來以至少一次語義流式傳輸事件。事件處理器處理到 Pubsub 事件表示的轉換，並生成由 UUID 和其他與處理上下文相關的元資訊組成的事件上下文。UUID 用於下游的 Dataflow 工作器進行重複資料刪除。我們為內部 Pubsub Publisher 應用幾乎無限重試設定，以實現至少一次將訊息從 Twitter 資料中心傳送到 Google Cloud。建立新的 Pubsub 表示事件後，

在 Google Cloud 上，我們使用基於 Google Dataflow 構建的 Twitter 內部框架進行實時聚合。Dataflow 工作人員實時處理重複資料刪除和聚合。重複資料刪除過程的準確性取決於定時視窗。我們調整了我們的系統以在重複資料刪除視窗中實現最大努力重複資料刪除。我們通過同時將資料寫入 BigQuery 並連續查詢重複的百分比，證明了高重複資料刪除的準確性，如下所述。最後，將帶有查詢鍵的聚合計數寫入 Bigtable。

對於服務層，我們使用 Twitter 內部 LDC 查詢服務，前端在 Twitter 資料中心和不同的後端，例如 Bigtable 和 BigQuery。整個系統每秒可以流式傳輸數百萬個事件，延遲低至約 10 秒，並且可以在我們的本地和雲流式傳輸系統中以高流量進行擴充套件。我們使用 Cloud Pubsub 作為訊息緩衝區，同時保證我們的本地流媒體系統不會丟失資料。然後是重複資料刪除以實現近乎一次的處理。

這種新架構節省了構建批處理流水線的成本，對於實時流水線，我們能夠實現更高的聚合精度和穩定的低延遲。此外，我們不需要在多個資料中心維護不同的實時事件聚合。

。。。

結論

通過將基於 TSAR 的舊架構遷移到 Twitter 資料中心和谷歌雲平臺上的混合架構，我們能夠實時處理數十億事件，並實現低延遲、高精度、穩定性、架構簡單和降低運營成本對於工程師。