Heron 新一代流处理框架详解

      最近公司需要开发新的流式ETL框架，我负责调研和测试Storm/Heron框架。Storm已经是非常成熟的流式处理框架了，在很多公司都在用，但是它在设计上也有诸多诟病，于是Twiter又开发了新的框架来代替Strom，这就是Strom2.0的Heron框架。 

    

      既然是要深入研究一个新的框架，于是我这花了一个星期将Heron和Strom的官方文档翻译了一遍，以及一篇非常重要的流式处理论文（来自Twiter，Twiter Heron: Stream Processing at Scale），将内容整理如下。

1. Storm介绍

Strom是一个流式数据实时计算系统，Strom的组件如下：

      1. Nimbus：负责资源分配和任务调度。

2. Supervisor：负责接受nimbus分配的任务，启动和停止属于自己管理的worker进程。
3. Worker：运行具体处理组件逻辑的进程。
4. Task：worker中每一个spout/bolt的线程称为一个task.
5. Executor：在storm0.8之后，task不再与线程对应，同一个spout/bolt的task可能会共享一个线程，默认情况下，一个线程对应一个task。
6. Topology：storm中运行的一个实时应用程序，因为各个组件间的消息流动形成逻辑上的一个拓扑结构。
7. Spout：在一个topology中产生源数据流的组件。通常情况下spout会从外部数据源中读取数据，然后转换为topology内部的源数据。
8. Bolt：在一个topology中接受数据然后执行处理的组件。Bolt可以执行过滤、函数操作、合并、写数据库等任何操作。
9. Tuple：一次消息传递的基本单元，是一个value list.
10. Stream：源源不断传递的tuple就组成了stream。

2. Storm存在的缺陷
   1. Woker进程设计上的缺陷

一台Supervisor运行着多个worker进程，每个worker进程跑着多个executor线程，而每个executor线程执行一个或多个task，storm有一套自己的优先算法来调度这一个executor线程在某个时间点应该run哪个task。但是，存在以下缺陷：

1. 很难定位一个executor线程中的某个task的性能。
2. Storm的worker就是一个JVM进程，每个worker可以跑多个executor线程，目前根据Storm现有的调度机制，我们无法确定那个task被分配到了哪个worker进程上，哪台物理机器上。由于不知道task被分配到哪个worker上，有可能是同一个，考虑join的情况，一个join task和一个output 到 DB Store或其他存储的task被分配到同一个worker，这样性能可能存在问题。
3. 一个executor线程会输出一个log文件，里面所有执行的task的信息都在里面，不好定位其中某个task的问题。
4. 当前正在跑的topology如果重启的话，之前分派在同一个worker的task由于toplogy重启，可能不会再被分配到同一个worker进程上，这给debug带来了困难。
5. 如果某个task有exception中断进程，整个worker进程被终止
6. 在实际的项目中，一个execuotr线程执行多个不同的task使得垃圾回收的问题很难 track down.
7. Storm默认每个worker进程的资源都是一样的。例如，一个worker需要5G，一个worker需要10G，那么我们就需配10G，这两个worker进程都是10G,浪费5G空间。
8. 如果对一个worker进程进行heap dump时，可能会阻塞worker hearbeats的发送，导致supervisor认为该worker心跳超时，kill 和重启了该worker Debugging problems becomes quite challenging as a result of this behavior.
9. Strom的worker进程使用线程来处理数据在task与worker进程之间的数据传输。在Strom中，每个tuple从进入storm到走出storm，在一个worker进程中需要通过四个线程的处理，这种设计很容易到达瓶颈，也很容易有Queue资源争夺的问题。 （ worker用thread和queue来做tuple的接收和发送，每个worker有一个receive-thread接收上游tuple，一个全局send-thread负责往下游发送tuple，然后executor有一个logic-thread来执行用户的代码逻辑，最后有一个本地的send-thread来做logic-thread和全局send-thread做数据通信，到这里，一个tuple需要从进入一个worker到出来总共要通过4个thread转发，效率很低。）

2.2  Storm Nimbus的设计缺陷

1. Storm的Nimbus任务很多，包括调度，监听，分发JAR等等，topology非常多的时候，Nimbus将变成瓶颈。
2. Nimbus不支持 worker进程细粒度的resource reservation和isolation。跑着不同Topology的worker进程在同一台Supervior上面运行，这会有抢资源相互影响的情况。Storm on YARN能够部分解决这种问题。
3. Storm使用Zookeeper来管理supervisor和worker的心跳，这种方式限制了每个Topology的worker进程数，也限制了集群中topology的总数。 如果topology很多，每个topology的并发很多，这样Zookeeper就是瓶颈。
4. Nimbus不是HA，Nimbus存在单点问题，一旦宕机，客户端将不能提交新的topology，也不能kill掉当前正在运行的topology。 Nimbus不是HA。

