浅析Apache Storm 0.10.0-beta发布:剑指Heron

jopen 9年前

写在前面的话

在浅析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管理,在分布式方面基本算是掀起了一股资源管理优化的风潮。

来自博客虫(www.blogchong.com)。