从Heron看实时计算系统差异对比

      真的有很久没有更新博客了，上一次更新还是2014年。那时候就在写云计算君临天下。感叹变化太快，自己14-15年从storm到全栈工程师，到产品经理，现在又重回大数据，不胜唏嘘。

      这两年里，许多新的开源系统发布，平均1、2年技术栈都要变一下。当然，其中最火爆的莫过于spark了。spark集批量计算，实时计算，SQL计算，图计算，机器学习与一身。以scala语言的易编程特点几乎一统大数据"计算“领域的江湖。

      不过streaming始终还是以min batch来作为最小单位进行计算，实时性上更适合分钟级的分析统计类应用。对于ms或者秒级实时的场景依然不太合适。当然目前实时计算领域还有一个flink设计上很牛逼，天然支持了状态计算，只可惜社区不够活跃，难以被大多数公司所采用。

      以上只是一个大致的概览，回到本文的主角——Heron，storm的继承者。沿用了storm的数据模型——经典spout-bolt模型。而又从架构上弥补了storm存在的缺点。

      1、资源最小单位——topology采用了进程的方式开并发，而不是以往的线程方式。利于资源隔离，debug，profilling以及troubleshooting等更加友好。但其实也有所失就是开进程开销总是要比线程要大。

      2、资源约束——topologies会严格使用自己所allocate的资源，而不会占用其他组件资源造成竞争，运行起来更加安全。当然安全的缺点就是可能会造成资源的浪费。这和虚拟机超卖是一个道理，有利有弊

      3、兼容性——完全兼容storm的代码，甚至做到不改一行代码直接编译后就能在Heron上运行

      4、背压机制——分布式系统中组件的执行速度各不相同，背压机制可以让各个组件自适应，而不至于造成堆积(具体实现还待了解)

      5、性能——吞吐量和延迟上大幅提升。看论文是采用了一些避免瓶颈的做法，例如轻依赖zk，c++写部分代码

      6、语义——最多一次，最少一次的语义。这一点相对spark来讲是劣势，和storm持平。exactly once目前看来是难点，Heron也正在实现中

      7、各种组件重新设计——Topology Master、Container、Stream Manager、Heron Instance、Metrics Manager、Heron Tracker

(1)Topology Master

      管理Topology的全生命周期，每个topology会开启一个TM，多个Container，TM会在zk中注册，TM会构建物理执行计划分配给其他组件

(2)Container

      容器，一个topology会启动多个容器。容器包含有Heron Instances，Steam Manager，Metrics Manager。容器就可以做资源格力

(3)Stream Manager

      Container中用来和其他Container网络交互的出口点

当然还有其他的一些组件：

Heron CLI、Heron Tracker、Heron UI。

这里不得不提的是Heron UI，可以显示当前的执行拓扑、执行速度、资源消耗，还可以知己看日志，总体来说是靠向生产系统的监控体系。

先mark，以后再补充！