性能、稳定性、反压、Exactly Once,Jstorm开源最佳实践全解析-阿里云开发者社区

开发者社区> 大数据> 正文

性能、稳定性、反压、Exactly Once,Jstorm开源最佳实践全解析

简介: 在2017年在线技术峰会——阿里开源项目最佳实践上,来自阿里巴巴中间件的技术专家卫乐分享了Jstorm开源最佳实践。他主要介绍了Jstorm的架构,从性能、稳定性、监控系统、大规模部署、反压、灰度发布&热升级、Exactly-Once、新的窗口机制等方面详细扥想了Jstorm做的优化。

2017年在线技术峰会——阿里开源项目最佳实践上,来自阿里巴巴中间件的技术专家卫乐分享了Jstorm开源最佳实践。他主要介绍了Jstorm的架构,从性能、稳定性、监控系统、大规模部署、反压、灰度发布&热升级Exactly-Once、新的窗口机制等方面详细扥想了Jstorm做的优化。以下内容根据直播视频整理而成。


关于阿里中间件,欢迎访问官网了解更多:https://www.aliyun.com/aliware


视频回顾:点击进入

Pdf下载:点击进入

 

发展历史

 0ac46ad3e78c0313cf964dbc3d87d061a8d95d35

JStorm2013年开始开发,历经了25个版本。从2014年“双十一”开始,做了管控平台,包括调度、用户自定义日志等特征。2015年的“双十一”,对调度进行了优化,并且增加了反压功能,重新设计了Topology Master。2016年,除了性能优化之外,还提供了Exactly Once,包括把社区的Sliding Window和Shade Dependency等特性都移植到JStorm,此外还提供了很多新的feature,如重构的窗口机制,灰度发布等

使用场景

Jstorm在阿里集团、蚂蚁、优酷、土豆、高德都使用非常广泛。有三种部署方式:StandaloneJStorm-on-YARNJStorm-on-docker(主推,可以一键部署,扩容缩容方便)。

Jstorm已经不是简单的实时计算了,其应用在很多场景:

  • 反欺诈:Nut/Velocity
  • 审计:阿里妈妈广告/P4P,AMG
  • 数据统计分析:Eagleeye,AE,BI
  • 监控:Tlog(阿里内部监控)Rds-monitorSQL监控),Oceanbase-monitorSQL监控), Cainiao Radar, YunOSMonitor
  • 数据同步:RDS-Log-Sync, Unify-Log
  • 实时推荐:Alipay 1315, Alipay Hyperloop, TPP
  • 应用调度:AE邮件实时分析,网销宝

架构

961320f865645c6b2370bae6132d5309380113c6 

JStorm的整体架构如上图所示。最下方是部署模式,JStorm Core是JStorm计算框架本身,其上是Raw Storm API(此接口相对底层)、Exactly Once、Extension API。其上是集团内部广泛使用的Plugin,SQL engine上是应用。最右边是管控平台Koala。

JStorm增强

性能

27de119b1e321679013aaf9f331122baa4be9cdf 

上图是去年JStorm 2.2.0和Storm 1.0.2的性能对比图。硬件是32CPU Core/128G物理机,每个Worker是6G内存。从图中可以看到在不同的Worker已经不同的并发下,JStorm至少是Storm两倍以上的性能。那么,如何进行的性能优化?

29800dd135fbbccb22688a0b20de6e0cca5e2d48 

性能优化在现代的流处理领域广泛认可的一种方式是做Batch,Batch对性能优化的影响是非常大的。Batch是将消息打包,从上游接收一些消息,处理完后进行Batch再往下发,能够节省很多资源,提高性能。在此基础上进行了路径优化,即对JStorm做了JVM层面的Profile,检测框架的hot function部分(调用比较多的部分),进行针对性优化。虽然对JStorm进行了重构Metrics体系,但是底层的Metrics Core库并没有优化,所以对Meter,Histogram等进行了优化。此外,在序列化方面,对常用的序列化都进行了调优。

稳定性

49ce873fdf4832fbdc7982a097c330d6c8ad38c6 

在稳定性方面,做了以下优化:

多集群部署方面,由于涉及到异地多机房、同城多机房等问题,所以同城方面使用了ZK做多机房的容灾,JStorm自动把这些作业调到别的机房,只要保证别的机房的Worker量可以支撑作业量就不会出现问题。跨城情况相对复杂,成本也比较高,在阿里使用多链路来解决,即在多城市部署一模一样的集群消费同一份数据,在输出上做一些灾备,输出到不同的异构数据输出中,这样任意一条链路挂掉就能实时切换。

隔离方面,standalone提供了天然的隔离性,因为Docker本身用cgroup做资源隔离,所以jstorm-on-docker的隔离也相对简单。jstorm-on-yarn是在yarn上的Container中开启cgroup来做隔离。

HA方面,JStormHA是很早的特性,非常稳定。节点自检是checkhealth,用于检查supervsior。脚本会在supervsior压力过大或者内存快满的情况下自动调整可用Worker数(降低)。

监控方面,JStorm的自定义metrics重新实现,管控平台Koala集成了监控报警。Tuple life style能够根据节点间花费的时间得知拓扑结构中比较慢的环节。

