推ter開源了流數據處理引擎Heron

推ter 宣布 開源Heron。Heron是 Apache Storm 的后繼者，也是一種流數據處理引擎。為方便開發人員對Heron的采用，Heron向后兼容Apache Storm。Heron所給出的可擴展性、調試能力、在共享集群架構中的工作能力以及更優的性能，使得其在推ter內部已取代Apache Storm成為推ter流數據處理引擎。在 文檔 中給出了Heron的完全特性列表。

針對這次發布，InfoQ擇機訪談了推ter技術經理和Heron項目的合作創始人Karthik Ramasamy。

InfoQ： 讓我們從Apache Storm開始。是哪些Apache Storm的技術限制，導致你們去啟動一個新的項目而非去對原始項目做改進？

Karthik Ramasamy：對于當前推ter的規模而言，在可擴展性、可調試性、可管理性、對其它數據服務有效地共享集群資源等方面，使用Apache Storm變得愈發具有挑戰性。

在Storm中，來自于同一拓撲結構（Topology）中多個組件的任務被塞入到同一個操作系統進程中，這使得調試變得十分的困難。此外，Storm需要專用的集群資源，這使得運行Storm 拓撲結構需要特別的硬件資源分配。這種工作方式導致了對珍貴的集群資源的低效使用，也限制了應用按需擴展的能力。

使用Storm時，籌備新的生產拓撲結構時需要對機器做手動隔離，同樣反之當應用不再需要該拓撲結構時，被分配服務于該拓撲結構的機器必須要停止服務。這種方式下的機器分配管理是十分繁瑣的。

最終，在無需被迫去重寫大量已基于Storm開發的應用的情況下，我們想要去達成上面所列出的所有目標。

在對多個方面檢查之后，我們得出這樣的一個結論，即為滿足上面所列出的所有目標，我們需要設計一個新的流數據處理系統。該新系統被稱為Heron項目。Heron是API兼容于Storm的，這使得現有的Storm用戶易于遷移到Heron上，并且新用戶也易于在Heron上做應用開發。現在推ter內部的所有生產拓撲結構已經運行在Heron上。這除了為我們提供了相對于Storm而言顯著的性能提升和更低的資源消耗，Heron在可調試性、可擴展性和可關聯性上具有巨大的優越性。

InfoQ： 僅在Apache中就有很多的流數據處理架構。Heron與這些項目相比有哪些不同之處？

Ramasamy：我們的設計理念概述于我們發表于SIGMOD 2015會議上的論文 “推ter Heron: Stream Processing at Scale”（2015年5月） 中。推ter在Storm 拓撲結構開發中投入了大量精力，此外一些其它的企業也正在一定規模上運行或立志要去運行流數據處理應用。實際上Storm并非是僅為我們自身的需求而需要擴展，也是為了其它的一些解決方案的需求，這些解決方案看上去并非十分成熟，并需要對現有拓撲結構進行完全且高代價的重組。

當前的局面驗證了我們對世界趨向于實時化這個最初的預測。以極低延遲分析實時數據的需求正在持續增長。在許多快速擴展的實時用例中都應用了Heron，其中包括了異常和欺詐檢測、物聯網和萬物互聯應用、嵌入式系統、虛擬現實和增強現實、廣告投放、金融、安全和社會媒體。

當前局面中的主要變數在于大規模應用中可靠性的驗證。Storm是前期的解決方案之一，在按需升級到Heron后，故障發生報告降低了10倍，運行也更加的高效。這些問題可能在當前系統中大規模地存在，但這也是存在變數的，因為推ter具有其它的企業所仍未體驗到的獨特需求。我們很高興看到該生態系統的增長，我們將繼續承擔開源空間中的引領者角色。

InfoQ： 在你的博客中提及Heron是流數據處理架構中的一個根本性變革。你為什么會這么說？

Ramasamy：從基于線程的Storm到基于進程的Heron是在流數據處理架構中的根本改進。這種改進使得用戶易于對他們拓撲結構的工作情況進行推理，并能對拓撲結構中的各個組件進行獨立地性能分析和調試。雖然實現該改進需要對Storm進行完全重寫，但是該改進使得Heron 拓撲結構的開發更加簡單并增強了可調試能力。我們認為這種在架構開發上的投資已經得到了回報，體現為故障情況報告得到了10倍的降低，這證明了Heron“恰好適用”于推ter規模上。

