Heron（二）—-系统架构

Heron的总体架构如图1所示，用户开发的代码通过aurora scheduler的命令行进行提交，aurora schedule是一个跑在mesos上的框架。

 

图1

topology会以一个aurora任务的方式运行，topology包含持有一些container。如图2所示。第一个container运行的进程叫topology Master。其余的container运行Stream Manager，Metrics Manager和一些Heron Instance。多个container可以运行在一个物理机上，container的资源调度和分配是由aurora基于物理节点上的资源情况进行。会有一个standby的Topology Master。topology的元数据信息保存在zookeeper里面。每个Heron instance会有一个独立的JVM。所有的进程之间通信使用protobuf。

图2

Topology Master（TM）

Topology Master（TM）负责管理真个topology的生命周期 ，他是了解整个topolgy状态的唯一接口（有点像YARN中的APP MASTER）。

Stream Manager（SM）

Stream Manager（SM）的主要功能是高效的管理tuple路由。每个Heron Instance（HI）连接到本地的SM去发送和接受数据。所有的SM之间互相有网络连接。

Heron Instance（HI）

HI执行一个spoult或者bolt的代码，与storm worker不同，每个HI是一个独立java进程，而且值跑一个spoult或者bolt的task。这样方便我们调试或者优化某个spoult/bolt，而且日志也比较清晰。

HI进程中有两个线程，三个队列，如图3所示。gateway线程负责控制所有的通信和数据的接入和输出。该线程通过TCP连接到本地的SM和Metrics Manager，负责从本地的SM接受数据，把数据发送给Task execution线程进行处理。Task Execution线程运行用户代码，用户代码发出的数据发送给gateway线程，有gateway线程发送给本地的SM。同时Task Execution线程会收集tuple执行的数量，发送tuple等数据，处理延时等metric信息。gateway线程和Task Execution线程通过三个单向的队列进行通信。gateway线程通过datain队列推送数据给Task Execution线程处理，Task Execution线程通过data-out队列发送数据给Gateway线程，metrics-out队列用来Task Execution线程发送metric数据给Dateway 线程。

                                                    图3

Metrics Manager（MM）

Metrics Manager从系统所有的元组收集导出Metrics信息，包括系统和用户自定义的metrics。每个container有一个MM，SM和HI汇报metrics给MM。

系统的启动顺序

当用户提交一个作业时

1）Aurora分配一定的资源需要的资源。

2）TM启动，并向zk注册零食节点

3）SM启动，通过zk发现TM，并连接到TM

4）所有的SM连接后，TM进行任务分配，分配信息叫物理执行计划，物理执行计划会被写入到zk

5）SM从TM获取物理执行计划，SM之间互相建立连接，形成一个网状图

6）HI启动，发现SM，并且下载物理执行计划，并且开始执行

系统容错

1）如果TM死了，TM会被重启，并重新从zk恢复状态。如果启动了standby TM，standby TM会编程主TM，被重启的变成standby。所有SM会重建连接到TM

2）如果SM死了，container会重启TM，重新下载物理执行计划，重建连接。（杨晓青注：SM是被哪个进程进行重启论文没有说清楚，从论文看没有重启container而container中只有SM，MM，和一些HI，不知道那个进程监控TM的失败并重启。aurora不太了解，以yarn来推断，如果SM是leader进程，SM死了整个container应该被重启的，如果SM不是leader，那应该还有个leader进程在才对）

3）HI死了，HI会重启，从新获取物理执行计划，运行自己的代码逻辑

4）如果整个container被从新分配和调度了，新分配的container会按照启动流程进行启动所有的进程。