Storm 1.0.0

Storm 1.0.0版本增加了很多新的特性,可用性以及性能也得到了很大的改善,该版本是Storm发展历程上一个里程碑式的版本,主要特点如下。性能提升Storm 1.0.0版本最大的亮点就是性能提升,和之前的版本先比,Storm 1.0的速度能够提升至16倍,延迟能够降低至60%。Storm的拓扑性能和应用案例以及依赖的外部服务相关,但是对于大部分应用,相对于之前的版本,性能能够实现3倍的提升。Pacemaker-心跳服务器Pacemaker在Storm中是一个可选的后台进程,用来处理Worker心跳。当Storm的集群规模很大时,所有Worker都向Zookeeper发送心跳,由于Zookeeper上的数据是写磁盘的,而且为了实现数据的一致性,Zookeeper中Leader节点与Follow节点要进行通信,也来带来大量的网络通信开销,所以Zookeeper就容易成为一个性能瓶颈。
由于心跳数据一般是临时的,所以不需要将其持久化到硬盘上,也不需要跨节点实现数据的同步。把心跳数据存储到内存就行,Pacemaker主要完成的就是这个功能。Pacemaker提供了简单的基于内存的键/值存储,存储模式类似Zookeeper,Key通过目录的形式维护,Value就是字节数据。分布式缓存API在之前的版本中,Storm开发者一般将拓扑所需要的资源(如查询数据、机器学习模型)和拓扑打包成一个Topology Jar包。这种实现方式带来的问题就是更新困难,如果想更新拓扑所依赖的资源,就得重新打包和部署。另一个问题,如果依赖的数据很大(GB或更大),这会极大的增加拓扑的时启动时间。
Storm 1.0 版本采用分布式缓存API来实现文件(BLOBs)在多个拓扑之间的共享。分布式缓存中的文件可以通过命令行更新,无需重新部署拓扑。分布式缓存中文件大小可以是几KB, 也可以是几GB, 同时也支持ZIP和GZIP压缩格式。
Storm 1.0支持两种方式实现分布式缓存API。一种是基于Supervisor节点上的本地文件系统,另外一种基于HDFS实现。这两种实现都支持细粒度的 ACL 访问控制。Nimbus HAStorm之前的版本中,Nimbus节点存在单点失败的问题(Nimbus节点挂掉不会影响正在运行的拓扑),但是如果Nimbus节点不存在,用户不能提交新的拓扑,之前拓扑的任务也不能实现重新分配。
在Storm 1.0中,采用HA Nimbus来解决单点失败问题。在集群中运行多个Nimbus 服务实例,当Nimbus节点挂掉时,重新选举出新的Nimubs 节点,Nimbus主机可以随时加入或者离开集群。HA Nimbus通过采取分布式缓存API来实现数据的备份,保证拓扑资源的可用性。原生流式窗口API基于窗口的计算在流处理中非常普遍,连续的数据流可通过特定的准则(如时间)划分为离散的多批数据,针对每一批数据可以进行单独计算。一个典型例子就是计算过去一小时内最流行的Twitter主题。
窗口计算可用来实现聚合,连接,模式匹配等等。窗口可以看做一个基于内存的表,基于一定的策略(如时间),事件可以加入到表中也可以从表中删除。
之前的版本中,Storm开发者需要自己构建窗口计算逻辑,缺少一些高层的抽象,基于这个高层抽象用户在拓扑中可以以一种标准的方式定义窗口。
Storm 1.0版本中提供了原生的流式窗口API, 窗口定义主要包含两个参数: 窗口长度和窗口滑动间隔。Storm支持滑动窗口和滚动窗口两种方式,窗口大小可以基于时间长度或者事件个数。状态管理-自动Checkpoint的有状态的BoltStorm 1.0引入了有状态的Bolt API, 并且支持自动Checkpoint。有状态的Bolt很容易实现,只需要继承 BaseStatefulBolt 类即可,在拓扑中,有状态的Bolt和无状态的Bolt可以一起使用。Storm可以自动管理Bolt的状态,比如说自动Checkpoint,而且当发生失败时,Storm可以恢复Bolt的状态。
Storm 1.0可以通过内存和Redis来实现状态的管理,之后的版本中,会考虑增加其他的状态存储方式。自动反压机制之前的版本中,限制注入到拓扑的数据流量的方式是启用ACKing机制,并且设置topology.max.spout.pending参数。 当用例不需要实现at-least-once语义容错时,采用这种方式会极大的降低性能。
Storm 1.0引入了基于高/低水位的自动反压机制,这里的水位可通过Task的缓冲区大小来表示。当缓冲区达到高水位时,反压机制自动触发,降低Spout的数据注入速率,直到达到低水位为止。
Storm的反压机制和Spout API是独立的,所以所有已经存在的Spout都支持自动反压。资源感知调度器Storm支持可插拔的拓扑调度器,Storm 1.0提供了基于资源的调度器,该调度器考虑到了集群中的内存(堆内和堆外)和CPU资源。资源感知调度器(RAS)允许用户为拓扑组件(Spout/Bolt)指定所需的内存和CPU资源,Storm会在不同的Worker之间调度拓扑Task,最大程度上满足这些Task的资源需求。
未来,Storm社区将会扩展RAS实现,考虑网络资源开销和机架感知。动态的日志等级Storm 1.0允许用户和管理员动态的调整正在运行的拓扑的日志等级,这种调整可以通过Storm UI或者命令行实现,用户也可以配置可选的超时时间,一旦超时,这种改变会自动恢复。日志文件可以通过Storm UI或者logviewer服务查找。Tuple采样和调试在拓扑的调试过程中,许多Storm用户采取增加 Debug Bolt或者Trident 函数来记录拓扑中的数据流信息,Storm 1.0中提供了新的拓扑调试功能。
Storm UI提供了这样的一个功能,允许用户对流入到拓扑或者特定的组件中的Tuples进行比例采样,这些采样数据可以直接从Storm UI观测到,也可以存入到硬盘中。分布式的日志查找Storm UI增加的另一个功能就是分布式的日志查找,查找对象可以是特定拓扑的所有日志文件,查找结果包含所有Supervisor节点的匹配结果。动态的Worker性能分析另外一个功能提升就是动态的Worker性能分析,这个新特性允许用户通过Storm UI获取Worker的分析数据,包括:
- Heap Dumps
- JStack 输出
- JProfile 记录
这些分析数据可以直接下载,用来离线分析,通过Storm UI也可以重启Workers。

相关内容推荐