以下内容来自: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比较快慢,这时,其实比较的不是时延,而是比较的吞吐了。