推ter已經用Heron替換了Storm

推ter已經用Heron替換了Storm。此舉將吞吐量最高提升了14倍，單詞計數拓撲時間延遲最低降到了原來的1/10，所需的硬件減少了2/3。

推ter使用 Storm 實時分析海量數據已經有好幾年了，并在2011年將其開源。該項目稍后開始在Apache基金會孵化，并在去年秋天成為頂級項目。Storm以季度為發布 周期，現在已經達到了0.9.5版本，并且正在向著人們期望的1.0穩定版前進。但一直以來，推ter都在致力于開發替代方案Heron，因為 Storm無法滿足他們的實時處理需求。

推ter的新實時處理需求包括 ：“每分鐘數十億的事件；大規模處理具有次秒級延遲和可預見的行為；在故障情況下，具有很高的數據準確性；具有很好的彈性，可以應對臨時流量峰值和管道阻塞；易于調試；易于在共享基礎設施中部署。” Karthik Ramasamy 是推ter 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通過協 議緩沖處理彼此間的通信，一臺機器上可以有多個容器。（要了解更多關于Heron內部架構的細節信息，請閱讀論文《 推ter Heron：大規模流處理 》。）

推ter已經用Heron完全替換了Storm。前者現在每天處理“數10TB的數據，生成數10億輸出元組”，在一個標準的單詞計數測試中，“吞吐量提升了6到14倍，元組延遲降低到了原來的五到十分之一”，硬件減少了2/3。

當被問到推ter是否會開源Heron時，Ramasamy說“在短時間內不會，但長期來看可能。”