深度理会 Twitter Heron 大数据及时说明体系

2015年6月1号， Twitter 对外宣讲了他们的Heron体系， 从ppt和论文中，看起来完爆storm。昨天，抽闲把论文，细心读了一遍， 把小我私人条记和心得分享一下：

择要：

Heron更得当超大局限的呆板， 高出1000台呆板以上的集群。 在不变性上有更优秀的示意， 在机能上，示意一样平常乃至稍弱一些，在资源行使上，可以和其他编程框架共享集群资源，但topology级别会更挥霍一些资源。

而从应用的角度，应用更方向于大应用，小应用的话，会多一点点资源挥霍， 对付大应用，debug-ability的重要性逐渐晋升。 其它对付task的计划， task会走向更重更伟大， 而JStorm的task是向更小更轻量去走。

将来JStorm可以把自动降级计策引入， 通过实现阿里妈妈的ASM， debug-ability应该远高出storm， 不会逊色于Heron， 乃至更强。

?近况：

全部的老的出产情形的topology已经运行在Heron上， 天天或许处理赏罚几十T的数据， billions of动静

为什么要从头计划Heron：

【题外话】这里完全引用作者吐槽的题目， 不少题目，着实JStorm已包办理

（1）debug-ability 很差， 呈现题目，很难发明

1.1 多个task运行在一个体系历程中， 很难定位题目。必要一个清楚的逻辑计较单位到物理计较单位的相关

（2）必要一种更高级的资源池打点体系

2.1 可以和其他编程框架共享资源， 说白了，就是相同yarn/mesos， 而在Twitter就是Aurora 2.2 更简朴的弹性扩容和缩容 集群 2.3 由于差异task，对资源需求是纷歧样的， 而storm会公正看待每个worker， 因此会存在worker挥霍内存题目。当worker内存出格大时， 举办jstack或heap dump时，出格轻易引起gc，导致被supervisor干掉 2.4 常常为了停止机能妨碍，经常举办超量资源分派， 本来100个core，分派了200个

（3）以为Storm计划不公道的处所

3.1 一个executor 存在2个线程， 一个执行线程， 一个发送线程， 而且一个executor运行多个task， task的调治完全依靠来历的tuple， 很不利便确认哪个task出了题目。 3.2 由于多种task运行在一个worker中， 无法明晰出每种task行使的资源， 也很难定位出题目的task，当呈现机能题目或其他举动时， 常用就是重启topology， 重启后就好了，由于task举办了从头调治 3.3 日记打到统一个文件中，也很难查找题目，尤其是当某个task猖獗的打印日记时 3.4 当一个task挂掉了，直接会干掉worker，并强制其他运行好的task被kill掉 3.5 最大的题目是，当topology某个部门呈现题目时， 会影响到topology其他的环节 3.6 gc引起了大量的题目 3.7 一条动静至少颠末4个线程， 4个行列， 这会触发线程切换和行列竞争题目 3.8 nimbus成果太多， 调治/监控/分发jar/metric report， 常常会成为体系的bottleneck 3.9 storm的worker没有做到资源保存和资源断绝， 因此存在一个worker会影响到其它的worker。 而现有的isolation调治会带来资源挥霍题目。 Storm on Yarn也没有完全办理这个题目。 3.10 zookeeper成为体系的瓶颈， 当集群局限增大时。 有些体系为了低落zk心态，新增了tracker，但tracker增进了体系运维难度。 3.11 nimbus是体系单点 3.12 缺乏反压机制 3.12.1 当receiver忙不外来时， sender就直接扔弃掉tuple， 3.12.2 假如关掉acker机制， 那无法量化drop掉的tuple 3.12.3 由于上游worker执行的计较就被扔弃掉。 3.12.4. 体系会变的难以猜测(less predictable.) 3.13 经常呈现机能题目， 导致tuple fail， tuple replay， 执行变慢 3.13.1 不良的replay， 恣意一个tuple失败了，城市导致整个tuple tree fail， 不良的计划时（好比不重要的tuple失败），会导致tuple等闲被重发 3.13.2 当内存很大时，长时刻的gc，导致处理赏罚延时，乃至被误杀 3.13.3 行列竞争

Heron计划原则：

（1）兼容老的storm api

（2）实现2种计策， At most once/At least once

架构：

调治器

