Heron數(shù)據(jù)實(shí)時(shí)分析平臺(tái)
Twitter開源了數(shù)據(jù)實(shí)時(shí)分析平臺(tái)Heron。
Twitter使用Storm實(shí)時(shí)分析海量數(shù)據(jù)已經(jīng)有好幾年了，并在2011年將其開源。該項(xiàng)目稍后開始在Apache基金會(huì)孵化，并在2015年秋天成為頂級(jí)項(xiàng)目。Storm以季度為發(fā)布周期，并且向著人們期望的穩(wěn)定版前進(jìn)。但一直以來，Twitter都在致力于開發(fā)替代方案Heron，因?yàn)镾torm無法滿足他們的實(shí)時(shí)處理需求。
Twitter現(xiàn)在已經(jīng)用Heron完全替換了Storm。前者現(xiàn)在每天處理“數(shù)10TB的數(shù)據(jù)，生成數(shù)10億輸出元組”，在一個(gè)標(biāo)準(zhǔn)的單詞計(jì)數(shù)測試中，“吞吐量提升了6到14倍，元組延遲降低到了原來的五到十分之一”，硬件減少了2/3。
當(dāng)被問到Twitter是否會(huì)開源Heron時(shí)，Ramasamy說“在短時(shí)間內(nèi)不會(huì)，但長期來看可能?！?/p>
然而就在2016年5月25日，Twitter正式宣布Heron開源。Twitter工程經(jīng)理Karthik Ramasamy在博客上宣布了這一消息。
Heron的基本原理和方法：
實(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)簡單部署。
為了滿足這些需求，Twitter討論出了幾種方案，包括：擴(kuò)展Storm、使用其他的開源系統(tǒng)、開發(fā)一個(gè)全新的平臺(tái)。因?yàn)橛袔讉€(gè)需求是要求改變 Storm的核心架構(gòu)，所以對(duì)它進(jìn)行擴(kuò)展需要一個(gè)很長的開發(fā)周期。其他的開源流處理框架并不能完美滿足Twitter對(duì)于規(guī)模、吞吐量和延遲的需求。而且，這些系統(tǒng)也不能兼容Storm API——適應(yīng)一個(gè)新的API需要重寫幾個(gè)topologies和修改高級(jí)的abstractions，這會(huì)導(dǎo)致一個(gè)很長的遷移過程。所以，Twitter決定建立 一個(gè)新的系統(tǒng)來滿足以上提到需求和兼容Storm API。
Heron的特色：
Twitter開發(fā)Heron，主要的目標(biāo)是增加性能預(yù)測、提高開發(fā)者的生產(chǎn)力和易于管理。
圖1：Heron架構(gòu)
圖2：拓?fù)浼軜?gòu)
對(duì)于Heron的整體架構(gòu)請(qǐng)看圖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)度。對(duì)于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，顯示邏輯計(jì)劃、物理計(jì)劃和拓?fù)錉顟B(tài)
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倍。
除此之外，Twitter已經(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)致Twitter的基礎(chǔ)設(shè)置效率有了顯著的提升。
了解更多：https://blog.twitter.com/2015/flying-faster-with-twitter-heron