Twitter Heron阅读笔记
说明：本文是《Twitter Heron: Stream Processing at Scale》的阅读记录整理，再结合网上其他资料整理而成，文中图片主要来自Heron论文和InfoQ上的宣传资料。
Storm的问题所在
Worker级别
Storm在worker设计上的问题应该是最多的。
- 所有task都一视同仁，无法对单个Task进行资源设置，会造成比较严重的资源浪费。拓扑越复杂，资源浪费越多。
- Task之间相互影响，单个Task故障会导致整个worker故障，进而产生连锁反应，导致其他worker也故障。
- 日志混合打印，worker的日志中，有spout和bolt的所有日志，比较乱，也比较多，对于问题定位和调试分析都是不利的。
- 对于dump等比较耗时的操作，会导致jvm暂停，然后worker的心跳会暂时无法写入，supervisor会误以为worker已经故障，会kill worker。
- 一个tuple在worker中处理要经过多个线程，比较繁琐，并且数据在多个线程之间切换比较低效。
至少会有四个线程：
Upstream thread：入口接收数据线程
Downstream thread：数据发送总出口
User logic thread：用户逻辑线程
Send thread：emit线程
Nimbus
- Nimbus任务过多，包含资源调度，jar包和序列化文件分发，metics汇聚，拓扑计数器等功能，在拓扑很多的情况下，很容易成为瓶颈
- 不支持资源隔离和资源预留，多个拓扑之间会相互影响。
- 和zookeeper之间会保存大量连接，频繁也会也会导致zookeeper成为瓶颈
- Nimbus是单点
注：Nimbus HA在社区1.0版本中已经实现
缺少背压机制(BackPressure)
三种背压机制实现
效率
- 单个tuple在整个tuple tree中如果在任何一个地方失败，都会从最开始的位置重发
- 垃圾回收周期过长，导致时延高和tuple失败
- Worker中的队列过多，导致队列之间互相竞争。
Heron架构设计
数据模型和API设计
数据模型和Storm保持一致，仍然包含spout和bolt的设计，twitter认为这是一个好的设计，所以仍然得以保留。
Heron 中的Toploogy就相当于数据库中的逻辑执行计划。只有在实际执行的时候才会变成物理执行计划。
在tuple的处理上，仍然和Storm保持一致，提供至少一次和最多一次的两种可靠性机制。
API完全兼容Storm，Twitter从Storm到Heron迁移只花了三个月就完成了全部迁移。
整体架构
Heron的整体架构如上图所示，拓扑提交之后，会通过调度器将topology分发到不同的节点。
以前的Storm有一个很大的缺点就是无法集成在Yarn或者Mesos上，即使后面有了Storm On Yarn也不是很理想的方案。资源仍然无法合理利用，还有多租户功能都依赖于资源管理的权限而无法实现。
Heron从架构上就解决了该问题，Scheduler就是一个Yarn或者Mesos的调度器。
拓扑总体架构上上图所示。
整个拓扑由一个Toplogy master和多个Container构成，拓扑中的运行逻辑就跑在Container中。一个continer就是一个资源隔离单元，包含了预留的CPU和内存资源。
Topology Master
负责管理当前拓扑，可以有多个实例，主备方式部署。
管理当前拓扑的路由信息，同时也会汇聚收集metrics信息。同时还包含拓扑的监控。
Stream Manager
Container内的独立进程。
负责tuple的有效路由，每个Heron Instance负责连接本地Stream Manager接收和发送数据，这种收发是通过protobuffer实现的。同时提供本地直接通讯方式。
提供Spout级别的背压机制，当流量过大，Heron处理不过来时候，从入口上减少数据量。在每个Socket channel上提供应用程序的buffer，并在此基础上加入高水位和低水位功能，当buffer中的数据超过高水位之后，背压触发，减少Spout的入口数据，直到降低到低水位以下。
Heron Instance
Heron Instance也是一个独立进程，主要用来处理用户逻辑，内部有两个线程，一个网关线程用于数据发送，发送 Stream Manager接收和发送数据，还有Metric manager用到的监控统计信息。
Metrics Manager
独立线程，收集各个Heron Instance的监控统计信息。
启动顺序和故障恢复
- 在Yarn，mesos，aurora中的多个节点上申请资源
- Topology Master启动，并由主在zookeeper上写入数据，可以被其他 Stream manager发现。
- 启动Stream Manager并且连接zookeeper监控topology master信息
- 当所有stream manager都连上Topology master之后，Toplogy master开始进行任务分配，当逻辑计划转为物理执行计划，将信息放入zookeeper
- 一旦分配结束，Stream Manager从zookeeper中获取分配信息，以帮助每Stream Manager去发现彼此。
- 一旦每个Strema Manager互相建立连接之后，启动Heron Instance进程，发现本地 stream manager, 下载自己的物理执行计划并开始执行。当所有的Heron instance都初始化成功之后，才开始执行。
如果Topology master故障，容器会重新启动，同时还会触发主备选举。Stream manager会重新发现它。
Stream manager故障，进程重启，重新发现Heron Instance和topology master。
Heron Instance故障，重新启动，重新发现本地stream manager。
多进程的部署方式避免了strom 中任何错误导致整个worker退出问题。
Heron在twitter上的增强
Heron tracker
访问拓扑信息，保存拓扑元数据信息，监控拓扑健康状态和拓扑的迁移。负载均衡情况
Heron UI
Storm UI的增强。
Heron Viz
用于收集和查看拓扑的metrics信息提供Dashbord。
性能对比
参见论文和Heron宣传材料。
附录
1) Twitter Heron: Stream Processing at Scale
2) http://www.infoq.com/cn/presentations/twitter-heron-streaming-at-scale