Aurora是一个基于mesos的通用service scheduler， Hero基于Aurora 实现了一套Topology Scheduler， 而且这个调治器已经提供了必然的抽象，可以移植到yarn/mesos/ec2（我的领略应该稍加修改就可以运行在其他通用型调治器上） 2/ 第一个container 运行 Topology Manager（TM）， 其他的container 内部会运行一个Stream manager/Metrics Manager 和多个Heron Instance。 这里一个container雷统一个docker感念，暗示一个资源荟萃，是Aurora的调治单位， 多个container可以运行在一台呆板上， 分派几多container由Aurora按照现有资源环境举办分派， 其它一个container配置了cgroup

Topology Manager

1. tm陪伴整个topology生命周期， 提供topology状态的独一contact （相同yarn的app master） 2. 可以一主多备， 各人抢占zk 节点， 谁胜出，谁为master， 其他为standby

Stream manager（SM）

最大的改变就是源自Stream manager， Stream manager就相等于一个container的tuple的总线（hub）。 全部的Hero Instance（HI）都毗连SM举办send/receive 假如container内部一个HI 发送数据到其它一个HI，走的是当地快速通道。

Backpressure 反压机制

当下流处理赏罚速率变慢后，通过反压机制，可以关照上游举办减速， 停止数据因buffer被塞满而丢失，并因此带来资源挥霍。

TCP 反压：

当一个HI 处理赏罚慢了后，则该HI的吸取buffer会被填满， 紧接着当地SM的sending buffer被填满， ? 然后会撒播到其他的SM和上游HI。 这个机制很轻易实现，但在现实行使中，存在许多题目。由于多个HI 共用SM， 不只将上游的HI 降速了，也把下流的HI 降速。从而整个topology速率全手下架，而且长时刻的降级。

Spout 反压。

这个机制是团结TCP 反压机制， 一旦SM 发明一个或多个HI 速率变慢，立即对当地spout举办降级， 遏制从这些spout读取数据。而且受影响的SM 会发送一个非凡的start backpressure message 给其他的sm，要求他们对spout举办当地降级。一旦出题目的HI 规复速率后，当地的SM 会发送 stop backpressure message 扫除降级。

Stage-by-Stage 反压

这个相同spout反压，可是一级一级向上反压。 Heron最后回收的是spout反压， 由于实现较量简朴，并且降级相应很是敏捷。 而且可以很快定位到谁人HI 处理赏罚速率慢了。 每个socket channel都绑定了一个buffer， 当buffer 的 queue size高出警戒水位时，触发反压，镌汰时，打仗反压。 这种机制，不会扬弃tuple，除了呆板宕机。 topology可以配置打开或封锁。

Heron Instance

（1） 一个task 一个历程， （2） 全部的历程之间通讯都是行使protocol buffer （3） 一个gateway线程， 一个执行线程。 gateway线程认真和外围通讯， sm/mm。 执行线程和现有storm的执行线程很是相同。执行线程会网络全部的metrics，然后发送给gateway线程。 （4）这个data-in/data-out行列会限制巨细， 当data-in 行列满了的时辰， gateway线程遏制从local SM 读取数据。同理假如data-out行列满，gateway会以为local SM不想接管更多的数据。 执行线程就不再emit或执行更多的tuple。 （5）data-in/data-out行列巨细不是牢靠， 假如是固按时， 当收集波动时，会导致内存中大量数据会萃无法发送出去，并触发GC,并导致进一步的降级。因此是动态调解， 按期调解行列巨细。 假如行列的capacity高出阀值时， 对其举办减半。这个操纵一连举办指导行列的capacity维持在一个不变的水位或0。这种方法有利停止GC的影响。 当行列的capcity小于某个阀值时， 会迟钝增添到设置巨细或最大capacity值。

Metrics manager（mm）

网络全部的metrics，包罗体系的和用户的metrics， 也包括SM的。 mm会发送metrics 给monitor体系(相同ganglia体系)，同样也会给TM.

流程：

（1）提交使命， Aurora分派须要的资源和在一些呆板上调治container （2）TM 在一个container上运行起来，并注册到ZK （3）每个container的SM 查询ZK 找到TM， 向TM 发送心跳。 （4）当全部的SM 连上TM后， TM 执行分派算法， 差异的compoent到差异的container。 这个阶段叫物理执行打算（相同SQL理会和执行进程）。并将执行打算放到ZK。 （5）SM 下载执行打算，并开始彼此之间举办毗连， 与此同时， 启动HI,hi开始发明container，下载他们的执行打算，并开始执行 （6）整个topology完成初始化，开始正式的发送和吸取数据。

