转载

Storm企业级应用：实战、运维和调优——1.2 Storm是什么

《Storm企业级应用：实战、运维和调优》原版授权，未经允许不得转载！

1.2 Storm是什么

本节主要通过Storm出现的背景、Storm的简介、Storm的设计思想、Storm与大数据Hadoop的比较等这几部分内容的介绍，使读者了解Storm的设计理念，从整体感观上切入，并快速掌握Storm。

1.2.1 Storm出现的背景

互联网从诞生的第一时间起，对世界的最大的改变就是让信息能够实时交互，从而大大加速了各个环节的效率。正因为大家有对信息实时响应、实时交互的需求，软件行业除了个人操作系统之外，数据库（更精确的说是关系型数据库）应该是软件行业发展最快、收益最为丰厚的产品了。记得十年前，很多银行别说实时转账，连实时查询都做不到，但是数据库和高速网络改变了这个情况。

随着互联网的更进一步发展，从Portal信息浏览型到Search信息搜索型到SNS关系交互传递型，以及电子商务、互联网旅游生活产品等将生活中的流通环节在线化。对效率的要求让大家对于实时性的要求进一步提升，而信息的交互和沟通正在从点对点向信息链甚至信息网的方向发展，这样必然带来数据在各个维度的交叉关联，数据爆炸已不可避免。因此流式处理加NoSQL产品应运而生，分别解决实时框架和数据大规模存储计算的问题。早在7、8年前诸如UC伯克利、斯坦福等大学就开始了对流式数据处理的研究，但是由于更多的关注于金融行业的业务场景或者互联网流量监控的业务场景，以及当时互联网数据场景的限制，造成了研究多是基于对传统数据库处理的流式化，对流式框架本身的研究偏少。目前这样的研究逐渐没有了声音，工业界更多的精力转向了实时数据库。

2010年Yahoo！对S4的开源，2011年Twitter对Storm的开源，改变了这个情况。以前互联网的开发人员在做一个实时应用的时候，除了要关注应用逻辑计算处理本身，还要为了数据的实时流转、交互、分布大伤脑筋。但是现在情况却大为不同，以Storm为例，开发人员可以快速的搭建一套健壮、易用的实时流处理框架，配合SQL产品或者NoSQL产品或者MapReduce计算平台，就可以低成本的做出很多以前很难想象的实时产品：比如一淘数据部的量子恒道品牌旗下的多个产品就是构建在实时流处理平台上的。

1.2.2 Storm简介

Storm是Twitter开源的分布式的、容错的实时计算系统，遵循Eclipse Public License 1.0。Storm通过简单的API使开发者可以可靠地处理无界持续的流数据，进行实时计算。Twitter Storm 是使用 Clojure（发音同 closure）语言实现的。Clojure 是 Lisp 语言的一种现代方言。类似于 Lisp，Clojure 支持一种功能性编程风格，但 Clojure 还引入了一些特性来简化多线程编程（一种对创建 Storm 很有用的特性）。Clojure 是一种基于虚拟机 (VM) 的语言，在 Java 虚拟机上运行。尽管 Storm 是使用 Clojure 语言开发的，但是仍然可以在 Storm 中使用几乎任何语言编写应用程序。所需的只是一个连接到 Storm 的架构的适配器。已存在针对 Scala、JRuby、Perl 和 PHP 的适配器，但是还有支持流式传输到 Storm 拓扑结构中的结构化查询语言适配器——可以通过标准输入、标准输出以JSON格式协议与Storm进行通信。

Storm可以方便地在一个计算机集群中编写与扩展复杂的实时计算，Storm之于实时处理，就好比Hadoop之于批处理。Storm保证每个消息都会得到处理，而且它很快——在一个小集群中，每秒可以处理数以百万计的消息。Storm的处理速度非常惊人：经测试，每个节点每秒钟可以处理100万个数据元组。

1.2.3 Storm的设计思想

在Storm中也有对于流Stream的抽象，流是一个不间断的无界的连续Tuple（Storm在建模事件流时，把流中的事件抽象为Tuple即元组)。Storm认为每个Stream都有一个Stream源，也就是原始元组的源头，所以它将这个源头抽象为Spout，Spout可能是连接Twitter API并不断发出Tweets，也可能是从某个队列中不断读取队列元素并装配为Tuple发射。

