棄用 Lambda，Twitter 啓用 Kafka 和數據流新架構
作者 | Lu Zhang、Chukwudiuto Malife
譯者 | Sambodhi
策劃 | 閆園園
在 Twitter 上，我們每天都要實時處理大約 4000 億個事件，生成 PB 級的數據。我們使用的數據的事件源多種多樣，來自不同的平臺和存儲系統，例如 Hadoop、Vertica、Manhattan 分佈式數據庫、Kafka、Twitter Eventbus、GCS、BigQuery 和 PubSub。
爲了處理這些源和平臺中的這些類型的數據，Twitter 數據平臺團隊已經構建了內部工具，如用於批處理的 Scalding，用於流的 Heron，用於批處理和實時處理的名爲 TimeSeries AggregatoR（TSAR）的集成框架，以及用於數據發現和消費的 Data Access Layer。然而，隨着數據的快速增長，高規模仍然給工程師們用來運行管道的數據基礎設施帶來了挑戰。比如，我們有一個交互和參與的管道，能夠以批處理和實時的方式處理高規模數據。由於數據規模的快速增長，對流延遲、數據處理的準確性和數據的實時性提出了更高的要求。
對於交互和參與的管道，我們從各種實時流、服務器和客戶端日誌中採集並處理這些數據，從而提取到具有不同聚合級別、時間粒度和其他度量維度的 Tweet 和用戶交互數據。這些聚合的交互數據尤其重要，並且是真正來自 Twitter 的廣告收入服務和數據產品服務檢索影響和參與度指標信息。此外，我們需要保證對存儲系統中的交互數據進行快速查詢，並在不同的數據中心之間實現低延遲和高準確性。爲了構建這樣一個系統，我們把整個工作流分解爲幾個部分，包括預處理、事件聚合和數據服務。
1 舊架構
舊的架構如下圖所示。我們的 Lambda 架構具有批處理和實時處理管道，構建在 Summingbird 平臺內，並與 TSAR 集成。如需進一步瞭解 Lambda 架構，請參閱《什麼是 Lambda 架構？》（What is Lambda Architecture？）。批處理組件源是 Hadoop 日誌，如客戶端事件、時間線事件和 Tweet 事件，這些都是存儲在 Hadoop 分佈式文件系統（HDFS）上的。我們構建了幾個 Scalding 管道，用於對原始日誌進行預處理，並且將其作爲離線來源攝入到 Summingbird 平臺中。實時組件來源是 Kafka 主題。
實時數據存儲在 Twitter Nighthawk 分佈式緩存中，而批處理數據存儲在 Manhattan 分佈式存儲系統中。我們有一個查詢服務，可以在這兩個存儲中存取實時數據，而客戶服務則會使用這些數據。
舊的 Lambda 架構
目前，我們在三個不同的數據中心都擁有實時管道和查詢服務。爲了降低批處理計算的開銷，我們在一個數據中心運行批處理管道，然後把數據複製到其他兩個數據中心。
現有挑戰
由於我們實時處理的數據規模大、吞吐量高，對於實時管道來說，可能會發生數據丟失、數據不準確的問題。對於 Heron 拓撲結構，當發生更多的事件需要處理，Heron Bolt 無法不能及時處理時，拓撲結構內會產生背壓。另外，由於垃圾收集成本很高，Heron Bolt 將會非常緩慢。
當系統長期處於背壓狀態時，Heron Bolt 會積累噴口滯後（spout lag），這表明系統延遲很高。通常當這種情況發生時，需要很長的時間才能使拓撲滯後下降。更多的時候，正如在我們的 Heron 管道中看到的那樣，也有很多 Heron 流管理器的 “死亡”（流管理器管理拓撲組件之間的圖元路由），而滯後不斷上升。
當前的操作方案是重啓 Heron 容器，將流管理器喚醒，以使 Bolt 能夠重新啓動處理流。這會在操作過程中造成事件丟失，從而導致 Nighthawk 存儲中的聚合計數不準確。
對於批處理組件，我們構建了幾條重型計算管道，這些管道用於處理 PB 級數據，每小時運行一次，將數據匯入 Manhattan。集中式 TSAR 查詢服務整合了 Manhattan 和 Nighthawk 的數據，爲客戶服務提供數據服務。由於實時數據的潛在損失，TSAR 服務可能爲我們的客戶提供較少的聚合指標。
爲了克服這一數據損失問題，減少系統延遲，並優化架構，我們建議在 Kappa 架構中構建管道，以純流模式處理這些事件。關於 Kappa 架構的更多信息，請參閱《什麼是 Kappa 架構？》（What is Kappa Architecture?）在該解決方案中，我們去掉了批處理組件，利用實時組件實現了低延遲和高準確度的數據，從而簡化了架構，減少了批處理管道中的計算成本。
2 Kafka 和數據流上的新架構
Kafka 和數據流上的新架構
新架構基於 Twitter 數據中心服務和谷歌雲平臺。我們在內部構建了預處理和中繼事件處理，將 Kafka 主題事件轉換爲具有至少一個語義的 pubsub 主題事件。在谷歌雲上，我們使用流數據流作業，對重複數據進行處理，然後進行實時聚合並將數據匯入 BigTable。
第一步，我們構建了幾個事件遷移器作爲預處理管道，它們用於字段的轉換和重新映射，然後將事件發送到一個 Kafka 主題。我們使用我們內部定製的基於 Kafka 的流框架創建了這些流管道，以實現一次性語義。第二步，我們構建了事件處理器，對具有最少一次語義的事件進行流處理。事件處理器處理向 Pubsub 事件表示法的轉換，並生成由 UUID 和其他與處理背景相關的元信息組成的事件背景。UUID 被下游的數據流工作器用來進行重複數據刪除。我們對內部的 Pubsub 發佈者採用了幾乎無限次的重試設置，以實現從 Twitter 數據中心向谷歌雲發送消息的至少一次。在新的 Pubsub 代表事件被創建後，事件處理器會將事件發送到谷歌 Pubsub 主題。
在谷歌雲上，我們使用一個建立在谷歌 Dataflow 上的 Twitter 內部框架進行實時聚合。Dataflow 工作器實時處理刪除和聚合。重複數據刪除的準確性取決於定時窗口。我們對系統進行了優化，使其在重複數據刪除窗口儘可能地實現重複數據刪除。我們通過同時將數據寫入 BigQuery 並連續查詢重複的百分比，結果表明了高重複數據刪除的準確性，如下所述。最後，向 Bigtable 中寫入包含查詢鍵的聚合計數。
對於服務層，我們使用 Twitter 內部的 LDC 查詢服務，其前端在 Twitter 數據中心，後端則是 Bigtable 和 BigQuery。整個系統每秒可以流轉數百萬個事件，延遲低至約 10 秒鐘，並且可以在我們的內部和雲端流系統中擴展高流量。我們使用雲 Pubsub 作爲消息緩衝器，同時保證整個內部流系統沒有數據損失。之後再進行重複數據刪除處理，以達到一次近似準確的處理。
這種新的架構節省了構建批處理管道的成本，對於實時管道，我們能夠實現更高的聚合精度和穩定的低延遲。在此期間，我們不必在多個數據中心維護不同的實時事件聚合。
3 評估
系統性能評估
下面是兩個架構之間的指標比較表。與舊架構中的 Heron 拓撲相比，新架構具有更低的延遲、更高的吞吐量。此外，新架構還能處理延遲事件計數，在進行實時聚合時不會丟失事件。此外，新架構中沒有批處理組件，所以它簡化了設計，降低了舊架構中存在的計算成本。
表 1：新舊架構的系統性能比較。
聚合計數驗證
我們將計數驗證過程分成兩個步驟。首先，我們在數據流中，在重複數據刪除之前和之後，對重複數據的百分比進行了評估。其次，對於所有鍵，我們直接比較了原始 TSAR 批處理管道的計數和重複數據刪除後數據流的計數。
第一步，我們創建了一個單獨的數據流管道，將重複數據刪除前的原始事件直接從 Pubsub 導出到 BigQuery。然後，我們創建了用於連續時間的查詢計數的預定查詢。同時，我們會創建另外一條數據流管道，把被扣除的事件計數導出到 BigQuery。通過這種方式，我們就可以看出，重複事件的百分比和重複數據刪除後的百分比變化。
第二步，我們創建了一個驗證工作流，在這個工作流中，我們將重複數據刪除的和彙總的數據導出到 BigQuery，並將原始 TSAR 批處理管道產生的數據從 Twitter 數據中心加載到谷歌雲上的 BigQuery。這樣我們就可以執行一個預定的查詢，以便對所有鍵的計數進行比較。
在我們的 Tweet 交互流中，我們能夠準確地和批處理數據進行超過 95% 的匹配。我們對低於 5% 的差異進行了研究，結果表明，這很大程度上是由於最初的 TSAR 批處理管道丟棄了後期事件，而這些事件被我們的新流管道捕獲。這進一步證明了我們目前的系統產生了更高的準確性。
4 結語
通過將建立在 TSAR 上的舊架構遷移到 Twitter 數據中心和谷歌雲平臺上的混合架構，我們能夠實時處理數十億的事件，並實現低延遲、高準確度、穩定性、架構簡單和減少工程師的運營成本。對於下一步，我們將使 Bigtable 數據集對區域故障具有彈性，並將我們的客戶遷移到新的 LDC 查詢服務器上。
作者介紹：
Lu Zhang，Twitter 高級軟件工程師。
Chukwudiuto Malife，Twitter 高級軟件工程師。
原文鏈接：
https://blog.twitter.com/engineering/en_us/topics/infrastructure/2021/processing-billions-of-events-in-real-time-at-twitter-
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/eauZCYfWZuolmmUVu_QBQA