三种failure case

1. 历程挂了 1.1 假如TM 挂了， container会重启TM， TM 会从ZK 上从头下载执行打算。假若有一主多备，则备机遇被promotion。 全部SM 会切到新的TM 1.2 假如SM 挂了， container仍旧会重启TM,并从ZK 下载执行打算， 并搜查是否有变革。其他的SM 会连到新的SM 1.3 假如HI 挂了， 重启并下载执行打算，并从头执行。

外围体系

外围体系就先容一下Heron Tracker

Heron Tracker

认真网络topology的信息， 雷统一个gateway的脚色。 通过watch zk，发明新的TM， 并获取topology的一些原数据。是一种Aurora service， 提供load balance在多个instance之间。 可以提供REST API。可以获取 （1） 逻辑和物理执行打算 （2） 各类metrics， 体系的和用户的 （3）日记link

Heron UI/VIZ

UI 提供传统的UI 方法。 VIZ 提供全新的UI， 可以看到更多的metrics， 曲线和康健搜查。比UI 炫酷许多。

机能陈诉和测试进程：

相识整个体系架构和事变流程后， 后头的机能测试陈诉， 没有看了， 也差不多有个观念了。

小我私人思索和总结：

（1） 相对付JStorm， Heron把脚色剥离的更清楚明白。

（1.1）调治器

scheduler 认真container的调治，这个调治很是的纯粹，可以直接复用yarn/mesos/， 现有的TM 着实就是nimbus，独逐一点变革就是这个TM 只认真本身topology的信息， 不是认真全部topology。这个TM 就相等于yarn下的app master， 很是得当今朝主流的调治体系。 当集群局限很是大的时辰， 而且每个应用都较量大的时辰， 这个架构会非停止nimbus成为瓶颈。 不外storm-on-yarn模式下， 也许通过一个nimbus打点一个小的逻辑集群，也可以办理这个题目， 而且当topology 较量小的时辰， 可以通过各人公用一个nimbus，节减一些资源。

（1.2） container

这里出格要把container拿出来细心说一下， 这个container是Auron的一个资源单位。假如将Auron相同JStorm的worker， 你就会发明脚色和架构是何等的相同。 （1.2.1） container和jstorm的worker都可以配置cgroup，到达必然的资源断绝 （1.2.2）container内部的SM/MM 着实就相同jstorm worker内部drainer/dispatcher/metricsreport线程。 但container 相对jstorm 的worker 尚有一些其他的优弱点： 利益： （1.2.3）这个粒度可以节制的更自由， 这个container 可以节制cpu 到更多的核，更多的内存上限。 但jstorm的worker 根基上最多10个核， 并且当内存太大，在core dump和gc的时辰压力会较量大。 （1.2.4）container还带必然的supervisor的成果，当container内部任何历程挂了， container城市认真把它重启， 因此整个体系的心态逻辑会很是的简朴。 ?Auron <–> container,? ?Container <– > tm/sm/mm/hi. ?整个体系的心跳压力模子会更简朴， 心跳压力（对ZK）也更小

机能：

ppt和文档内里说机能有15倍以上的晋升， 这个在某些配置下是可以到达这种结果， 但凡是环境机能应该比JStorm还要差一点点。 怎样到达这种结果呢， （1）条件前提是， grouping方法不是选择localOrShuffle可能localFirst ?就是把container配置的尽也许的大， 最好是独有一台呆板。这样SM和SM 之间的通讯就会大幅镌汰， 而一个container内部的HI 通讯走内部通道。因此会有更多的HI走内部通道。而jstorm/storm， worker较量多的时辰， worker和worker之间会建设netty connection， 更多的netty connection会带来更多的内存耗损和线程切换。 尤其是worker数高出200个以上时。 但为什么说凡是环境下，机能应该还要比JStorm差一点点呢。 由于在出产情形， container 是不行能占据这么多资源， 不然Auron的调治太粗粒度，一台呆板只跑一个大container， 会导致更严峻的资源挥霍。正常环境下， 一个container绑定2 ～ 4个核， 这个时辰，和一个平凡的jstorm worker没有什么区别， 但jstorm worker内部task之间数据传输的服从会远远高于Heron， 由于Heron的HI 之间纵然是走历程间通讯方法,也逃走不了序列化和反序化的举措， 这个举措必定会耗时， 更不消说IPC 之间的通讯服从和历程内的通讯服从。

