Twitter的流處理器系統Heron——升級的storm，可以利用mesos來進行資源排程

2011年，Twitter釋出了開源的分散式流計算系統Storm。四年後，隨著使用者數量的急劇增加，Twitter每天要處理的事件已經增加到十億以上。Storm系統應對如此龐大而複雜多樣的流資料變得十分困難。為了解決該問題，Twitter公司近期開發了一套全新的流處理系統——Heron。近日，Twitter公司在SIGMOD 2015會議上對Heron進行了介紹。

據Twitter公司的技術經理Karthik Ramasamy表示，Twitter公司之前對Storm所存在的問題以及新平臺的功能需求進行了詳細分析。首先，Storm除錯能力較弱的問題曾讓Twitter員工比較困擾。在Storm中，一個拓撲中的多個元件是捆綁在作業系統的一個程式中的。這就使得在拓撲出現問題時很難迅速定位問題的根源。使用者不得不借助cleaner對映來幫助實現邏輯計算單元到物理程式的對映，從而輔助除錯。此外，Storm還需要專門的叢集資源來執行拓撲。這就使得它不能利用流行的叢集排程軟體進行計算資源的優化。而且，在使用Storm時，使用者需要手動隔離機器才能部署一個新的產品拓撲。同樣，在拓撲不再使用時還需要手動回收機器資源。所有Storm存在的這些問題嚴重限制了Twitter處理事件的能力，而且帶來時間和計算資源的巨大浪費。因此，Twitter認為新的系統需要具備能夠每分鐘處理上億的事件、大規模處理資料的延遲為亞秒級、行為可預測、高資料精度、遇到區域性流量過高或流水線擁堵時能夠自行調整輸入速率、除錯方便以及能夠在共享式框架中部署等功能。

據Karthik透露，Twitter當初考慮了三種可能的方案——擴充套件現有的Storm系統、利用別的已經開源的系統和開發一套新的系統。然而，Storm系統的核心部件並不能滿足現有的需求，而對其進行修改又需要比較長的開發週期。同時，其他的開源流處理框架不能滿足Twitter在規模、吞吐量以及延遲等方面的需求。更關鍵的是，它們不能與Storm的API相相容，遷移工作會十分複雜。因此，Twitter最終決定開發一套全新的實時流處理系統。

根據設計要求，Heron保持了與Storm相同的資料模型和API，執行的也是由spout和bolt構成的拓撲。其總體框架包含了一個排程器和若干個拓撲。該排程器只是一個抽象模型，可以具體化為YARN、Mesos或者ECS等，方便資源共享。使用者利用API提交拓撲到排程器後，排程器把每個拓撲當作一個單獨的任務，並根據叢集中節點利用情況分派若干個容器來執行。在這些容器中，其中一個執行拓撲master，負責管理拓撲。剩餘的每一個容器都需要執行一個流管理器來負責資料路由、一個metric管理器負責收集和報告各種各樣的metric以及若干個Heron例項程式來執行使用者自定義的spout/bolt程式碼。最後，拓撲的後設資料，如物理規劃和執行細節等都被儲存在ZooKeeper中。

因此，Heron能夠輕鬆部署在執行如Mesos、YARN或者自定義排程框架的共享架構中。而且，Heron向後相容Storm，使得原來基於Storm的其它系統可以繼續使用。在Heron中執行已有的Storm拓撲完全不需要任何改變，移除了複雜的遷移過程。容器中的Heron例項執行的是單獨的任務，保證了使用者利用jstack或者heap dump等工具即可進行例項的除錯。Metric收集器又使得拓撲中任何元件的失效變得十分明顯，大大降低了除錯的難度。此外，Heron有一個背壓機制能夠在執行過程中動態調整拓撲中資料流的速度，而不影響資料精度。同時，與2013年 10月釋出的Storm相比，Heron的吞吐量可以到達其10-14倍，而延遲時間卻只是它的1/15-1/5，資源消耗也更低。

目前，Heron已經作為Twitter的主要流處理器系統在執行，其中包括了數百個拓撲。由於Heron的低資源消耗特性，遷移後的新系統硬體減少了2/3，大大提高了物理資源的利用率。Karthik也表示，Twitter公司非常願意與Storm社群或者其他開源的實時流處理系統社群分享Heron的經驗和教訓。

 

轉自：http://www.infoq.com/cn/news/2015/06/Heron-Twitter

本文轉自張昺華-sky部落格園部落格，原文連結：http://www.cnblogs.com/bonelee/p/6401186.html，如需轉載請自行聯絡原作者