Twitter Heron架構介紹

我們每天在Twitter上處理着數十億的事件。正如你猜測的那樣,實時分析這些事件是一個巨大的挑戰。目前,我們主要的分析平臺是開源的分佈式流計算系統Storm。但是隨着Twitter數據規模變大和多樣化,我們的需求已經發生了改變。因此,我們設計了一個新系統Heron——實時分析平臺,它可完全兼容Storm的API。我們在昨天的SIGMOD 2015上正式推出。

基本原理和方法:

實時流系統是在大規模數據分析的基礎上實現系統性的分析。另外,它還需要:每分鐘處理數十億事件的能力、有秒級延遲,和行爲可預見;在故障時保證數據的準確性,在達到流量峯值時是彈性的,並且易於調試和在共享的基礎設施上實現簡單部署。

爲了滿足這些需求,我們討論出了幾種方案,包括:擴展Storm、使用其他的開源系統、開發一個全新的平臺。因爲我們有幾個需求是要求改變 Storm的核心架構,所以對它進行擴展需要一個很長的開發週期。其他的開源流處理框架並不能完美滿足我們對於規模、吞吐量和延遲的需求。而且,這些系統 也不能兼容Storm API——適應一個新的API需要重寫幾個topologies和修改高級的abstractions,這會導致一個很長的遷移過程。所以,我們決定建立 一個新的系統來滿足以上提到需求和兼容Storm API。

Heron的特色:

我們開發Heron,主要的目標是增加性能預測、提高開發者的生產力和易於管理。

https://img-my.csdn.net/uploads/201506/03/1433299944_4898.png

圖1:Heron架構

https://img-my.csdn.net/uploads/201506/03/1433299966_9679.png

圖2:拓撲架構

對於Heron的整體架構請看圖1和圖2。用戶使用Storm API來構建和提交topologies來實現一個調度。調度運行的每一個topology作爲一個job,有幾個容器組成,其中一個容器運行主 topology,負責管理topology。每個剩餘的容器運行一個流管理器,負責數據路由——一個權值管理器,用來蒐集和報告各種權值和多個 Heron實例(運行user-defined spout/bolt代碼)進程。這些容器是基於集羣中的節點的資源可用性來實現分配和調度。對於topology元數據,例如物理計劃和執行細節,都是 保管在Zookeeper中。

Heron功能:

  • Off the shelf scheduler:通過抽象出調度組件,我們可輕易地在一個共享的基礎設施上部署,可以是多種的調度框架,比如Mesos、YARN或者一個定製的環境。

  • Handling spikes and congestion:Heron 具有一個背壓機制,即在執行時的一個topology中動態地調整數據流,從而不影響數據的準確性。這在流量峯值和管道堵塞時非常有用。

https://img-my.csdn.net/uploads/201506/03/1433302007_7908.png

https://img-my.csdn.net/uploads/201506/03/1433302015_5819.png

圖3:Heron UI,顯示邏輯計劃、物理計劃和拓撲狀態

  • Easy debugging:每個任務是進程級隔離的,從而很容易理解行爲、性能和文件配置。此外,Heron topologies複雜的UI如圖3所示,可快速和有效地排除故障問題。

  • Compatibility with Storm:Heron提供了完全兼容Storm的特性,所我們無需再爲新系統投資太多的時間和資源。另外,不要更改代碼就可在Heron中運行現有的Storm topologies,實現輕鬆地遷移。

  • Scalability and latency:Heron能夠處理大規模的topologies,且滿足高吞吐量和低延遲的要求。此外,該系統可以處理大量的topologies。

Heron性能

我們比較了Heron和Storm,樣本流是150,000個單詞,如下圖所示:

https://img-my.csdn.net/uploads/201506/03/1433302715_6599.png

圖4. Throughput with acks enabled

https://img-my.csdn.net/uploads/201506/03/1433302725_9989.png

圖5. Latency with acks enabled

如圖4所示,Heron和Storm的吞吐量呈現線性增長的趨勢。然而,在所有的實驗中,Heron吞吐量比Storm高10–14倍。同樣在端至端延遲方面,如圖5所示,兩者都在增加,可Heron延遲比Storm低5–15倍。

除此之外,我們已經運行topologies的規模大概是數百臺的機器,其中許多實現了每秒產生數百萬次事件的資源處理,完全沒有問題。有了 Heron,衆多topologies的每秒集羣數據可達到亞秒級延遲。在這些案例中,Heron實現目標的資源消耗能夠比Storm更低。

Heron at Twitter

在Twitter,Heron作爲我們主要的流媒體系統,運行數以百萬計的開發和生產topologies。由於Heron可高效使用資源,在遷移Twitter所有的topologies後,整體硬件減少了3倍,導致我們的基礎設置效率有了顯著的提升。

下一步?

我們樂意協作和在Storm社區分享我們的經驗,或是其他實時流處理系統的社區,以便進一步促進這些程序的開發。

我們第一步是分享我們在SIGMOD 2015上的Heron研究論文。你會發現更多的細節:我們設計Heron的動機、系統的功能和性能,以及我們如何在Twitter上使用它。

致謝:

Sanjeev KulkarniMaosong FuNikunj BhagatSailesh MittalVikas R. Kedigehalli, Siddarth Taneja (@staneja),Zhilan ZweigerChristopher Kellogg, Mengdie Hu (@MengdieH) and Michael Barry.

「注:上面感謝的是Heron貢獻者,Twitter ID也給了出來,如果對這個系統很感興趣,不妨聯繫他們。」

還要着重感謝Storm社區,他們提供了很多的經驗教訓,幫助我們推進分佈式實時分析處理系統。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章