解析Apache Storm 0.10.0-beta发布：剑指Heron

问题导读

1.storm在安全性方面做了哪些改进？
2.storm任务以及拓扑部署上的改进优化了哪些内容？
3.分组策略方面做了如何的改进?
4.storm通过什么方式允许hive数据接入？
5.对于Redis的支持，你认为带来什么好处？

写在前面的话

在浅析Storm的发布版本之前，先吐槽一下Storm的版本号。

我是从0.8.0版本开始接触Storm的，那时候Storm还是推特的开源项目，作为一个Storm的半个老鸟，看到Storm又推出了一个新版本，当然是有些想法的。

从2013年，Apache接手Storm之后版本号的发布继续延续了以前的风格。说白了就是众人期望了无数年，版本依然没有过“1”。

对于这个浅析，不是单纯的翻译，夹杂了很多博客虫(微信ID:blogchong)个人的看法，当然肯定存在误差，欢迎指正以及交流。

浅析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：翻译以及个人见解若有所误差，欢迎指正。

欢迎关注博客虫，关注前沿IT技术、关注最热IT时讯、分享工作吐槽感悟！

博客虫(www.blogchong.com)。

好文章，谢谢分享！！！

分析的很全面，收藏下