去年，twitter對外宣布了新的分布式流計算系統heron，随後消息稱twitter已經用heron替換了storm。此舉将吞吐量最高提升了14倍，單詞計數拓撲時間延遲最低降到了原來的1/10，所需的硬體減少了2/3。
twitter使用storm實時分析海量資料已經有好幾年了，并在2011年将其開源。該項目稍後開始在apache基金會孵化，并在去年秋天成為頂級項目。storm以季度為釋出周期，并且向着人們期望的穩定版前進。但一直以來，twitter都在緻力于開發替代方案heron，因為storm無法滿足他們的實時處理需求。
twitter的新實時處理需求包括：“每分鐘數十億的事件；大規模處理具有次秒級延遲和可預見的行為；在故障情況下，具有很高的資料準确性；具有很好的彈性，可以應對臨時流量峰值和管道阻塞；易于調試；易于在共享基礎設施中部署。”
karthik ramasamy是twitter storm/heron團隊的負責人。據他介紹，為滿足這些需求，他們已經考慮了多個選項：增強storm、使用一種不同的開源解決方案或者建立一個新的解決方案。增強storm需要花費很長時間，也沒有其它的系統能夠滿足他們在擴充性、吞吐量和延遲方面的需求。而且，其它系統也不相容storm的api，需要重寫所有拓撲。是以，最終的決定是建立heron，但保持其外部接口與storm的接口相容。
拓撲部署在一個aurora排程器上，而後者将它們作為一個由多個容器（cgroups）組成的任務來執行：一個topology master、一個stream manager、一個metrics manager（用于性能監控）和多個heron 執行個體(spouts和bolts)。拓撲的中繼資料儲存在zookeeper中。處理流程通過一種反壓機制實作調整，進而控制流經拓撲的資料量。除aurora外，heron還可以使用其它服務排程器，如yarn或mesos。執行個體運作使用者編寫的java代碼，每個執行個體一個jvm。heron通過協定緩沖處理彼此間的通信，一台機器上可以有多個容器。
twitter已經用heron完全替換了storm。前者現在每天處理“數10tb的資料，生成數10億輸出元組”，在一個标準的單詞計數測試中，“吞吐量提升了6到14倍，元組延遲降低到了原來的五到十分之一”，硬體減少了2/3。
當被問到twitter是否會開源heron時，ramasamy說“在短時間内不會，但長期來看可能。”
然而就在5月25日，twitter正式宣布heron開源。twitter工程經理karthik ramasamy在部落格上宣布了這一消息。
heron的基本原理和方法：
實時流系統是在大規模資料分析的基礎上實作系統性的分析。另外，它還需要：每分鐘處理數十億事件的能力、有秒級延遲，和行為可預見；在故障時保證資料的準确性，在達到流量峰值時是彈性的，并且易于調試和在共享的基礎設施上實作簡單部署。
為了滿足這些需求，twitter讨論出了幾種方案，包括：擴充storm、使用其他的開源系統、開發一個全新的平台。因為有幾個需求是要求改變 storm的核心架構，是以對它進行擴充需要一個很長的開發周期。其他的開源流處理架構并不能完美滿足twitter對于規模、吞吐量和延遲的需求。而且，這些系統也不能相容storm api——适應一個新的api需要重寫幾個topologies和修改進階的abstractions，這會導緻一個很長的遷移過程。是以，twitter決定建立 一個新的系統來滿足以上提到需求和相容storm api。
heron的特色：
twitter開發heron，主要的目标是增加性能預測、提高開發者的生産力和易于管理。
圖1：heron架構
圖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中動态地調整資料流，進而不影響資料的準确性。這在流量峰值和管道堵塞時非常有用。
圖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個單詞，如下圖所示：
圖4. throughput with acks enabled
圖5. latency with acks enabled
如圖4所示，heron和storm的吞吐量呈現線性增長的趨勢。然而，在所有的實驗中，heron吞吐量比storm高10–14倍。同樣在端至端延遲方面，如圖5所示，兩者都在增加，可heron延遲比storm低5–15倍。
除此之外，twitter已經運作topologies的規模大概是數百台的機器，其中許多實作了每秒産生數百萬次事件的資源處理，完全沒有問題。有了 heron，衆多topologies的每秒叢集資料可達到亞秒級延遲。在這些案例中，heron實作目标的資源消耗能夠比storm更低。
heron at twitter
在twitter，heron作為主要的流媒體系統，運作數以百萬計的開發和生産topologies。由于heron可高效使用資源，在遷移twitter所有的topologies後，整體硬體減少了3倍，導緻twitter的基礎設定效率有了顯著的提升。