簡介
Heron是Twitter開源的分佈式流處理系統，用來在Twitter內部替代Storm。它提供了和Storm兼容的API。並彌補了Storm中的不足。
Storm的不足和新的需求
- 調試困難，在Storm中，一個topology的多個componetns捆綁在同一個進程中，使調試變得很困難。因此需要更清晰的邏輯單元到物理進程的映射關係。
- Storm適用專用的集羣資源的抽象，需要特定的資源分配方法。這使資源分配效率不高，也限制了按需擴展。因此需要能夠適用流行的集羣的調度系統提供更靈活的調度方式，這樣可以實現集羣資源被不同的數據處理系統共享。
- Storm在部署新的topology時，需要手動隔離機器，在topology不使用時需要對機器進行收回。用這種方式進行管理機器非常的不便。
- Nimbus實現的功能太多，需要處理調度、監控、JAR分發、性能指標的收集和topology的管理。會成爲系統的瓶頸。
- 缺少反壓機制。
- 效率問題。次優元組重傳，元組失敗時，需要重新傳送這個元組樹；過長的垃圾回收週期，導致高的延遲和元組失敗率；傳輸隊列存在很多的競爭。
Heron的架構
用戶同過Heron cli工具向Aurora Scheduler創建和部署topoligy。Heron的提供了抽象的Sheduler接口，因此可以把Heron運行在其它的Scheduler，如YARN、Mesos等上。
每個Topology由若干的container組成，一個container中運行的是Topology Master，其它的container中運行了一個Stream Manager、一個Metrics Manager和若干部署spout/bolt的Heron Instance。
若干container可以運行在一個物理節點上。所有的Heron進程通過protobufs通信。
Topology Master
Topology Mastere（TM）僅負責管理特定的topology，不會設計數據的處理和轉發。啓動後，它會在Zookeep上建立一個臨時結點，用來防止多個TM管理同一個topology.也讓屬於這個topology的進程能夠發現該TM。TM也作爲topology metrics的gateway。
Stream Manager
Stream Manager(Sm)負責tuples的轉發，每個Heron Instance(HI)連接到它本地的進行手法tuples。同一個container的Hi，會使用本地的短路路由。
Heron Instance
Spout或blot的工作在Heron Instance(HI)中完成。每一個HI是一個JVM進程，只運行單個的spout或bolt任務。這樣設計的主要目的是方便調試和分析。
HI有兩個線程，分別是Gateway thread和Task Execution thread。Gateway thread通過TCP連接本地的SM和Metrics Manager，負責控制HI的通信和數據傳輸和接收/發往本地SM的tuple。Task Execution thread負責運行用戶的代碼，調用blot和spout的相關函數。Gateway thread和Task Execution thread之間通過三個隊進行通信：data-in、data-out、metrics-out。其中data-in和data-out隊列是固定大小的，當data-in達到界限後，會觸發本地SM的反壓機制，data-out帶到界限後，會讓Task Execution thread暫停發送或處理tuple。
Metrics Manager
Metrics Manager(MM)負責收集和報告系統中所有組件的metric。每個container中的Stream Manager和Heron Instance會向該container中的Metric Manager報告它們的metric。每個container中的metric發送到系統內的監控系統，也會傳送給Topology Master，用於在外部UI的進行顯示。