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