资源操作率：

Heron 可以很是精准的节制资源行使环境， 可以或许担保， 申请几多资源，就会用几多资源。 在大集群这个级别会节减资源，在topology级别挥霍资源。 假如JStorm-on-yarn这种体系下， 由于每个逻辑集群会超量申请一些资源， 因此资源也许会多有少量挥霍。无法做到像Heron一样精准。 假如改革nimbus成为topology level 相同TM（腾讯在jstorm基本上实现了这个成果）， 这个题目就可以很好的办理。在平凡standalone的JStorm模式下， jstorm不会挥霍资源， 但由于Standalone，导致这些呆板不能被其他编程框架行使， 因此也可以说挥霍必然的资源。 但这种环境就是 资源断绝性– 资源操作率的一种均衡， 此刻这种按照线上运行环境，挥霍水平可以接管。 在topology这个粒度举办较量时， Heron应该会耗损掉更多的资源。 最大的题目在于， Heron中一个task就是一个process， 论文中没有描叙这个process的民众线程， 可以必定的是， 这个process好比尚有大量的民众线程， 好比ZK-client/network-thread/container-heartbeat-thread， 一个task一个process，这种计划，相对付一个worker跑更多的task而言，必定挥霍了更多的CPU 和内存。 至于吐槽在Storm和JStorm，超量申请资源题目， 好比一个topology只要100 个cpu core能完成， 申请了600个core， 这个题目，在jstorm中是绝对不存在的， jstorm的cgroup配置是share + limit方法， 也就是上限是600 core，但topology假如用不到600个core， 此外topology可以抢占到cpu core。 在内存方面， jstorm的worker 内存申请量，是凭证worker最大内存申请， 但当代操纵体系早就做到了， 给你一个上限， 当你用不了这么多的时辰， 其他历程可以抢占。

在不变性和debug-ability这点上：

Heron 上风很是大， 首要就是通过2点: (1) 自动降级计策， 也就是论文说的backpressure， 这个对付大型应用长短常有用的， 也很明显进步不变性。 （2） 一个task一个process， 这个团结降级计策，可以很是快速定位到堕落的task， 其它由于一个task 一个process， task之间的影响会很是快， 其它也停止了一个历程行使过大的内存，从而触发严峻的GC 题目。

最后总结：

Heron更得当超大局限的呆板， 高出1000台呆板以上的集群。 在不变性上有更优秀的示意， 在机能上，示意一样平常乃至稍弱一些，在资源行使上，可以和其他编程框架共享资源，但topology级别会更挥霍一些资源。 其它应用更方向于大应用，小应用的话，会多一点点资源挥霍， 对付大应用，debug-ability的重要性逐渐晋升。 其它对付task的计划， task会走向更重更伟大， 而JStorm的task是向更小更轻量去走。 将来JStorm可以把自动降级计策引入， 通过实现阿里妈妈的ASM， debug-ability应该远高出storm， 不会逊色于Heron， 乃至更强。

其他流式编程框架

1.S4 Distributed Stream Computing Platform.?http://incubator.apache.org/s4/ 2. Spark Streaming. https://spark.apache.org/streaming/? 3. Apache Samza. http://samza.incubator.apache.org 4. Tyler Akidau,Alex Balikov,Kaya Bekiroglu,Slava Chernyak,Josh?Haberman,Reuven Lax,Sam McVeety,Daniel Mills,Paul?Nordstrom,Sam Whittle: MillWheel: Fault-Tolerant Stream?Processing at Internet Scale.? PVLDB 6(11): 1033-1044 (2013) 5.?Mohamed H. Ali,Badrish Chandramouli,Jonathan Goldstein,Roman Schindlauer: The Extensibility Framework in Microsoft?StreamInsight.? ICDE?2011: 1242-1253 6. Rajagopal Ananthanarayanan,Venkatesh Basker,Sumit Das,Ashish?Gupta,Haifeng Jiang,Tianhao Qiu,Alexey Reznichenko,Deomid?Ryabkov,Manpreet Singh,Shivakumar Venkataraman: Photon:?Fault-tolerant and Scalable Joining of Continuous Data Streams.? SIGMOD?2013: 577-588 7. DataTorrent.? https://www.datatorrent.com 8. Simon Loesing,Martin Hentschel,Tim Kraska,Donald Kossmann:?Stormy: An Elastic and Highly Available Streaming Service in the?Cloud. EDBT/ICDT Workshops 2012: 55-60