Storm 1.0.0 正式发布

Apache storm 社区很高兴的宣布版本 1.0.0 稳定已经发布，可以从the downloads page下载。
这个版本是 Apache storm 演变的一个重要的里程碑，包括大量的新特性，可用性和性能方面的改进，其中一些如下。

性能提升

该版本主要亮点之一就是性能较之前的版本有一个巨大的性能提升，Apache Storm 1.0 的性能较之前的版本提升 16 倍，延迟降低了 60%。很显然，拓扑基于不同的使用案例和所依赖外部服务不同，性能差别很大，但大多数情况下，用户可以期待一个 3X 的性能提升比早期版本。

Pacemaker - Heartbeat Server

Pacemaker 是一个可选的 Storm 守护线程，用于处理来自 workers 的心跳。随着 Storm 的集群规模的增大，Zookeeper 会因为来自 workers 的大量心跳写入而成为瓶颈，在 Zookeeper 尝试保持一致性的同时，会产生大量的写磁盘操作和网络传输量。

因为心跳是一个短暂的性质，他们不需要持久化到磁盘或跨节点同步，存储在内存中即可。这正是 Pacemaker 的作用，Pacemaker 的功能与简单的基于内存的键/值对存储一样，目录式键和字节数组值。

分布式缓存 API

在过去，它是常见的,开发人员需要的将资源（如查找数据，机器学习模型等）打包成一个 topology 的 jar 文件。这种方法的问题是，更新数据需要重新打包和重新部署的拓扑结构。另一个问题是，有时数据可能非常大（千兆字节或更多），其负面影响拓扑的启动时间。

Storm 1.0 版本引入了分布式缓存 API，允许文件在拓扑结构之间共享（BLOBs）。在分布式缓存中，文件可以在命令行的任何时间更新，而不需要重新部署拓扑。分布式缓存 API 允许文件从几个 kb 大小的几个 GB，也支持压缩格式，如 ZIP，GZIP。

Storm 1.0 配备了两个实现分布式缓存 API：一个主管节点的本地文件系统的支持，和一个由 Apache Hadoop HDFS 支持。同时还支持实施细粒度的访问控制，通过 ACL。

HA Nimbus

使用过 Storm 用户知道 Storm Nimbus 服务存在单点故障问题（Nimbus 节点挂掉之后，不会影响正在运行的 topology），然而，Nimbus 节点挂掉之后，不能提交新的 topology 和重新分配任务。

Storm 1.0 解决了这个问题，通过在集群中运行多个 Nimbus 实例和在 Nimbus 节点挂掉之后按照 leader 选举机制选举新的 Nimbus 节点，Nimbus 节点可以在任何时间加入和离开集群。HA Nimbus 利用分布式缓存 API 复制来保证在 Nimbus 节点宕机时 topology 资源可用 。

原生的流式窗口 API

基于窗口型的计算在流式处理中被广泛使用，在流处理中，无限的数据量基于一些标准（比如时间）被划分成有限的数据集，一个计算被施加到一个组，有一个例子是计算出热门的话题。

窗口主要被用来做聚合，拼接，模式匹配等，窗口被视为 in-memory 表，可以被用于事件的添加和删除。

在过去的版本中，Storm 依靠开发者自己开发窗口逻辑，没有一个高层次抽象推荐给开发者使用。

Apache Storm 1.0 现在包括一个本地的窗口 API。窗口可以指定以下 2 个参数，
窗口长度：窗口的长度或持续时间
滑动间隔：窗口滑动的时间间隔

Storm 支持基于时间宽度或事件计数的滑动和滚动窗口。

状态管理--带有自动检查点的有状态 bolt

Storm 1.0 引入了一个新的带有自动检查点有状态的 bolt API，有状态的 bolt 很容易实现（只要继承 BaseStatefulBolt 类即可），可以和 topology 中的无状态 bolt 结合。Storm 自动的管理 bolt 的状态和恢复在事件中失败的状态。

Storm 1.0 自带状态实现，支持 redis，未来发布的版本中将会加入额外的支持状态存储。

自动反压机制

在之前的 Storm 版本中，唯一的限制往 topology 的输入是开启 ACKing 并设置 topology.max.spout.pending。对于一些用户来说，不需要 at-least-once 的处理保证，这样的要求就会造成一个显著的性能损失。

Storm 1.0 包括一个新的基于可配置的高/低水印表示为一个任务的缓冲区大小的百分比自动反压机制。如果高水位达到，Storm 1.0 会减慢拓扑的 spouts 和当低水位时，停止节流。

Storm 的反压机制是实现独立的 Spout API，所以现有的所有 Spouts 都被支持。

资源调度

基于 Storm 可插拔的拓扑调度 API，Storm 1.0 增加了一个新的调度器实现，将内存（堆和堆）和集群中的可用的 CPU 资源考虑在内。资源感知调度器（又名“RAS 调度器”）允许用户指定的内存和 CPU 为每个拓扑组件（Spouts/Bolts），和 Storm 将调度 workers 之间的 tasks 任务以最好地满足这些要求。

在未来，Storm 社区计划扩大 RAS 实现支持网络资源和架意识等。

动态日志级别

Storm 1.0 现在允许用户和管理员可以动态地改变一个运行拓扑的日志级别设置，从 Storm 用户界面以及命令行。用户还可以指定一个可选的超时时间，这些变化将被自动恢复。由此产生的日志文件也很容易通过 Storm 的 UI 和 logviewer 服务来查找。

Tuple 采样与调试

在调试一个拓扑结构的过程中，很多用户发现需要自己加入 Storm“调试”bolts 或 trident 功能，记录有关数据流经的拓扑信息，然后在生产部署时，只能删除或禁用它们。Storm 1.0 消除了种方式。

Storm 的 UI 现在包括一个功能，允许你在从 Storm 的 UI 上取样流经一个拓扑或个别部件的一定百分比的 tuples。采样的事件可以直接在 Strom 的用户界面查看，也可以保存到磁盘。

分布式日志搜索

Storm 的用户界面的另一个改进是添加一个分布式日志搜索。这个搜索功能允许用户搜索在特定拓扑的所有日志文件，包括归档日志（以 zip 结尾的）。搜索结果将包括来自所有 Supervisor 节点的匹配结果。

动态 Worker 分析

最后，但肯定不是最不重要的，在 Storm 1.0 的可用性改进是动态的 worker 分析。这个新功能允许用户直接从 Storm 用户界面请求数据，包括：
堆转储
JStack 输出
JProfile 记录

生成的文件，然后可供下载使用各种调试工具离线分析。现在还可以在 Storm 的用户界面重启 worker。