twitter heron流计算系统总结 基本框架（一） --- 纸上谈兵

话说twitter一直在使用storm的作为其实时流计算的基础，storm于2011年开源，后来(什么时间忘了)成为了apache的顶级开源项目，现在为啥会舍弃了storm重新研发了heron呢？

首先是twitter的要求：

twitter对流计算系统需求：更好的扩展性、更容易调试debug、性能更好、更易管理（We need a system that scales better, has better debug-ability, has better performance，and is easier to manage )

然后是storm的问题: 

1. storm的设计中一个jvm进程对应着一个storm worker，一个storm worker有多个executor而executor里包含多个task，一个task又是由Spouts and bolts 组成，一个executor 又被映射到两个jvm线程，每个线程同时调度多个任务。 也技术是说一个jvm 进程内同时运行多个逻辑上互不关联的任务，不能做资源隔离，相互影响。 这种复杂的设计极大增加了调试的成本；并且多个task的log被写入一个log文件，爆出的异常排查起来比较困难。
2. 
3. 内存的使用不够高效，storm的设计中认为所有的worker都是一样对等的，分配资源时产生浪费（比如spout多个worker实际上是可以公用的，在storm现有的设计下每个worker必须有一个自己的spout，这样比不就浪费资源了吗 ）
4. 上线新的topology时需要人工对硬件资源做隔离，下线应用时原有的节点也不再使用。直接增加了系统管理的成本
5. storm的nimbus承担着带调度、监控、分发jar包的功能，负担比较重，没有资源隔离的功能； nimbus还是一个系统的单点
6. storm使用zk作为worker和nimbus的心跳检测，集群规模增大，topologies数量增大后zk就是瓶颈了（zk的能力你懂得，链接的数量和拼读都是有瓶颈的，负载高时会出现一些奇葩的问题）
   
7. storm没有back pressure机制，现在使用的是简单的fail-fask机制
8. storm现有的处理效率不够好：一个tuple在topology处理流程很长，在任何一个地方处理失败都会导致tuple重放，极端情况会导致tuple不断重放但是不做任何有意义的工作; 还有长时间的gc，还有队列的争抢。 为了避免这些问题，就需要提供比实际消耗要多很多倍的资源。

twitter考虑过Apache Samza [2] or Spark Streaming，但是接口不与storm兼容，很多应用需要需要重写。或者修改storm的core，修改现有系统的core实际开发的量恐怕比直接重写一个系统的时间更长吧。最后综合考虑，twitter决定写一个全新的流计算系统，于是heron就诞生了。现在twitter的所有生产环境中的topologies已经切换到了heron上并且稳定运行。

heron的架构

 

heron的与storm一样也分为topology，但是运行在Aurora上调度。 storm是由nimbus调度的，这与storm的设计师很不一样的。heron的设计人员考虑Aurora比较成熟就没有必要再去搞一套自己的调度了。

heron基本结构:

container

上述的几个组件合起来称为一个container，twitter内部一个container被映射为一个linux cgroups。所有的heron进程之间基于protocolbufs通信。如上所说这些container是在Aurora上调度的。

Topology Master
在topology的整个生命周期内管理topology的状态，TM（Topology Master）在zk上创建一个临时节点做到服务发现，并且保证对同一个topology只有一个master TM。同事也是topology metrics的路由。 TM不在具体的数据处理路径上，所以不会是瓶颈。

Stream Manager
主要是管理tuple的路由，每个HI（heron instance的缩写）连接到自己本地的SM（Stream Manager） 每个SM和相关的SM连接接收、发送tuple( 对twitter这篇论文的疑问：SM不成了瓶颈了吗)。 每个SM的连接的个数是O(K2)，注意K不是整个集群中container的个数，而是topology 物理执行计划相关的container（或者SM）个数，不然连接数就太多了。 同一个container内部的HI之间传递tuple基于“local short-circuiting mechanism” 看这几个次的意思也明白了吧。

下面介绍heron SM的亮点功能

back pressure概述

  heron使用back pressure机制动态调节topology的tuple流速。 heron的back pressuer是如何实现的呢,heron的设计人员在论文中探讨了几种方法:tcp backpressure:使用tcp的windowing机制、spout backpressure 机制、Stage-by-Stage Backpressure 机制。 heron使用的是spout backpressure 机制，因为其容易实现，反应时间短，其在实际运行也是非常稳定有效的。

spout backpressure具体实现

每个socket channel与一个application level的buffer绑定，buffer与high water和low water标志位，当buffer size达到high water时backpressure就会触发直到buffer达到low water。 这种方法的好处是一旦tuple从spout出来后heron就不会扔掉，除非宕机或者进程挂掉，这样能使

tuple failure更有确定性。  当一个topology处于backpressure 模式时，处理的速度会与最慢的环节相同。

Heron Instance概述
与stormn不同HI是一个独立的jvm进程，可能是spout也可能是bolt，这样比较清晰，更容易debug，不会像storm一样很多spout、bolt在一个jvm进程内运行。

Heron Instance的实现

有两种实现方式：1、基于单线程的实现方式：一个线程既处理tcp通信又处理用户逻辑 2、两个线程分别处理tcp通信和用户逻辑。 heron选择了后一种，原因不用解释也能懂了。两个线程：Gateway Thread，Task Execution Thread。

Gateway Thread：分别用于控制从HI数据的出、入，维护一个loacal SM和metrics manager的tcp连接，还负责从local SM 接收tuples。

Task Execution Thread：执行user code， 对于bolt的case，当tuple到达时执行execute方法，对于spout的场景，会重复执行next tuple从数据源取出下一个tuple，将数据inject进入topology。  无论从bolt还是spout发射出来的数据会被送到gateway thread，gateway thread会将数据送入local SM。除此之外，Task Execution Thread还搜集metric信息：例如处理延迟、被发射出去的tuple数量。

Gateway Thread和Task Execution Thread基于三个丢雷进行数据交换： data-in data-out metric-out 三个队列。

为了减少gc的影响，heron周期性检测data-out data-in队列的大小，相应低increase decrease  队列的大小，周期性地执行直到队列到一个稳定的值或者变为0

Metrics Manager

MM收集并expor系统所有部件的metric信息，包括系统的metric和user metric，每一个containrer有一个metrics manager。

Startup Sequence and Failure Scenarios

启动流程：
提交任务- 》scheduler Aurora 分配资源，在多台机器上调度topolgy containers -> TM 在第一个container上出现 在zk上注册->同时 SM 连接到TM上，周期性发送心跳。

当所有的SM连接到TM上，TM根据分配算法分配topology的不同组件到不同的container上， 这叫做“物理计划” 分配完成后SM就会知道所有的SM并建立P2P的连接。

HI（heron instance)也启动发现local SM,然后下载自己那部分的 “物理计划” 开始执行。 随后tuple开始进入系统。  TM还会把TM“物理计划”写入zk防止丢失。

failure 情景：

TM die，SM die，container被重新调度这几种情形  脑补吧

参考：

《Twitter Heron: Stream Processing at Scale》

http://www.oschina.net/news/73811/twitter-open-source-heron
http://geek.csdn.net/news/detail/33750