Twitter實時處理大約4000億事件,并每天生成一個PB(petabyte)的數(shù)據(jù)。Twitter從多種事件源消費數(shù)據(jù),例如分布式數(shù)據(jù)庫、Kafka、Twitter事件總線等。
Twitter訂閱源中的事件調(diào)用示例
在這篇文章中,我們將嘗試理解:
為了處理事件,Twitter有自己的一套內(nèi)部工具,例如:
在我們深入了解事件系統(tǒng)如何演變之前,讓我們簡要了解一下這四種內(nèi)部工具。
TimeSeriesAggregator:
Twitter的數(shù)據(jù)工程團隊面臨著每天處理數(shù)十億事件的挑戰(zhàn),無論是批處理還是實時處理。TSAR是一個健壯的、可擴展的、實時事件時間序列聚合框架,主要用于監(jiān)控參與度:聚合與推文的互動,按多種維度(如設(shè)備、參與類型等)進行分段。
讓我們在非常高的層次上檢查Twitter的工作原理。所有Twitter功能都由遍布全球的微服務(wù)支持,包括超過10萬個實例。它們負責(zé)生成事件,這些事件被發(fā)送到事件聚合層,該層由Meta的一個開源項目構(gòu)建。這一層負責(zé)對這些事件進行分組,運行聚合作業(yè),并將數(shù)據(jù)存儲在HDFS中。然后處理這些事件,并進行格式轉(zhuǎn)換,重新壓縮數(shù)據(jù),以創(chuàng)建格式良好的數(shù)據(jù)集。
Twitter的舊架構(gòu)基于lambda架構(gòu),它包括批處理層、速度層和服務(wù)層。批處理部分是由客戶端生成的日志,并在事件處理后存儲在Hadoop分布式文件系統(tǒng)(HDFS)上。Twitter構(gòu)建了幾個擴展管道,用于預(yù)處理原始日志,并將它們作為離線源攝入到Summingbird平臺中。速度層的實時組件源是Kafka主題。
一旦數(shù)據(jù)被處理,批處理數(shù)據(jù)就存儲在Manhattan分布式系統(tǒng)中,而實時數(shù)據(jù)則存儲在Twitter自己的分布式緩存Nighthawk中。TSAR系統(tǒng),如TSAR查詢服務(wù),查詢緩存和數(shù)據(jù)庫,是服務(wù)層的一部分。
Twitter在三個不同的數(shù)據(jù)中心有實時管道和查詢服務(wù)。為了減少批處理計算成本,Twitter在一個數(shù)據(jù)中心運行批處理管道,并將數(shù)據(jù)復(fù)制到其他兩個數(shù)據(jù)中心。
你能想到為什么實時數(shù)據(jù)會存儲在緩存中而不是數(shù)據(jù)庫中嗎?
讓我們嘗試理解這種架構(gòu)在實時事件處理中可能遇到的挑戰(zhàn)。
讓我們用一個例子來理解這一點:
假設(shè)有一個大事件,如FIFA世界杯。推文源將開始向推文拓撲發(fā)送大量事件。解析推文的bolts無法及時處理事件,拓撲內(nèi)部出現(xiàn)了背壓。當(dāng)系統(tǒng)長時間處于背壓狀態(tài)時,heron bolts可能會積累spout滯后,這表明系統(tǒng)延遲高。Twitter觀察到,當(dāng)這種情況發(fā)生時,拓撲滯后的下降需要很長時間。
團隊使用的操作解決方案是重啟Heron容器以重新開始處理流。這可能導(dǎo)致操作期間事件丟失,從而導(dǎo)致緩存中聚合計數(shù)的不準確。
現(xiàn)在讓我們嘗試理解批處理事件的例子。Twitter有幾個重計算管道處理PB級別的數(shù)據(jù),并每小時運行一次,以將數(shù)據(jù)同步到Manhattan數(shù)據(jù)庫中。現(xiàn)在讓我們想象一下,如果同步作業(yè)需要超過一個小時,而下一個作業(yè)已經(jīng)安排開始。這可能導(dǎo)致系統(tǒng)的背壓增加,并可能導(dǎo)致數(shù)據(jù)丟失。
正如我們所看到的,TSAR查詢服務(wù)整合了Manhattan和緩存服務(wù),為客戶提供數(shù)據(jù)。由于實時數(shù)據(jù)可能丟失,TSAR服務(wù)可能會向客戶提供不準確的指標。
讓我們嘗試理解促使他們解決這個問題的客戶和業(yè)務(wù)影響:
現(xiàn)在,這意味著如果我們想根據(jù)用戶生成的事件更新用戶的時間線,或者根據(jù)用戶與Twitter系統(tǒng)的互動進行用戶行為分析,客戶將無法做到,因為他們需要等待批處理完成。
新架構(gòu)建立在Twitter數(shù)據(jù)中心服務(wù)和Google Cloud平臺上。Twitter構(gòu)建了一個事件處理管道,將kafa主題轉(zhuǎn)換為pub sub主題,然后發(fā)送到Google Cloud。在Google Cloud上,流數(shù)據(jù)流作業(yè)執(zhí)行實時聚合,并將數(shù)據(jù)沉入BigTable中。
對于服務(wù)層,Twitter使用了一個在Twitter數(shù)據(jù)中心前端和Bigtable及Bigquery后端的LDC查詢服務(wù)。整個系統(tǒng)可以以低延遲(約10毫秒)流式處理每秒數(shù)百萬事件,并且在高流量期間可以輕松擴展。
這種新架構(gòu)節(jié)省了構(gòu)建批處理管道的成本,對于實時管道,Twitter能夠?qū)崿F(xiàn)更高的聚合精度和穩(wěn)定的低延遲。此外,他們不需要在多個數(shù)據(jù)中心維護不同的實時事件聚合。
與舊架構(gòu)中的Heron拓撲相比,新架構(gòu)提供了更低的延遲,并提供了更高的吞吐量。此外,新架構(gòu)處理了延遲事件計數(shù),并且在進行實時聚合時不會丟失事件。更重要的是,新架構(gòu)中沒有批處理組件,因此簡化了設(shè)計并減少了舊架構(gòu)中存在的計算成本。
通過將基于TSAR的舊架構(gòu)遷移到Twitter數(shù)據(jù)中心和Google Cloud平臺的混合架構(gòu),Twitter能夠?qū)崟r處理數(shù)十億事件,并實現(xiàn)低延遲、高精度、穩(wěn)定性、架構(gòu)簡化和降低工程師的運營成本。
本文鏈接:http://www.www897cc.com/showinfo-26-83612-0.htmlTwitter如何優(yōu)化處理4000億事件的流程
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: 銘瑄科技出席 2024 英特爾網(wǎng)咖及電競酒店行業(yè)生態(tài)論壇 為電競生態(tài)貢獻力量
下一篇: Python的這個特性,省了我一大堆代碼