在浅析Storm的发布版本之前，先吐槽一下Storm的版本号。我是从0.8.0版本开始接触Storm的，那时候Storm还是推特的开源项目，作为一个Storm的半个老鸟，看到Storm又推出了一个新版本，当然是有些想法的。从2013年，Apache接手Storm之后版本号的发布继续延续了以前的风格。说白了就是众人期望了无数年，版本依然没有过“1”。
浅析Storm 0.10.0-beta
//顺序按照官网的要点顺序，翻译+个人见解
一、集群安全性以及多用户调度部署。
我们先把官网列的点列出：
-
Kerberos Authentication with Automatic Credential Push and Renewal
-
Pluggable Authorization and ACLs
-
Multi-Tenant Scheduling with Per-User isolation and configurable resource limits.
-
User Impersonation
-
SSL Support for Storm UI, Log Viewer, and DRPC (Distributed Remote Procedure Call)
-
Secure integration with other Hadoop Projects (such as ZooKeeper, HDFS, HBase, etc.)
-
User isolation (Storm topologies run as the user who submitted them)
在早期的Storm设计中，并没有考虑系统安全性的问题。
其实大部分开源软件的发展过程都差不多，早期的发展肯定是以功能以及性能为主，在发展到一定阶段之后，系统安全才会被加以考虑。如今，随着Storm的发展，以及当前实时业务需求的上涨，实际的集群部署也越来越多，安全性的需求也越来越高。
这次在安全性的支持方面，除了Storm的社区，雅虎、赛门铁克还有Hortonworks作出了不小的贡献。
主要改动点：
-
(1)自动更新Kerberos身份验证机制；
-
(2)可插拔的访问授权以及访问控制机制；
-
(3)支持多用户调度，并且对于不同用户可灵活配置资源；//这一点在向资源集中调度方向靠拢
-
(4)模拟多用户调度；
-
(5)UI方面的改进，支持SSL协议的日志查看器、DRPC页面监控；
-
(6)优化了与Hadoop生态的集成，主要是安全性方面，包括Zookeeper、Hbase以及HDFS等等；//随着大数据平台一体化，Storm的推广，越来越多的Hadoop生态组件会集成进去
-
(7)多用户的隔离，即每个用户中允许操作自己提交的拓扑任务；//其实这点跟在引入多用户的时候，必然是需要支持的
总结：
安全性方面，不多说，博客虫(微信ID:blogchong)感觉这个点在一般的企业来说，其实优先级是不高的；
重点是对多用户调度的支持，以及资源管理方面的优化，自从Hadoop2.0以后，资源的集中管理一直是一个热门方向，所以，Storm在这方面的优化还是值得期待的。
二、版本升级以及持续改进的优化
在过去，升级Storm往往会出现很多问题，涉及到拓扑的变更、拓扑的重新部署等等。究其因，不同版本之间的数据结构往往是有所出入的。所以，升级的过程不是一个完全向下兼容的过程。
从storm 0.10.0开始，版本的升级方面将有很大的优化，甚至是可以在不停止拓扑任务的情况下进行版本升级，整个过程也可以实现自动化。
总结：
随着Storm的实际部署节点越来越多，必然会面临版本升级的情况，所以这一点的改进是很重要的，因为其对于用户后续的持续使用是一个巨大的考验。
三、任务以及拓扑部署上的改进优化
熟悉Storm的朋友可能知道，对于拓扑任务的部署，往往有任何的拓扑改动，我们都需要进行代码的重新编译。如果部署的拓扑规模较大，这将影响很大。
在新改进的方向中，希望通过外部配置文件的形式，去定义拓扑的布局以及相关的配置。
先列上官网改进点：
-
Easily configure and deploy Storm topologies (Both Storm core and Micro-batch API) without embedding configuration in your topology code
-
Support for existing topology code
-
Define Storm Core API (Spouts/Bolts) using a flexible YAML DSL
-
YAML DSL support for most Storm components (storm-kafka, storm-hdfs, storm-hbase, etc.)
-
Convenient support for multi-lang components
-
External property substitution/filtering for easily switching between configurations/environments (similar to Maven-style ${variable.name} substitution)
主要改动点：
-
(1)优化拓扑的配置以及部署，在代码中将拓扑结构相关的东西剥离；
-
(2)依然支持现有的拓扑编码；//向下兼容
-
(3)使用灵活的YAML DSL去定义Spout以及Bolt；//说白了，还是在拓扑构建方面进行优化
-
(4)依然支持现有的一些接口，比如storm-kafka、storm-hbase、storm-hdfs；//依然是向下兼容，不多说
-
(5)多语言组件的支持；//以前虽然号称支持多语言，其实除了python以及java以外的语言，开发难度还是挺大的
-
(6)支持配置环境之间的切换，类似于Maven中${变量名}代替；
总结：
向下兼容的一些东西，咱就不多说了，这是版本升级的理所应当支持的功能；
重点在于拓扑结构的革命性改变，其实我们可以发现，Storm 0.10.0在灵活性使用方面做了很多的该进，包括了这个拓扑结构
四、提供新的分组策略：局部关键词分组
现有的Storm分组策略，在0.8版本到现在一直没有改变，如今引入了一个新的分组策略：局部关键词分组策略。
局部关键词分组与按字段分组(Grouping)一样，不同之处在于，其考虑了下游Bolt的负载情况，更好的利用了剩余资源，尽量达到了节点间的负载均衡。
总结：
从这点我们可以发现，Storm的革命性改进除了在灵活性方面，在资源调度方面也是不余余力啊。
五、优化了日志框架
调试分布式程序是一件很困难的事，通常我们会通过一个主要的信息来源去分析，那就是程序产生的日志文件。
但是这同样会产生矛盾，Storm是实时级别的架构系统，对于日志的记录层级难以掌控：多了，容易刷爆磁盘；少了，难以发现问题。
在Storm 0.10.0中，使用了log4j v2，这是一个具有更高的吞吐量以及更低的延迟的日志架构。并且更有效的利用资源，对于业务逻辑，我们可以轻松的追踪到。
同样，列上E文关键点：
-
Rolling log files with size, duration, and date-based triggers that are composable
-
Dynamic log configuration updates without dropping log messages
-
Remote log monitoring and (re)configuration via JMX
-
A Syslog/RFC-5424-compliant appender.
-
Integration with log aggregators such as syslog-ng
主要关键点：
-
(1)通过日志文件大小、时间日期组合的方式，触发日志的滚动；
-
(2)动态的修改日志配置，不会丢失日志数据；
-
(3)支持日志的远程监控，以及JMX的远程配置；
-
(4)支持RFC-5424协议；
-
(5)Syslog-ng的整合以及支持日志聚合；//未来很有可能使用syslog-ng完全替代syslog，不过需要时间验证
总结：
日志这一块的话，其实没什么多说的地方，现有日志其实也足够用了，问题不是很大，当然如果有更好的支持优化，肯定是大赞的。
六、支持Hive数据的接入
这个特性将会在0.13中引入，提供数据从Hive接入Storm的API，以及数据Hive落得的API，让数据从Storm到Hive的流程更加的合理以及方便，一旦数据在源头被提交，在Hive即可查询。
实现Storm到Hive的一体化，在微批处理以及事务处理中支持Hive。
总结：
依然是大数据平台一体化的改进，Storm与Hadoop生态的进一步“合体”。
七、Microsoft Azure Event Hubs的整合
在Azure云计算平台上支持Storm的部署执行，这个不多说。只能说Storm的影响力越来越大了，很多云平台已经主动和Storm“联姻”了。
八、对于Redis的支持
除了Hadoop生态，对于大行其道的Nosql，Storm也开始整合。跟其他组件的支持类似，提供了一些使用案例，同样是Storm大融合的趋势。
九、JDBC/RDBMS的整合集成
Storm 0.10.0支持高灵活可定制的集成，几乎兼容任何类型的JDBC。甚至允许拓扑元组数据与数据库数据在拓扑进行灵活的交互。
总结：
在Hadoop盛行之前，其实Storm的数据落地方式很单调，其中将Storm处理过后的数据存入数据库中是一种主流，所以，这一方面的优化可以说解决了很多历史遗留问题。
十、依赖冲突的优化
直接总结吧：在以往的Storm历史版本中，其实经常会出现依赖版本冲突的现象。在Storm 0.10.0中，对这方面作了优化。好吧，又是一个历史遗留问题，说明Storm在进一步规范化。
我们来梳理一下总结
在推特发布Heron后没几天，Apache就发布了Storm的0.10.0，不可谓不及时。
也难怪，Heron号称颠覆性的设计，虽然它暂时没有开源，虽然Storm已经占据了数据实时处理领域的半壁江山，但是依然危机感十足啊。
OK，还是回到正题，说说我的感想：
(1)大数据平台统一融合趋势
我在《DT时代变革的反思》一文中，曾经说到：支撑大数据得以发展的核心是数据平台。
在Hadoop大规模离线数据处理技术日渐成熟的今天，实时业务的需求逐渐在上升，这也是Storm得以快速发展的原因之一。
实时处理平台以及我们现在盛行的Hadoop生态平台，是两个不同的方向，逻辑上是分离的。
随着大数据处理的需求多样化，数据在不同平台上流通的需求很迫切。
如今，不管是现在版本Storm对Hive的支持、对redis的支持，还是以往中对HDFS、Hbase、Zookeeper的支持等，这都是Storm对于数据平台一体化做的努力。
在大数据平台方面，无论是实时处理，还是以Hadoop为代表的批量离线处理或者Nosql存储等几个方面，平台的统一融合将会是一个趋势。
(2)资源的集中管理
Storm在资源拓扑任务资源分配方面，一直以来都是一个硬伤。随着Hadoop2.0之后，Hadoop的资源统一交给Yarn管理，在分布式方面基本算是掀起了一股资源管理优化的风潮。
PS：翻译以及个人见解若有所误差，欢迎指正。
来源：博客虫投稿，原文链接。