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. 内存的使用不够高效,storm的设计中认为所有的worker都是一样对等的,分配资源时产生浪费(比如spout多个worker实际上是可以公用的,在storm现有的设计下每个worker必须有一个自己的spout,这样比不就浪费资源了吗 )
  3. 上线新的topology时需要人工对硬件资源做隔离,下线应用时原有的节点也不再使用。直接增加了系统管理的成本
  4. storm的nimbus承担着带调度、监控、分发jar包的功能,负担比较重,没有资源隔离的功能; nimbus还是一个系统的单点
  5. storm使用zk作为worker和nimbus的心跳检测,集群规模增大,topologies数量增大后zk就是瓶颈了(zk的能力你懂得,链接的数量和拼读都是有瓶颈的,负载高时会出现一些奇葩的问题)
  6. storm没有back pressure机制,现在使用的是简单的fail-fask机制
  7. 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

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页