流处理系统Heron——architecture

简介

Heron是Twitter开源的分布式流处理系统，用来在Twitter内部替代Storm。它提供了和Storm兼容的API。并弥补了Storm中的不足。

Storm的不足和新的需求

1. 调试困难，在Storm中，一个topology的多个componetns捆绑在同一个进程中，使调试变得很困难。因此需要更清晰的逻辑单元到物理进程的映射关系。
2. Storm适用专用的集群资源的抽象，需要特定的资源分配方法。这使资源分配效率不高，也限制了按需扩展。因此需要能够适用流行的集群的调度系统提供更灵活的调度方式，这样可以实现集群资源被不同的数据处理系统共享。
3. Storm在部署新的topology时，需要手动隔离机器，在topology不使用时需要对机器进行收回。用这种方式进行管理机器非常的不便。
4. Nimbus实现的功能太多，需要处理调度、监控、JAR分发、性能指标的收集和topology的管理。会成为系统的瓶颈。
5. 缺少反压机制。
6. 效率问题。次优元组重传，元组失败时，需要重新传送这个元组树；过长的垃圾回收周期，导致高的延迟和元组失败率；传输队列存在很多的竞争。

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的进行显示。