官方文檔摘譯：我們每天在Twitter上處理著數(shù)十億的事件。正如你猜測的那樣，實(shí)時(shí)分析這些事件是一個(gè)巨大的挑戰(zhàn)。目前，我們主要的分析平臺(tái)是開源的分布式流計(jì)算系統(tǒng)Storm。但是隨著Twitter數(shù)據(jù)規(guī)模變大和多樣化，我們的需求已經(jīng)發(fā)生了改變。因此，我們設(shè)計(jì)了一個(gè)新系統(tǒng)Heron——實(shí)時(shí)分析平臺(tái)，它可完全兼容Storm的API。我們在昨天的SIGMOD 2015上正式推出。

基本原理和方法：

實(shí)時(shí)流系統(tǒng)是在大規(guī)模數(shù)據(jù)分析的基礎(chǔ)上實(shí)現(xiàn)系統(tǒng)性的分析。另外，它還需要：每分鐘處理數(shù)十億事件的能力、有秒級(jí)延遲，和行為可預(yù)見；在故障時(shí)保證數(shù)據(jù)的準(zhǔn)確性，在達(dá)到流量峰值時(shí)是彈性的，并且易于調(diào)試和在共享的基礎(chǔ)設(shè)施上實(shí)現(xiàn)簡單部署。

為了滿足這些需求，我們討論出了幾種方案，包括：擴(kuò)展Storm、使用其他的開源系統(tǒng)、開發(fā)一個(gè)全新的平臺(tái)。因?yàn)槲覀冇袔讉€(gè)需求是要求改變Storm的核心架構(gòu)，所以對它進(jìn)行擴(kuò)展需要一個(gè)很長的開發(fā)周期。其他的開源流處理框架并不能完美滿足我們對于規(guī)模、吞吐量和延遲的需求。而且，這些系統(tǒng)也不能兼容Storm API——適應(yīng)一個(gè)新的API需要重寫幾個(gè)topologies和修改高級(jí)的abstractions，這會(huì)導(dǎo)致一個(gè)很長的遷移過程。所以，我們決定建立一個(gè)新的系統(tǒng)來滿足以上提到需求和兼容Storm API。

Heron的特色：

我們開發(fā)Heron，主要的目標(biāo)是增加性能預(yù)測、提高開發(fā)者的生產(chǎn)力和易于管理。

圖1：Heron Architecture

圖2：Topology Architecture

對于Heron的整體架構(gòu)請看圖1和圖2。用戶使用Storm API來構(gòu)建和提交topologies來實(shí)現(xiàn)一個(gè)調(diào)度。調(diào)度運(yùn)行的每一個(gè)topology作為一個(gè)job，有幾個(gè)容器組成，其中一個(gè)容器運(yùn)行主topology，負(fù)責(zé)管理topology。每個(gè)剩余的容器運(yùn)行一個(gè)流管理器，負(fù)責(zé)數(shù)據(jù)路由——一個(gè)權(quán)值管理器，用來搜集和報(bào)告各種權(quán)值和多個(gè)Heron實(shí)例（運(yùn)行user-defined spout/bolt代碼）進(jìn)程。這些容器是基于集群中的節(jié)點(diǎn)的資源可用性來實(shí)現(xiàn)分配和調(diào)度。對于topology元數(shù)據(jù)，例如物理計(jì)劃和執(zhí)行細(xì)節(jié)，都是保管在Zookeeper中。

Heron功能：

Off the shelf scheduler：通過抽象出調(diào)度組件，我們可輕易地在一個(gè)共享的基礎(chǔ)設(shè)施上部署，可以是多種的調(diào)度框架，比如Mesos、YARN或者一個(gè)定制的環(huán)境。

Handling spikes and congestion：Heron 具有一個(gè)背壓機(jī)制，即在執(zhí)行時(shí)的一個(gè)topology中動(dòng)態(tài)地調(diào)整數(shù)據(jù)流，從而不影響數(shù)據(jù)的準(zhǔn)確性。這在流量峰值和管道堵塞時(shí)非常有用。

圖3：Heron UI showing logical plan, physical plan and status of a topology

Easy debugging：每個(gè)任務(wù)是進(jìn)程級(jí)隔離的，從而很容易理解行為、性能和文件配置。此外，Heron topologies復(fù)雜的UI如圖3所示，可快速和有效地排除故障問題。

Compatibility with Storm：Heron提供了完全兼容Storm的特性，所我們無需再為新系統(tǒng)投資太多的時(shí)間和資源。另外，不要更改代碼就可在Heron中運(yùn)行現(xiàn)有的Storm topologies，實(shí)現(xiàn)輕松地遷移。

Scalability and latency：Heron能夠處理大規(guī)模的topologies，且滿足高吞吐量和低延遲的要求。此外，該系統(tǒng)可以處理大量的topologies。

Heron性能

我們比較了Heron和Storm，樣本流是150,000個(gè)單詞，如下圖所示：

?圖4. Throughput with acks enabled

?圖5. Latency with acks enabled

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

除此之外，我們已經(jīng)運(yùn)行topologies的規(guī)模大概是數(shù)百臺(tái)的機(jī)器，其中許多實(shí)現(xiàn)了每秒產(chǎn)生數(shù)百萬次事件的資源處理，完全沒有問題。有了Heron，眾多topologies的每秒集群數(shù)據(jù)可達(dá)到亞秒級(jí)延遲。在這些案例中，Heron實(shí)現(xiàn)目標(biāo)的資源消耗能夠比Storm更低。

Heron at Twitter

在Twitter，Heron作為我們主要的流媒體系統(tǒng)，運(yùn)行數(shù)以百萬計(jì)的開發(fā)和生產(chǎn)topologies。由于Heron可高效使用資源，在遷移Twitter所有的topologies后，整體硬件減少了3倍，導(dǎo)致我們的基礎(chǔ)設(shè)置效率有了顯著的提升。

作者: hely 原文地址：https://blog.twitter.com/2015/flying-faster-with-twitter-heron