引言

Twitter實(shí)時(shí)處理大約4000億事件，并每天生成一個(gè)PB(petabyte)的數(shù)據(jù)。Twitter從多種事件源消費(fèi)數(shù)據(jù)，例如分布式數(shù)據(jù)庫、Kafka、Twitter事件總線等。

Twitter訂閱源中的事件調(diào)用示例

在這篇文章中，我們將嘗試?yán)斫猓?/p>

• Twitter過去是如何處理事件的，以及那種方法存在哪些問題?
• 是什么業(yè)務(wù)和客戶影響促使Twitter遷移到新架構(gòu)?
• 新架構(gòu)
• 舊架構(gòu)和新架構(gòu)的性能比較。

為了處理事件，Twitter有自己的一套內(nèi)部工具，例如：

• Scalding是Twitter用于批處理的工具。
• Heron是Twitter自己的流處理引擎。
• TimeSeriesAggregator(TSAR)用于批處理和實(shí)時(shí)處理。

在我們深入了解事件系統(tǒng)如何演變之前，讓我們簡要了解一下這四種內(nèi)部工具。

• Scalding：Scalding是一個(gè)Scala庫，可以輕松指定Hadoop MapReduce作業(yè)。Scalding建立在Cascading之上，Cascading是一個(gè)抽象了底層Hadoop細(xì)節(jié)的Java庫。Scalding與Pig相當(dāng)，但提供了與Scala的緊密集成，將Scala的優(yōu)勢帶入MapReduce作業(yè)中。
• Heron：Apache Heron是Twitter自己的流處理引擎，由于需要處理PB級別的數(shù)據(jù)，提高開發(fā)人員的生產(chǎn)力并簡化調(diào)試而開發(fā)。Heron中的流應(yīng)用程序稱為拓?fù)?。拓?fù)涫且粋€(gè)有向無環(huán)圖，其節(jié)點(diǎn)表示數(shù)據(jù)計(jì)算元素，邊表示數(shù)據(jù)流動的流。
• Spouts：它們連接到數(shù)據(jù)源并將數(shù)據(jù)注入流中
• Bolts：它們處理傳入的數(shù)據(jù)并發(fā)出數(shù)據(jù)

TimeSeriesAggregator：

Twitter的數(shù)據(jù)工程團(tuán)隊(duì)面臨著每天處理數(shù)十億事件的挑戰(zhàn)，無論是批處理還是實(shí)時(shí)處理。TSAR是一個(gè)健壯的、可擴(kuò)展的、實(shí)時(shí)事件時(shí)間序列聚合框架，主要用于監(jiān)控參與度：聚合與推文的互動，按多種維度(如設(shè)備、參與類型等)進(jìn)行分段。

讓我們在非常高的層次上檢查Twitter的工作原理。所有Twitter功能都由遍布全球的微服務(wù)支持，包括超過10萬個(gè)實(shí)例。它們負(fù)責(zé)生成事件，這些事件被發(fā)送到事件聚合層，該層由Meta的一個(gè)開源項(xiàng)目構(gòu)建。這一層負(fù)責(zé)對這些事件進(jìn)行分組，運(yùn)行聚合作業(yè)，并將數(shù)據(jù)存儲在HDFS中。然后處理這些事件，并進(jìn)行格式轉(zhuǎn)換，重新壓縮數(shù)據(jù)，以創(chuàng)建格式良好的數(shù)據(jù)集。

舊架構(gòu)

Twitter的舊架構(gòu)基于lambda架構(gòu)，它包括批處理層、速度層和服務(wù)層。批處理部分是由客戶端生成的日志，并在事件處理后存儲在Hadoop分布式文件系統(tǒng)(HDFS)上。Twitter構(gòu)建了幾個(gè)擴(kuò)展管道，用于預(yù)處理原始日志，并將它們作為離線源攝入到Summingbird平臺中。速度層的實(shí)時(shí)組件源是Kafka主題。

一旦數(shù)據(jù)被處理，批處理數(shù)據(jù)就存儲在Manhattan分布式系統(tǒng)中，而實(shí)時(shí)數(shù)據(jù)則存儲在Twitter自己的分布式緩存Nighthawk中。TSAR系統(tǒng)，如TSAR查詢服務(wù)，查詢緩存和數(shù)據(jù)庫，是服務(wù)層的一部分。

Twitter在三個(gè)不同的數(shù)據(jù)中心有實(shí)時(shí)管道和查詢服務(wù)。為了減少批處理計(jì)算成本，Twitter在一個(gè)數(shù)據(jù)中心運(yùn)行批處理管道，并將數(shù)據(jù)復(fù)制到其他兩個(gè)數(shù)據(jù)中心。

你能想到為什么實(shí)時(shí)數(shù)據(jù)會存儲在緩存中而不是數(shù)據(jù)庫中嗎?

舊架構(gòu)中的挑戰(zhàn)

讓我們嘗試?yán)斫膺@種架構(gòu)在實(shí)時(shí)事件處理中可能遇到的挑戰(zhàn)。

讓我們用一個(gè)例子來理解這一點(diǎn)：

