大数据计算框架Hadoop, Spark和MPI

转自：https://www.cnblogs.com/reed/p/7730338.html

---

 

今天作题，其中一道是

请简要描述一下Hadoop, Spark, MPI三种计算框架的特色以及分别适用于什么样的场景。

一直想对这些大数据计算框架总结一下，只惋惜太懒，一直拖着。今天就借这个机会好好学习一下。

一张表

名称	发起者	语言	简介	特色	适用场景
Hadoop	Yahoo工程师，Apache基金会	Java	MapReduce分布式计算框架+HDFS分布式文件系统（GFS）+HBase数据存储系统(BigTable) 数据分布式存储在磁盘各个节点，计算时各个节点读取存储在本身节点的数据进行处理	高可靠（Hadoop按位存储） 高扩展（在可用的计算机集群间分配数据并完成计算任务，能够方便的扩展到数千个节点上） 高效（能在节点间动态的移动数据，保证节点的平衡）计算向存储迁移 高容错，经过数据备份应对节点失效	离线大批量数据处理； 不须要屡次迭代
Spark	UC Berkley AMP Lab，Apache基金会	Scala	基于内存计算的并行计算框架 使用内存来存储数据，RDD(弹性分布式数据集) 用户能够指定存储策略，当内存不够的时候能够放到磁盘上	轻量级快速处理（减小磁盘IO，用RDD在内存中存储数据，须要持久化时才到磁盘） 支持多种语言 支持复杂查询（SQL查询、流式查询、复杂查询） 实时流处理（Spark Streaming）	离线快速的处理，不能用于处理须要长期保存的数据; 适用于屡次迭代的计算模型（机器学习模型）
Storm	BackType团队，Twitter，Apache基金会	Java, clojure	不进行数据的收集和存储工做，直接经过网络实时的接受数据而且实时的处理数据，而后直接经过网络实时传回结果	全内存计算，实时处理大数据流	在线的实时处理，基于流
MPI			基于消息传递的并行计算框架 MPI从数据存储节点读取须要处理的数据分配给各个计算节点=>数据处理=>数据处理	数据存储和数据处理是分离的 用计算换通讯 没法应对节点失效	各类复杂应用的并行计算。支持MPMD（多程序多数据），开发复杂度高

Hadoop

Hadoop就是解决了大数据的可靠存储和处理。如今的Hadoop主要包含两个框架

• 大规模存储系统HDFS：在由普通PC组成的集群上提供高可靠的文件存储，经过将块保存成多个副本的办法来解决服务器或硬盘坏掉的问题。以低功耗、高性能的方式储存数据，而且能优化大数据的种类和读取速度。
• 计算引擎YARN：能够承载任何数量的程序框架，原始的框架是MR，经过Mapper和Reduccer的抽象提供一个编程模型，能够在一个或上百个PC组成的不可靠集群上并发的、分布式的处理大量数据集，而把并发、分布式和故障恢复等计算细节隐藏起来。

Hadoop的局限和不足

抽象层次低，须要手工编写代码来完成，使用上难以上手。
只提供两个操做，Map和Reduce，表达力欠缺。
一个Job只有Map和Reduce两个阶段（Phase），复杂的计算须要大量的Job完成，Job之间的依赖关系是由开发者本身管理的。
处理逻辑隐藏在代码细节中，没有总体逻辑
中间结果也放在HDFS文件系统中
ReduceTask须要等待全部MapTask都完成后才能够开始
时延高，只适用Batch数据处理，对于交互式数据处理，实时数据处理的支持不够
对于迭代式数据处理性能比较差

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

Spark

Apache Spark是一个新兴的大数据处理的引擎，主要特色是提供了一个集群的分布式内存抽象，以支持须要工做集的应用。

这个抽象就是RDD（Resilient Distributed Dataset），RDD就是一个不可变的带分区的记录集合，RDD也是Spark中的编程模型。Spark提供了RDD上的两类操做，转换和动做。转换是用来定义一个新的RDD，包括map, flatMap, filter, union, sample, join, groupByKey, cogroup, ReduceByKey, cros, sortByKey, mapValues等，动做是返回一个结果，包括collect, reduce, count, save, lookupKey。

在Spark中，全部RDD的转换都是是惰性求值的。RDD的转换操做会生成新的RDD，新的RDD的数据依赖于原来的RDD的数据，每一个RDD又包含多个分区。那么一段程序实际上就构造了一个由相互依赖的多个RDD组成的有向无环图（DAG）。并经过在RDD上执行动做将这个有向无环图做为一个Job提交给Spark执行。

Spark对于有向无环图Job进行调度，肯定阶段（Stage），分区（Partition），流水线（Pipeline），任务（Task）和缓存（Cache），进行优化，并在Spark集群上运行Job。RDD之间的依赖分为宽依赖（依赖多个分区）和窄依赖（只依赖一个分区），在肯定阶段时，须要根据宽依赖划分阶段。根据分区划分任务。

Spark支持故障恢复的方式也不一样，提供两种方式，Linage，经过数据的血缘关系，再执行一遍前面的处理，Checkpoint，将数据集存储到持久存储中。

Spark为迭代式数据处理提供更好的支持。每次迭代的数据能够保存在内存中，而不是写入文件。

那么Spark解决了Hadoop的哪些问题呢？

抽象层次低，须要手工编写代码来完成，使用上难以上手。
    =>基于RDD的抽象，实数据处理逻辑的代码很是简短。。
只提供两个操做，Map和Reduce，表达力欠缺。
    =>提供不少转换和动做，不少基本操做如Join，GroupBy已经在RDD转换和动做中实现。
一个Job只有Map和Reduce两个阶段（Phase），复杂的计算须要大量的Job完成，Job之间的依赖关系是由开发者本身管理的。
    =>一个Job能够包含RDD的多个转换操做，在调度时能够生成多个阶段（Stage），并且若是多个map操做的RDD的分区不变，是能够放在同一个Task中进行。
处理逻辑隐藏在代码细节中，没有总体逻辑
    =>在Scala中，经过匿名函数和高阶函数，RDD的转换支持流式API，能够提供处理逻辑的总体视图。代码不包含具体操做的实现细节，逻辑更清晰。
中间结果也放在HDFS文件系统中
    =>中间结果放在内存中，内存放不下了会写入本地磁盘，而不是HDFS。
ReduceTask须要等待全部MapTask都完成后才能够开始
    => 分区相同的转换构成流水线放在一个Task中运行，分区不一样的转换须要Shuffle，被划分到不一样的Stage中，须要等待前面的Stage完成后才能够开始。
时延高，只适用Batch数据处理，对于交互式数据处理，实时数据处理的支持不够
    =>经过将流拆成小的batch提供Discretized Stream处理流数据。
对于迭代式数据处理性能比较差
    =>经过在内存中缓存数据，提升迭代式计算的性能。