2.3  缺少Backpressure的机制

Storm没有backpressure机制，如果下游接收数据的bolt没有及时处理数据的话，上游发送者就会drop message。这是一种fail-fast机制，但是存在一些问题：

1. 如果是一个已知的问题，某个bolt已经停止响应，这种机制将会无限制的 tuple drops,当处于production环境时，而我们却很难发现这些 tuple drops.
2. Work done by upstream components is lost.
3. 系统的行为变得不可预知.

2.4  效率的缺陷

在Production环境中，我们会遇到各种各样的问题导致topology执行失败，导致 tuple failures, tuple replays, and execution lag。最常见的原因：

1. 一个tuple的失败会导致整个tuple tree的失败，这个topology会重新跑一次这个tuple tree。效率很低。
2. topology会消耗大量的RAM来应对worker进程遇到GC超过一分钟的时刻，这会导致tuple失败的可能性
3. 当一个worker进程跑多个executor线程的时候，transfer queues里面会有很多tuple。

3. Heron 介绍

3.1  Heron的设计目标

（1） 完全兼容Strom API

（2） 在性能、稳定性和监控等方面，Heron将会高于Strom，在data model方面，Heron使用process-based model 代替Strom的thread-based model。

（3） 解决以上Storm存在的问题

3.2  Heron设计简介

Heron是Storm的威力加强版，从架构的角度来看，Heron与Strom有着显著的不同，但是它却可以完美的兼容Strom API。用户通过Heron API发布topoloy到Scheduler。

每一个topology都作为一个Aurora的job在运行。每一个job会在多个container去执行，这些container由Aurora来分配和调度。第一个container作为Topology Master，

其他的多个container中。每个container都会run一个Stream Manager，一个Metrics Manager和多个Heron Instances进程（spouts和bolts）。多个container可以运行在一个物理节点上。Aurora将会根据每个节点的资源去调度每个container。Standby Topology Master能够作为HA。所有的元数据信息包括谁提交的job，job的运行信息，启动时间等等都会保存在Zookeeper中。 每个Heron Instance都是用java写的，且都是JVM进程。Heron进程之间用protocol buffers进行通信。

3.3  Topology

You can think of a Heron cluster as a mechanism for managing the lifecycle of stream-processing entities called topologies. More information can be found in the Heron Topologies  document. （我们可以把Heron集群看作是一个用来管理流式处理实体的生命周期的一种机制，这种流式处理实体被叫做Topology）

topology是一个有向非闭环图（ directed acyclic graph ），它被用来处理流式的数据. topologogy由三个基本部分组成： spouts  and  bolts ,  tuples ，如下图:

spout的作用是发送tuple到topology中，bolt的作用是处理这些tuple。在上面的图中，spout S1 产生tuples供给给bolts B1 和 B2 来处理，bolt B1处理tuple后将结果供给给B3 和 B4, 同样的， bolt B2处理tuple将结果供给给 B4.

3.3.1  Topology 的生命周期

当部署好一个Heron集群后，我们可以通过Heron Client来提交一个topology到Heron集群中，我们可以使用这个Heron Client来管理整个Heron的生命周期，topology的生命周期包括以下几个阶段:

1. submittopology：提交topology到Heron集群. 此时，topology还没有进行流式处理，但是已经被激活.
2. activatetopology. Topology即将开始流式处理，topology的处理架构已经创建.
3. restart  topology,当修改topology的配置后，需要重启topology
4. deactivate topology. 当反激活topology后，topology将不会再处理流式数据，但是进程依然存在在集群中。
5. kill   topology. 将topology从heron集群中彻底删除.

3.3.2  Spouts

spout是流式数据的来源，其作用是把tuple数据供给给topology. spout可以读取Kafka、hdfs等数据源，将流式数据输出给一个或多个bolt.

3.3.3  Bolts

bolt会消费从spout传过来的tuple流，执行一系列自定义的流式处理的操作，bolt的流式处理操作包括performing complex stream transformations, performing storage operations, aggregating multiple streams into one, emitting tuples to other bolts within the topology, and much more.

3.3.4  Logical Plan