升级/降级方面,降级即JStorm的反压,升级即热部署和灰度发布。

监控系统

423cde6f9e70c528db42dcda42fa55aa57ab196a 

Jstorm的监控系统如上图所示,重新设计的监控系统的优点在于自动聚合的功能。从下往上,一个Task有多个Stream,Task往上是Component,再往上是Topology,再往上是Cluster。重新设计后的优点在于可以统计所有级别的Metrics,展现完整的历史曲线,而不是单点的数据。

自定义监控

f22cc839d871829bdc1cae2fe207a5d7728f2f21 

上图是Metrics整个分级汇总的实现。具体可见github源码中最新的metrics设计文档。

大规模部署

54bed8a9780e6ddfb8385cff83ab350bae04b720 

在没有Topology Master的情况下,所有的Task汇报心跳、发送Metrics的时候都需要写ZK,并且Storm是把Metrics直接ZK里面,这样ZK的压力更大。有了Topology Master之后,Topology MasterTask的总节点,Task汇报心跳的时候只需要向Task汇报心跳,Topology Master汇总后再发送给Nimbus或者ZK,这样会使ZK的压力缩到拓扑的量级。

反压

Storm的反压,比如bolt处理消息来不及的情况下会向ZK写一个节点进行反压,监听bolt上游的节点停止发送数据直到下游的bolt能够正常处理。这样的问题是数据可能出现骤降的过程,并且反压结束数据流下来之后容易导致新一次的反压,从而导致tps会一直抖动。

ba986366af2dab10ba6558236cefd7ff83075d2c 

Jstorm做了两级的反压,第一级和Jstorm类似,通过执行队列来监测,但是不会通过ZK来协调,而是通过Topology Master来协调。在队列中会标记high water mark和low water mark,当执行队列超过high water mark时,就认为bolt来不及处理,则向TM发一条控制消息,上游开始减慢发送速率,直到下游低于low water mark时解除反压。此外,在Netty层也做了一级反压,由于每个Worker Task都有自己的发送和接收的缓冲区,可以对缓冲区设定限额、控制大小,如果spout数据量特别大,缓冲区填满会导致下游bolt的接收缓冲区填满,造成了反压。

灰度发布&热升级

3c7275ccfc25a79a558cc0a34f9b59b275630612 

一个规模很大的拓扑,以前的升级需要先把拓扑kill掉,修改代码、重新打包、重新提交,导致应用会有短暂的时间不能使用。此外,有时候只想升级部分的Worker,不想重启整个拓扑。灰度发布和热升级是做Worker内部的重启,但是不会kil拓扑。

Exactly-Once

ece338b41500baccac5a82f0fc3f6fec97ff03e2 

Jstorm中,Exactly-Once是通过Topology Master来做协调的。Jstorm中的Exactly-Once并不像以前那样每发一条消息一次。Spout发一个Batch,会有一个Batch ID,并且立马发一个Checkpoint barrier(控制消息),TM会得知发了一条新的Batch,TM会把offset记录下来。Bolt分为两种,一种是Stateless Bolt,一种是Stateful Bolt。Stateless Bolt比较简单,就是正常处理,继续往下游Bolt发。Stateful Bolt则需要把状态存起来,把Checkpoint发送给Topology Master,直到Ending boltTM发送Checkpoint barrier。当所有的Ending bolt都做完Checkpoint后,就会将状态存在Hdfs/hbase中,再通知Spout发送下一个Batch。

5f4b63ca7ac1cb696a554bdea24a2f4a98e3c7d4 

实际上,每一个batch的处理和发送是可以并行的,只是TM本身的Checkpoint是串行的,这样就可以很好的提高性能。比如中间有一个Batch处理失败了,TM会得知,此时就会做Rollback,向Spout发送Rollback barrier,从Hdfs/hbase中找出最近完成的Checkpoint,删除历史无用的Checkpoint,Spout会从状态中重新恢复Offset,Stateless Bolt会继续处理,Stateful Bolt会把Checkpoint所对应的状态从Hdfs/hbase中拉出来恢复,再根据数据计算。

其他特性

其他的特性包括自定义调度、动态调整日志级别自定义日志(外部应用可以很方便做日志采集、基于日志的监控报警)、用户自定义metrics(根据业务日志做监控报警)、优雅shutdown(把所有的消息处理完之后再shutdown)、动态扩容、更新配置

新的窗口机制

Storm的Window有很多问题,所有的数据需要统一处理,在工业级的产品中不可行。重构的窗口机制不会在内存憋每个窗口的数据,只需要存每个窗口的处理结果。重构的窗口机制,支持Processing timeIngestion timeEvent timeWatermark (late element)Window early fire

JStorm Future

Apache Beam提供了一次编写、多个不同引擎到处运行的特性。JStorm也会适配Beam,做Apache Beam JStorm runnerJStorm SQL需要进行重构和优化。将来计划在Jstorm上封装一些算子、整合框架,使其易于开发、调试,性能更加优化。

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
大数据
使用钉钉扫一扫加入圈子
+ 订阅

大数据计算实践乐园,近距离学习前沿技术

其他文章