InfoQ： 推ter是Heron項目的最大貢獻者嗎？還有哪些公司也對Heron有貢獻？

Ramaswamy：由于近期我們剛開源了該平臺，所以推ter當前絕對是Heron的主導貢獻者，但是我們驚喜于其它的一些大規模企業對采用并為Heron做出貢獻所表現出的興趣。Heron被證實可工作于推ter這樣的規模上，這在我們看來對于流數據處理架構而言是獨一無二的，其它的企業正借用我們的設計及實現去進一步地改寫該系統。尤其是，正如我們在最初發布中所披露的，Microsoft在使用Apache REEF將Heron工作于YARN上具有關鍵的貢獻，并為進一步改進計算效率給出了一種復雜的打包算法。我們已經具有50位貢獻者，他們提交了超過900次的提交請求（Pull Request），我們期待這些貢獻會繼續地增長。

我們也很高興地看到，大型中國的企業對Heron進行了標定，并將其用于一些我們所知的推ter之外的最大規模集群上。我們正在緊密合作，期望更多的企業名字能得到公布。

我們一直致力于開源社區的提交。先于Heron，我們曾貢獻了 Apache Storm ，它開源于2011年。還有集群資源管理器 Apache Mesos 、MapReduce流數據處理架構 Summingbird 以及更近期提交的高性能日志復制服務 DistributedLog 。我們是帶著將其開源的目標來對Heron進行開發的。自最初的SIGMOD論文發表以來，不斷的有人詢問我們Heron的開源計劃，尤其是很多咨詢來自于其它的一些企業，這些或是在很大的規模上運行并具有實時處理的需求，或是與我們面對同樣的生產問題并想使用可獲取的經驗。我們很高興看到所有這些對Heron的興趣，并很高興看到Heron被采用。

InfoQ： 對Apache Storm的向后兼容性被看作是開發人員采用Heron的關鍵因素。該特性是否在所有將來版本中也是有保證的？你能從開發人員的角度提出一些告誡，并從實現者的角度給出一些挑戰嗎？

Ramasamy：推ter用例可被無縫支持是至關重要的，該用例主要是向后兼容我們對Storm的使用。但是在Apache Storm中還包括了我們從不需要且永不會去支持的新用例，這些用例主要是分布式遠程過程調用（Distributed Remote Procedure Calls，DRPC）。現在Heron已經開源，我們發現一些有積極性的貢獻者有興趣去做對更多功能的支持，因而我們希望Apache Storm的未來版本將會繼續得到支持。在我們看來，盡快支持所需的所有語義并盡可能地保持Heron和Storm的兼容，這對于這兩者的生態系統都是有益的。

InfoQ：你能詳細說明一下Heron的路線圖嗎？

Ramasamy：在很大程度上，路線圖側重于快速而高效地支持除Apache aurora之外的主調度器。通過REFF和SLURM，Heron已得到了Apache YARN的支持。此外對Apache Mesos的支持雖然是實驗性，但是這種支持是穩定的。我們期待對DC/OS、Marathon和 Kubernetes的支持，并已正在開發實現中。我們以安裝簡單化和操作可靠性為目標。此外，我們正在擴展Heron的運維能力，目標包括熱部署、大型活動期間拓撲結構的手動擴展、拓撲結構的自動擴展等功能。我們還正在圍繞一些阻斷算法開展著工作，研究當分布式系統中存在拖后腿的節點和網絡分區時如何繼續對流數據進行處理。

雖然Heron將繼續側重于推ter的核心用例，但一些正在生產環境中測試的特性也即將被添加進來。如果你有興趣貢獻特定的特性，或是想要去改進現有的系統，請伸出你的手并加入Heron社區和Heronstreaming開發者協作群組（Slack Channel）。我們期待著Heron社區的進一步發展。

來自：http://www.infoq.com/cn/news/2016/10/推ter-opensources-heron