topology的逻辑计划（logic plan）有点类似与数据库查询的执行计划. 上图就是一个logicial plan的例子.

3.3.5 Physical Plan

topology的物理计划（physical plan）是针对逻辑计划而言的， 物理计划（physical plan）是一个实际执行topology时候的拓扑计划图,其中包括 machines running each spout or bolt and more. 下图是一个物理计划:

3.3  Scheduler

这里的Scheduler是一个抽象的概念，我们可以使用Aurora调度器作为Scheduler。Aurora是一个通用的service调度器。Aurora的设计理念和Nimbus是一样的。当前Heron Scheduler支持Aurora，Local，Slurm，YARN。

3.4  State Manager

Heron State Manager会跟踪与监控每个正在运行的topology，每个topology包括logical plan, physical plan和topology的执行状态，当前Heron State Manager支持Local File System, Zookeeper。

3.5  Uploader

Heron uploader会分发topology的jar到各个服务器上来执行，Heron Uploader现在支持：HDFS，Local File System，Amazon S3

3.6 Container

每个topology都会有多个containers,每个container里面又有多个Heron Instance进程, 和一个Stream Manager, 和一个 Metrics Manager. Containers会和Topology Master进行通信，以此来确保topology能够形成一个充分connected的拓扑图.

3.7 Topology Master

TM（Topology Master）主要负责topology的throughout，在startup的时候，TM把信息存放在Zookeeper上，以便其他进程能够发现TM。所以TM有如下两个目的：

1. 阻止多个TM的产生
2. 允许其他属于该topology的进程发现该TMTopology Master管理topology，它会关注每个topology的status。
3. TM（Topology Master）作为一个gateway for topology metircs through an endpoint

Topology Master (TM) 管理着整个生命周期，从这个Topology被提交到Topology Master上，直到我们Kill掉这个Topology为止。

当客户端提交一个topology到Heron后， 一个Topology Master和多个container将会处理这个topology. Topology Master会在Zookeeper上创建一个临时的node来保存这个topology的相关信息来确保当前这个topology只有一个Topology Master来管理。通过Zookeeper上面的这个临时节点，这个topology的其他进程也能很容易的找到当前的Topology Master。Topology Master会为Topology创建一个 physical plan ，这个physical plan会被转发到各个topology component上，如下图：

Topology Master有一系列的配置参数可以调节一个topology的生命周期的每个阶段.

3.7  Stream Manager

Stream Manager的作用是管理每个tuple应该被哪个Heron Instance进程处理，每个tuple在各个topology components之间的路由，也被称作是tuple的路由（routing）。每个Heron Instance连接本地的Stream Manager来发送和接收tuple。在一个container中，一个tuple从一个Heron Instance到另外一个Heron Instance使用的是 local short-circuiting的机制。每个Stream Manager也会去连接其他所有的Stream Manager来形成一个network. 如下图就是一个Stream Manager Network:

Heron使用了backpressure的机制来动态的调节topology的流量通过率。这样可以让不同的task部分以不同的速度执行。例如，在后面阶段的任务处理速度slow down，这个时候如果前面的任务依然很快的执行，这就会导致数据的倾斜。因此Heron提供了这样的功能。

Heron提供一种背压机制来动态调整数据流动的速率。这种机制可以让topology中的各个components以不同speed来跑。也可以动态更改它的speed。

以下是几种实现Backpressure的策略：

1. TCP Backpressure

这个策略利用TCP窗口的机制来梳理HI（Heron Instance）和其他Component的backpressure。所有的消息都是通过TCP sockets来做通信，如果某个HI处理缓慢，那么它的本地接收buffer就会被装满，在这个HI上游和数据通信的SM也会发现这个然后填满发送的buffer，这样该HI的处理速度就加快了。

2. Spout backpressure

这个Backpressure策略是和TCP Backpressure策略协同使用的，当SM发现它本地的HI运行慢时，SM就会通知本地的Spout停止读取数据，那么往该Spout发送数据的SM的buffer就会阻塞以致fill up，这是受影响的SM就会发送一条start backpressure的message到其他与之相连的SM，当其他SM收到该message时就会告诉他们本地的Spout不再读取数据，当上游缓慢的HI速度赶上来之后，SM再发一个stop backpressure的message到下游，然后停止backpressure。

Stream Manager作为一个数据的路由引擎（routing engine）, 它propagating back pressure within the topology在实际生产环境中是非常重要的. 下图是一个Stream Manager实现backpressure的图:

在上面图中可以看到， ContainerA中的Bolt3接收所有的来自Spout1的输入. 当Bolt3的处理速度变慢的时候，ContainerA中的Stream Manager将会拒绝来自其他Stream Manager的数据输入，这将会使得在其他container的socket buffers填满，而导致整个崩溃。

在这种情况下，Heron的backpressure机制出现了，ContainerA中的Stream Manager将会发送一条message到其他的Stream Manager上，其他的Stream Manager在收到这条message后会检查自己的container的 physical plan ，并从spout断去切断向Bolt3输入，如下图.

当containerA中的Bolt3恢复后，containerA中的Stream Manager会再发送以条message去通知其他的Steam Manager去恢复topology.

3.8  Heron Instance

Heron Instance是一个java 进程，每个HI都是 只跑一个task ，即要么是spout要么是bolt。这样有利于debug。 这种设计也为以后数据的复杂性考虑，当以后数据复杂性变高的时候，我们还可以考虑用其他语言来实现HI。

HI的设计有以下两种：

（1） Single-threaded approach

主线程有一个TCP channel与本地的SM通信，等待tuple的到来，一旦tuple来了，就会调用用户的逻辑代码来执行，如果需要输出，该线程就会缓存数据，直到达到阈值，然后输出到downstream的SM。

这种设计简单，但是也有一些缺点，由于某些原因，用户的逻辑可能被block：

• Invoking the sleep system call for a finite duration of time
• Using read/write system calls for file or socket I/O
• Calling thread synchronization primitives

（2） Two-threaded approach

顾名思义，两个thread：Gateway thread 和Task Execution thread，如下图：

Gateway thread负责数据的输入输出和通信

Task Execution thread则负责运行用户逻辑代码

Gateway thread要和Task Execution thread要进行数据通信，他们之间通过如上图的三种queue来通信。Gateway thread用data-in往Task Execution thread输入数据，Task Execution thread用data-out往Gateway thread，metrics-out是用Task Execution thread用来收集metric然后往Gateway thread发送。

3.9  Metrics Manager

Metrics Manager从每个task任务中收集并导出metrics。这里的metrics包括系统级别的metrics和用户自定义的topology metrics.

每个container都有一个Metrics Manager，向这个container里面的Stream Manager和Heron Instance去report metrics。

每个container中，Metrics Manager发送metrics到monitoring system。Metrics Manager也会发送metrics到Topology Master，Topology Master会提供外部的UI页面展示。

Heron执行期间会收集一些metircs，这些metircs可以存下来做离线分析。当前的Heron支持以下集中sinks:

• File Sink
• Graphite Sink
• Scribe Sink

每个topology都会有一个MM服务在运行来收集metrics，并将metircs信息导出给当前container下的所有topology component. MM也会路由这些metrics信息给Topology Master和external collectors。Metrics我们可以自定义并实现。

3.10 执行流程

Topology Submit Sequence

Topology的生命周期描述了topology每个阶段的状态. 以下的序列图描述了当topology被提交到Heron集群后的一些列action。

当Heron CLI提交一个topology到Heron集群：

1. Aurora scheduler 为这个topology分发必要的资源，安排对应的topology container（TM和container）。
2. Topology Master作为第一个container出现，把信息同步到Zookeeper上，以便其他进程能够发现TM。
3. Stream Manager去Zookeeper同步信息去并找到Topology Master
4. Stream Manager连接Topology Master并周期性的发送心跳
5. 当所有的Stream Manager都已经连接到Topology Master后，Topology Master会根据Heron的分配算法把Topology的所有任务分配到包不同的container上。这个过程叫做“physical plan”，为了确保安全，Topology Master会把“physical plan”写到Zookeeper中。
6. 当“physical plan”完成后， Stream Manager会从Topology Master那里接收到完整的“physical plan”，这个"physical plan"能够帮助Stream Manager发现其他的Stream Manager。这些Stream Manager相互连接形成一个fully-connected network。
7. 在此时，Heron Instance进程会发现它们本地的Stream Manager，下载“physical plan”中对应它自己的那一部分，并开始执行。
8. 以上的步骤完成后，data/tuples starts flowing through the topology

11. 11.  失败场景处理

当一个topology在执行过程中，会有很多中情况导致失败，例如进程fail，container fail或是服务器宕机等，这些失败会影响topology的一部分或是整个topology。