假設(shè)有一個(gè)大事件，如FIFA世界杯。推文源將開始向推文拓?fù)浒l(fā)送大量事件。解析推文的bolts無法及時(shí)處理事件，拓?fù)鋬?nèi)部出現(xiàn)了背壓。當(dāng)系統(tǒng)長時(shí)間處于背壓狀態(tài)時(shí)，heron bolts可能會積累spout滯后，這表明系統(tǒng)延遲高。Twitter觀察到，當(dāng)這種情況發(fā)生時(shí)，拓?fù)錅蟮南陆敌枰荛L時(shí)間。

團(tuán)隊(duì)使用的操作解決方案是重啟Heron容器以重新開始處理流。這可能導(dǎo)致操作期間事件丟失，從而導(dǎo)致緩存中聚合計(jì)數(shù)的不準(zhǔn)確。

現(xiàn)在讓我們嘗試?yán)斫馀幚硎录睦?。Twitter有幾個(gè)重計(jì)算管道處理PB級別的數(shù)據(jù)，并每小時(shí)運(yùn)行一次，以將數(shù)據(jù)同步到Manhattan數(shù)據(jù)庫中?，F(xiàn)在讓我們想象一下，如果同步作業(yè)需要超過一個(gè)小時(shí)，而下一個(gè)作業(yè)已經(jīng)安排開始。這可能導(dǎo)致系統(tǒng)的背壓增加，并可能導(dǎo)致數(shù)據(jù)丟失。

正如我們所看到的，TSAR查詢服務(wù)整合了Manhattan和緩存服務(wù)，為客戶提供數(shù)據(jù)。由于實(shí)時(shí)數(shù)據(jù)可能丟失，TSAR服務(wù)可能會向客戶提供不準(zhǔn)確的指標(biāo)。

讓我們嘗試?yán)斫獯偈顾麄兘鉀Q這個(gè)問題的客戶和業(yè)務(wù)影響：

• Twitter廣告服務(wù)是Twitter最主要的收入模式之一，如果其性能受到影響，直接影響他們的商業(yè)模式。
• Twitter提供各種數(shù)據(jù)產(chǎn)品服務(wù)來檢索印象和參與度指標(biāo)的信息;這些服務(wù)會因數(shù)據(jù)不準(zhǔn)確而受到影響。
• 另一個(gè)問題是，從事件創(chuàng)建到可用于使用可能需要幾個(gè)小時(shí)，因?yàn)榕幚碜鳂I(yè)。這意味著客戶端進(jìn)行的數(shù)據(jù)分析或任何其他操作將不會擁有最新數(shù)據(jù)?？赡軙袔讉€(gè)小時(shí)的時(shí)間滯后。

現(xiàn)在，這意味著如果我們想根據(jù)用戶生成的事件更新用戶的時(shí)間線，或者根據(jù)用戶與Twitter系統(tǒng)的互動進(jìn)行用戶行為分析，客戶將無法做到，因?yàn)樗麄冃枰却幚硗瓿伞?/p>

新架構(gòu)

新架構(gòu)建立在Twitter數(shù)據(jù)中心服務(wù)和Google Cloud平臺上。Twitter構(gòu)建了一個(gè)事件處理管道，將kafa主題轉(zhuǎn)換為pub sub主題，然后發(fā)送到Google Cloud。在Google Cloud上，流數(shù)據(jù)流作業(yè)執(zhí)行實(shí)時(shí)聚合，并將數(shù)據(jù)沉入BigTable中。

對于服務(wù)層，Twitter使用了一個(gè)在Twitter數(shù)據(jù)中心前端和Bigtable及Bigquery后端的LDC查詢服務(wù)。整個(gè)系統(tǒng)可以以低延遲(約10毫秒)流式處理每秒數(shù)百萬事件，并且在高流量期間可以輕松擴(kuò)展。

這種新架構(gòu)節(jié)省了構(gòu)建批處理管道的成本，對于實(shí)時(shí)管道，Twitter能夠?qū)崿F(xiàn)更高的聚合精度和穩(wěn)定的低延遲。此外，他們不需要在多個(gè)數(shù)據(jù)中心維護(hù)不同的實(shí)時(shí)事件聚合。

性能比較

與舊架構(gòu)中的Heron拓?fù)湎啾?，新架?gòu)提供了更低的延遲，并提供了更高的吞吐量。此外，新架構(gòu)處理了延遲事件計(jì)數(shù)，并且在進(jìn)行實(shí)時(shí)聚合時(shí)不會丟失事件。更重要的是，新架構(gòu)中沒有批處理組件，因此簡化了設(shè)計(jì)并減少了舊架構(gòu)中存在的計(jì)算成本。

結(jié)論

通過將基于TSAR的舊架構(gòu)遷移到Twitter數(shù)據(jù)中心和Google Cloud平臺的混合架構(gòu)，Twitter能夠?qū)崟r(shí)處理數(shù)十億事件，并實(shí)現(xiàn)低延遲、高精度、穩(wěn)定性、架構(gòu)簡化和降低工程師的運(yùn)營成本。