有了源头即Spout也就是有了Stream，同样的思想Twitter将流的中间状态转换抽象为Bolt，Bolt可以消费任意数量的输入流，只要将流方向导向该Bolt，同时它也可以发送新的流给其他Bolt使用，这样一来，只要打开特定的Spout（管口）再将Spout中流出的Tuple导向特定的Bolt，又Bolt对导入的流做处理后再导向其他Bolt或者目的地。

假设Spout就是一个一个的水龙头，并且每个水龙头里流出的水是不同的，想获得哪种水就拧开哪个水龙头，然后使用管道将水龙头的水导向到一个水处理器（Bolt），水处理器处理后再使用管道导向另一个处理器或者存入容器中。如图1-8和图1-9展示了Spout、Tuple和Bolt之间的关系，同时形象地描绘了它们之间的流程。

Storm企业级应用：实战、运维和调优——1.2 Storm是什么

图1-8 Spout、Bolt顺序处理数据流图

Storm企业级应用：实战、运维和调优——1.2 Storm是什么

图1-9 Bolt多输入数据流图

为了增大水处理效率，可以在同个水源处接上多个水龙头并使用多个水处理器，图1-10的设计就是这种结构。

Storm企业级应用：实战、运维和调优——1.2 Storm是什么

图1-10 多Spout、多Bolt处理流程图

对应上文的介绍，可以很容易的理解图1-10，这是一张有向无环图。Storm将这个图抽象为Topology（即拓扑），拓扑是Storm中最高层次的一个抽象概念，提交拓扑到Storm集群执行，一个拓扑就是一个流转换图。图中的每个节点是一个Spout或者Bolt，图中的边是指Bolt订阅了哪些流。

1.2.4 Storm与Hadoop的角色和组件比较

Storm集群和Hadoop集群表面上看很类似。但是Hadoop上运行的是MapReduce作业，而在Storm上运行的是拓扑Topology，这两者之间是非常不一样的。一个关键的区别是：一个MapReduce作业最终会结束，而一个Topology拓扑会永远运行（除非手动杀掉）。表1-1列出了Hadoop 与Storm的不同之处。

表1-1 HadoopStorm与Hadoop角色和组件的对比

	Hadoop	Storm
系统角色	JobTracker	Nimbus
	TaskTracker	Supervisor
	Child	Worker
应用名称	Job	Topology
组件接口	Mapper/Reducer	Spout/Bolt

如果只用一句话来描述Storm的话，可能会是这样：分布式实时计算系统。按照Storm作者的说法，Storm对于实时计算的意义类似于Hadoop对于批处理的意义。众所周知，根据Google MapReduce来实现的Hadoop为提供了Map和Reduce原语，使批处理程序变得非常地简单和优美。那么Storm则是在批处理之前，及时的把数据做了处理。

Storm 与其他大数据解决方案的不同之处在于其处理方式。Hadoop 在本质上是一个批处理系统。数据被引入HDFS并分发到各个节点进行处理。当处理完成时，结果数据返回到HDFS供始发者使用。Storm支持创建拓扑结构来转换没有终点的数据流。不同于Hadoop作业，这些转换从不停止，它们会持续处理到达的数据。

Hadoop专注于批处理。这种模型对许多情形（例如为网页建立索引）已经足够，但还存在其他一些使用模型，它们需要来自高度动态的来源的实时信息。为了解决该问题，就得借助Twitter推出的 Storm。Storm不处理静态数据，但它处理预计会连续的流数据。考虑到Twitter用户每天生成1.4亿条推文（Tweet），很容易看到此技术的巨大用途。

Storm不只是一个传统的大数据分析系统：它是复杂事件处理 (CEP) 系统的一个示例。CEP系统通常分类为计算和面向检测，其中每个系统都可通过用户定义的算法在Storm中实现。举例而言，CEP可用于识别事件洪流中有意义的事件，然后实时地处理这些事件。

Storm作者Nathan Marz提供了在Twitter中使用Storm的大量示例。一个最有趣的示例是生成趋势信息。Twitter从海量的推文中提取所浮现的趋势，并在本地和国家级别维护这些趋势信息。这意味着当一个案例开始浮现时，Twitter的趋势主题算法就会实时识别该主题。这种实时算法是使用 Storm实现的基于Twitter数据的一种连续分析。

原文 http://www.adintellig.com/storm-in-action-1-2/

正文到此结束