最近在写本科的毕业论文,题目是有关于MapReduce的并行化处理,老师给出修改意见中提到了关于分布式计算框架的的国内外研究现状,一开始并无搞懂分布式计算机框架,觉得是MapReduce。MapReduce只是一种并行编程模式,也能够是一种并行框架,并非分布式计算框架。百度得知,好比Hadoop,storm,Spark等才是分布式计算框架,随后又查看了一篇博客,写得不错,以下:java
如下是转载内容:http://blog.csdn.net/zwan0518/article/details/17751959程序员
随着互联网的发展,web2.0时期[1]的到来,人类正式进入了信息爆炸时期的。海量的信息在不少应用都会出现,好比一些社交网络应用中记录用户行为日志一般都是以GB甚至是TB为单位的。常规的单机计算模式已经不能支撑如此巨大的数据量。因此,计算必须以分布式的把巨大的计算任务分红小的单机能够承受的计算任务,在这种状况下分布式计算框架与云计算[2]出现。web
咱们的互联网从Web 1.0迈入到现在的Web 2.0时期,互联网中的信息量以指数的速度增加着。天天互联网产生的数据量都是以TB的数据量不断生长。相对于传统的关系型数据的存储和计算,这些天天产生的数据大多都是非关系性的、并且没有固定格式的数据。这就对传统的基于关系型的数据存储与计算产生了挑战[3]。算法
相对于传统的数据计算,在Web2.0时期以前,在一个机器上对数据进行计算对于机器的配置彻底是能够支撑的。相对于常见的服务器内存是100G,把全部计算数据都缓存进内存进行科学计算是能够实现的。可是在现在,对于一些应用的用户日志都是以TB为单位的,这些数据是不可能一次性的所有缓存进内存,即便能够对服务器的内存进行扩充,可是运算代价仍是很是大。在这个时候必须有必定的运算机制能够把计算任务分担到多台机器上,让每台机器都承担一部分的计算和数据存储的任务。这就下降了对单机的配置要求,可使用普通的机器进行科学计算。编程
可是对于分布计算的开发和维护中须要考虑的情形是很是复杂和多变的。在进行分布式计算过程当中对计算过程当中的控制信息的通讯,每一个任务的数据获取,对计算结果的合并和对错误计算的回滚,在分布式计算的时候都是须要保证运行正常[4]。若是这些任务所有都由开发人员负责,这对程序员的要求是很是高的。分布式计算框架的出现是为了解决这种瓶颈,经过分布式框架封装计算细节,完成分布式计算程序的开发。缓存
经过使用分布式计算框架,程序员能够很容易的享受到分布式计算的带来的高速计算的好处,并且还没必要对分布式计算过程当中各类问题和计算异常进行控制。这就让程序员的开发效率成倍的提升。服务器
本文就对当前的分布式计算框架进行了系统的回顾与总结。网络
Hadoop计算框架是出现比较早的一个分布式计算框架,它主要是基于Google提出的MapReduce的开发模式[5]下一个开源实现功能很是强大的分布式计算框架,由Java开发完成。Hadoop分布式计算框架包括两个部分,计算框架MapReduce与用来存储计算数据的存储框架HDFS(HadoopDistributed File System)。数据结构
MapReduce是一种计算架构设计,利用函数式编程思想把一个计算分红map与reduce两个计算过程。MapReduce把一个大的计算任务划分为多个小的计算任务,而后把每一个小的计算任务分配给集群的每一个计算节点,并一直跟踪每一个计算节点的进度决定是否从新执行该任务,最后收集每一个节点上的计算结果并输出。架构
MapReduce架构是基于JobTracker与TaskTracker的主从结构设计。JobTracker负责具体的任务划分和任务监视,并决定某个任务是否须要回滚;TaskTracker则是负责具体的任务执行,对每一个分配给本身的任务进行数据获取,保持与JobTracker通讯报告本身状态,输出计算结果等计算过程。
对任务输入,框架会首先经过JobTracker进行任务的切分,划分结束就发送到每一个TaskTracker进行执行Map任务,Map结束以后为了让性能更加均衡会执行洗牌Shuffle操做,最后执行Reduce操做,输出结果。具体的任务执行以下图所示:
分布式文件系统HDFS,它是一个基于分布式的对大文件进行存储的文件系统。HDFS具备高容错性[6]和对机器设备要求比较低等特色。HDFS对每一个大文件分红固定大小的数据块,均衡的存储在不一样的机器上,而后对每一个数据文件进行备份存储,保证数据不会出现丢失。
HDFS集群也是基于名称节点NameNode与数据节点DataNode展开的主从架构设计。主节点名称节点负责整个集群的数据存储信息的存储,一个集群中只有一个名称节点,而从节点数据节点负责具体的数据存储,通常会有多个在集群中。以下图所示:
Storm分布式计算框架是由Twitter提出由类Lisp语言开发推出的一个用来处理实时的大数据的基于流式计算的分布式框架。它的出如今必定程度上结局了Hadoop框架中的延迟比较大,后期程序运维复杂等特色,并且它还有Hadoop所不能支持的实时性、流式计算等特色。对一些实时性的数据分析,Storm具备很是高的效率。
Storm相比较于Hadoop,Storm拥有更多的功能组件,可是其主要功能是基于Nimbus和Supervisor两个功能组件展开,经过Zookeeper对组件进行生命周期的监视。Nimbus相似于Hadoop的JobTracker负责任务的分配与监视每一个任务的状态;Supervisor是在每一个工做机器上都部署,它负责监视这台机器并负责这台机器上工做进程启动。
相比Hadoop的执行是以任务(Job)展开,Storm任务则是以提交拓扑(Topology)的方式开始。和Hadoop任务执行不一样的是除非你手动干预中止任务流,不然该拓扑会在框架中一直循环计算。每一个拓扑会在具体的工做进程Worker上执行,Worker之间是采用了ZeroMQ[7]消息队列进行通讯,提升通讯性能。
Storm具体的任务过程经过客户端提交一个声明好的拓扑,Nimbus经过与Zookeeper交互获取适合的运行机器,而后把任务分配到具体的机器,机器上的Supervisor根据分配到的任务开始启动相应的工做进程开始执行任务。在执行过程当中,不管是Supervisor仍是每一个Worker都会与Zookeeper保持心跳联系。具体执行过程以下图所示:
Spark[8]是最近很是流行、使用Scala编写、基于RDD[9](Resilient Distributed Datasets)弹性分布式内存数据集的分布式计算框架。该框架解决了在Hadoop计算框架中,在执行迭代性质的任务效率比较低的弊端,除此以外该框架还提供了任务执行期间的任务的交互查询,增长了任务的可控性。相比Hadoop,Spark除了提供计算的方法调用以外,还提供了更多的操做。
Spark和Hadoop的通用性相比,Spark框架对一些特殊的算法必定的针对性。由于Spark会对输入数据进行缓存,因此对每次计算就没必要对数据重复加载,这对计算的加速有很是大的促进做用。对于一些须要迭代的计算,经过中间数据的缓存能够快速完成整个计算。在使用Spark指挥,对于一些迭代的工做,好比Kmeans算法,则会提升20倍左右的速度。除此以外,Spark对于缓存到内存中的数据仍是可控制的,当没有足够可以使用的内存,能够选择缓存必定百分比的数据。这就让框架有更大的自助性。
Spark的任务执行框架也是以主从模式对任务调度,其任务执行框架由主结构Master和从属结构Workers组成,具体的任务执行是以Driver的方式。用户本身开发的程序以Driver的方式链接Master,并指定数据集RDD的生成与转换,而后把RDD的操做发送到任务执行节点Workers上。Workers即执行具体任务也存储计算所需数据,当收到对于RDD的操做以后,Workers经过收到的操做定义对本地化数据进行操做生成预期结果,最后把结果返回或者存储。
对于三种分布式框架,虽然都是基于主从结构对框架展开的,可是在细节上不一样分布式计算框架的结构还有不一样的。一个好的架构设计不只会让框架后期更好维护,并且对于开发者来讲也更容易对框架的运行机理更容易掌握,能够在性能上进行优化[10]。三种分布式计算框架的架构比较以下表就所示:
表1 架构比较
Tab. 1 Architectures Comparation
框架名称 |
架构设计 |
存储 |
通讯 |
Hadoop |
JobTracker/TraskTacker |
HDFS |
RPC/HTTP |
Storm |
Nimbus/Supervisor |
实时的输入流 |
zeroMQ消息队列 |
Spark |
Master/Workers |
内存、磁盘 |
共享、广播变量 |
三种分布式框架在不一样的领域行业都在大规模的使用,不一样的框架会有本身最适用的计算场景[11],三种计算框架的性能上的比较以下表所示:
表2 性能比较
Tab. 2 Performance Comparation
框架名称 |
优点 |
弊端 |
使用场合 |
Hadoop |
Java编写性能高 |
时延高; 处理流程固定 |
批处理; 对延迟不敏感; 离线的数据处理 |
Storm |
实时接收数据流; 更高的容错能力; 开发简单; |
依赖其余组件较多; 内存控制很差; 多语言支持补好 |
实时性; 流数据处理; 分布式RPC计算 |
Spark |
算法实现简单; 数据缓冲内存; 计算方法更通用; 任务执行时能够交互 |
须要较大内存; 增量更新效率差 |
批处理; 迭代性质的任务; 大部分大数据处理任务 |
除了这几个经常使用的框架以外,还有不少分布式计算框架在各个领域中发挥着很大的做用。在Hadoop框架出现的时候,微软公司推出了分布式计算框架Dryad[12]与DryadLINQ[13]。和Storm相似的基于实时数据流进行处理的分布式计算框架也有不少,好比Yahoo公司推出的S4计算框架与伯克利大学D-Streams[14]计算框架,Hadoop也提出了基于数据流的实现是HStreaming的概念。
文献[15]给出了在将来的云计算框架的一些发展前景,文献[16]给出了分布式计算框架对当今的项目维护的影响并预测将来分布式计算框架对软件维护的预测,文献[17]对当前的云计算进展给出了总结与将来云计算的进一步的发展方向。在将来的框架发展中,数据量确定会比如今的量级更加庞大[18],对计算框架的可扩展性有较大的考验,要求计算的时间消耗有必定的限制;数据的复杂性会更加难以控制[19],对框架的架构[20]和计算模式会提出更高的要求。针对一些特殊的应用场景,不一样的分布式框架也须要对相应的不一样应用展开优化和升级[21]。
在将来的发展中,结合当今研究方向,分布式框架的发展方向会在如下几种展开:
1) 分布式计算框架会在架构上进行更近一步的优化,在架构上更加清晰,Hadoop在第二代推出分布式计算框架YARN则是对Hadoop的架构进行优化。经过良好的架构设计让框架更加容易维护,计算过程更加清晰。
2) 在将来的分布式计算架构中,计算模式也会更加优化,从当今分布式计算框架能够看出从批量计算的Hadoop到流式计算Storm而后到函数式编程的Spark。经过一个良好的计算模式,让开发框架上的应用程序更加容易、便利。
3) 分布式计算框架的基础架构也会必定程度上展开研究,用来支撑上层的分布式计算过框架。在大数据计算中,分布在不一样机器上的数据的传输花费较大的代价,因此基础架构的发展也会促进分布式计算框架性能上的提高。
本文对当前互联网中现有的比较流行的分布式计算框架进行了系统的回顾,详细对不一样计算框架的架构和计算过程和进行了详细的介绍。而后又对不一样的分布式计算框架从计算数据的存储到计算过程当中的数据通讯进行了详细的对比,又从性能上对不一样框架的展开比较,得出不一样框架的优缺点,并给出不一样的计算框架在不一样的适用场合。最后本文展望了分布式计算框架在将来的发展方向。