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 HA
Storm之前的版本中，Nimbus节点存在单点失败的问题（Nimbus节点挂掉不会影响正在运行的拓扑），但是如果Nimbus节点不存在，用户不能提交新的拓扑，之前拓扑的任务也不能实现重新分配。
在Storm 1.0中，采用HA Nimbus来解决单点失败问题。在集群中运行多个Nimbus 服务实例，当Nimbus节点挂掉时，重新选举出新的Nimubs 节点，Nimbus主机可以随时加入或者离开集群。HA Nimbus通过采取分布式缓存API来实现数据的备份，保证拓扑资源的可用性。
原生流式窗口API
基于窗口的计算在流处理中非常普遍，连续的数据流可通过特定的准则（如时间）划分为离散的多批数据，针对每一批数据可以进行单独计算。一个典型例子就是计算过去一小时内最流行的Twitter主题。
窗口计算可用来实现聚合，连接，模式匹配等等。窗口可以看做一个基于内存的表，基于一定的策略（如时间），事件可以加入到表中也可以从表中删除。
之前的版本中，Storm开发者需要自己构建窗口计算逻辑，缺少一些高层的抽象，基于这个高层抽象用户在拓扑中可以以一种标准的方式定义窗口。
Storm 1.0版本中提供了原生的流式窗口API, 窗口定义主要包含两个参数： 窗口长度和窗口滑动间隔。Storm支持滑动窗口和滚动窗口两种方式，窗口大小可以基于时间长度或者事件个数。
状态管理-自动Checkpoint的有状态的Bolt
Storm 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。
原文摘自http://blog.csdn.net/wfzczangpeng/article/details/52711296