在浅析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：翻译以及个人见解若有所误差，欢迎指正。
来源：博客虫投稿，原文链接。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。