当这个Topology Master进程死掉后，这个container会重启这个failed的进程，这个Topology Master会根据Zookeeper的数据来恢复宕机之前的状态。此时，standby Topology Master会继续处理topology的业务，刚刚重启的Topology Master将会成为standby。 与此同时，这些Stream Manager将会发现这个新的Topology Master，并去连接这个新的Topology Master。

类似地，当Stream Manager死掉后，在这个container中，这个Stream Manager会被restart，这个Stream Manager会重新发现当前的Topology Master，初始化一个connection去Topology Master获取最新的 “ physical plan”。其他的Stream Manager刚刚丢失了宕机的那个Stream Manager的connection，此时，这个Stream Manager被重启并且拿到了最新的 “ physical plan”，它们也会去这个Stream Manager得到一份指明了这个新的Stream Manager位置的 “ physical plan"，并且创建一个和一个新的Stream Manager位置的的连接。

当一个container里面的Heron Instance进程死掉了，这个Heron Instance会被重新restart，并重新连接它本地的Stream Manager，而后这个Heron Instance进程将会从这个Stream Manager中拿到一份 “ physical plan”的copy，通过这个 “ physical plan”可以让这个Heron Instance知道自己是一个spout还是bolt。然后继续执行。

当一个container被移动位置或rescheduled的时候，这个重启的Stream Manager会重新发现当前的Topology Master，然后就是以上#3，#4的流程。

3.12 Heron Topology Demo

以下是一段Heron Topology的Example:

3.13 Heron监控

当Heron集群在Production环境的时候，监控往往是最重要的部分，Heron提供以下功能：

1. ability for users to interact with their topologies
2. ability for users to view metrics and  trends for their topologies
3. ability for users to view exceptions that occurs in the Heron Instances

为了实现以上的功能，Heron增加了以下组件：Heron Tracker，Heron UI and Heron Viz

3.13.1  Heron Tracker

Heron Tracker是一个web服务，它提供了一套清晰完整的REST API,可以让我们很容易的扩展Heron的监控与Debug工具. 这套API提供了查询topology信息的途径，包括logical plan和physical plan,各种metircs指标，用户自定义的metircs和系统的metrics,以及log信息,也可以连接到Aurora job的页面。The tracker runs as an Aurora service, and typically is run in several instances for fault tolerance. The API requests are load balanced across these instances.

3.13.3  Heron UI

用户可以通过这个UI界面去和topology进行交互，展示topology的信息，包括 logical and physical plan，log信息，内存使用情况，metircs等。这个UI界面会使用Heron Tracker API

3.13.4  Heron Viz

Heron Viz是一个service服务，用于创建一个dashboard，通过这个dashboard可以查看由Metrics Manager统计的某个topology的metrics，这个Heron Viz会周期性的连接Heron Tracker查看是否有新的topology。当有新的Topology的时候，他会调用一个画图的API（Viz）去创建一个graphs dashboard，被称作 Heron Viz dashboard。这个dashboard里面会有这个topology的详细信息。Heron Viz dashboard也会根据为当前的Topology去创建一个health metrics， resource metrics, component metrics and stream manager (SM) metrics.

4． 总结

1. First, the provisioning of resources (e.g. for containers and even the Topology Master) is cleanly abstracted from the duties of the cluster manager, thereby allowing Heron to “play nice” with the rest of the (shared) infrastructure.
2. Second, Isolation, topologies should be process based rather than thread based, since each Heron Instance is executing only a single task (e.g. running a spout or bolt), and each process should run in isolation.it is easy to debug that instance by simply using tools like jstack and heap dump with that process, to profile and to troubleshoot.
3. Third, the design makes it transparent as to which component of the topology is failing or slowing down, as the metrics collection is granular, and lets us easily map an issue unambiguously to a specific process in the system.
4. Fourth, by allowing component-level resource allocation, Heron allows a topology writer to specify exactly the resources for each component, thereby avoiding unnecessary over-provisioning.
5. Fifth, having a Topology Master per topology allows each topology to be managed independently of each other (and other systems in the underlying cluster). In additional, failure of one topology (which can happen as user-defined code often gets run in the bolts) does not impact the other topologies.
6. Sixth, In a distributed system like Heron, there are no guarantees that all system components will execute at the same speed. Heron has built-in back pressure mechanisms to ensure that topologies can self-adjust in case components lag. The backpressure mechanism allows us to achieve a consistent rate of delivering results, and a precise way to reason about the system. It is also a key mechanism that allows migrating topologies from one set of containers to another (e.g. to an upgraded set of machines).
7. Finally, we now do not have any single point of failure.
8. Heron is fully API and data model compatible with Apache Storm