大数据计算框架Hadoop, Spark和MPI
今天做题，其中一道是
请简要描述一下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处理流数据。
对于迭代式数据处理性能比较差
=>通过在内存中缓存数据，提高迭代式计算的性能。
