Distributed System: Storm 的基础介绍

以下内容来自：http://www.cnblogs.com/Jack47/p/storm_intro-1.html 与 http://www.cnblogs.com/swanspouse/p/5135679.html

Storm的官方介绍：

Storm是一个免费并开源的分布式实时计算系统。利用Storm可以很容易做到可靠地处理无限的数据流，像Hadoop批量处理大数据一样，Storm可以实时处理数据。‘

下面是Hadoop和Storm类似概念对比：

结构	Hadoop	Storm
主节点	JobTracker	Nimbus
从节点	TaskTracker	Supervisor
应用程序	Job	Topology
工作进程名称	Child	Worker
计算模型	Map / Reduce	Spout / Bolt

Storm的架构：水龙头是Spout（喷嘴）；Bolt是中间的处理节点；整一个运行的程序叫Topology；Stream里面包含了元组（Tuple）. 对于这些部件的详情，请参考：http://www.cnblogs.com/Jack47/p/storm_intro-1.html






那为什么需要Storm呢？其和Hadoop对比有什么优势？

（来源参考：https://www.zhihu.com/question/20098507）

Hadoop是基于Map/Reduce模型的，处理海量数据的离线分析工具。Hadoop无疑是大数据分析的王者，本质上是一个批量处理系统，它专注于大数据的批量处理。数据存储在Hadoop 文件系统里(HDFS)并在处理的时候分发到集群中的各个节点。当处理完成，产出的数据放回到HDFS上。注意，这个过程是随着任务终止而终止。

Storm是分布式的、实时数据流分析工具，数据是源源不断产生的，例如Twitter的Timeline。在Storm上构建的拓扑（Topology）处理的是持续不断的流式数据。不同于Hadoop的任务，这些处理过程不会终止，会持续处理到达的数据。

Hadoop处理的是静态的数据，而Storm处理的是动态的、连续的数据。

Storm有很多应用：

实时分析，在线机器学习(online machine learning)，连续计算(continuous computation)，分布式远程过程调用(RPC)、ETL等。Storm处理速度很快：每个节点每秒钟可以处理超过百万的数据组。它是可扩展(scalable)，容错(fault-tolerant)，保证你的数据会被处理（就像MapReduce的JobTracker能确保所有的工作都能完成），并且很容易搭建和操作。

以其创始人说的话，Steam产生Twitter的趋势信息。Twitter从海量推文中抽取趋势信息，这意味者一旦一个案例开始出现，Twitter的话题趋势算法就能实时的鉴别出这个话题。这个实时的算法就是通过在Storm上连续分析Twitter数据来实现的。

两者快慢的比较（来源：https://www.zhihu.com/question/20098507）

从时延的角度：

storm的网络直传、内存计算，其时延必然比hadoop的通过hdfs传输低得多；当计算模型比较适合流式时，storm的流式处理，省去了批处理的收集数据的时间；因为storm是服务型的作业，也省去了作业调度的时延。所以从时延上来看，storm要快于hadoop。

说一个典型的场景，几千个日志生产方产生日志文件，需要进行一些ETL操作存入一个数据库。

假设利用hadoop，则需要先存入hdfs，按每一分钟切一个文件的粒度来算（这个粒度已经极端的细了，再小的话hdfs上会一堆小文件），hadoop开始计算时，1分钟已经过去了，然后再开始调度任务又花了一分钟，然后作业运行起来，假设机器特别多，几钞钟就算完了，然后写数据库假设也花了很少的时间，这样，从数据产生到最后可以使用已经过去了至少两分多钟。

而流式计算则是数据产生时，则有一个程序去一直监控日志的产生，产生一行就通过一个传输系统发给流式计算系统，然后流式计算系统直接处理，处理完之后直接写入数据库，每条数据从产生到写入数据库，在资源充足时可以在毫秒级别完成。

从吞吐的角度：

如果本身计算的问题就是批处理问题，那么Storm是不如Hadoop的。

跑一个大文件的wordcount，本来就是一个批处理计算的模型，你非要把它放到storm上进行流式的处理，然后又非要让等所有已有数据处理完才让storm输出结果，这时候，你再把它和hadoop比较快慢，这时，其实比较的不是时延，而是比较的吞吐了。