Hadoop与Spark比较

先看这篇文章：http://www.huochai.mobi/p/d/3967708/?share_tid=86bc0ba46c64&fmid=0

直接比较Hadoop和Spark有难度，因为它们处理的许多任务都一样，但是在一些方面又并不相互重叠。

比如说，Spark没有文件管理功能，因而必须依赖Hadoop分布式文件系统(HDFS)或另外某种解决方案。

Hadoop框架的主要模块包括如下：

Hadoop Common
Hadoop分布式文件系统(HDFS)
Hadoop YARN
Hadoop MapReduce

虽然上述四个模块构成了Hadoop的核心，不过还有其他几个模块。这些模块包括：Ambari、Avro、Cassandra、Hive、 Pig、Oozie、Flume和Sqoop，它们进一步增强和扩展了Hadoop的功能。

Spark确实速度很快(最多比Hadoop MapReduce快100倍)。Spark还可以执行批量处理，然而它真正擅长的是处理流工作负载、交互式查询和机器学习。

相比MapReduce基于磁盘的批量处理引擎，Spark赖以成名之处是其数据实时处理功能。Spark与Hadoop及其模块兼容。实际上，在Hadoop的项目页面上，Spark就被列为是一个模块。

Spark有自己的页面，因为虽然它可以通过YARN(另一种资源协调者)在Hadoop集群中运行，但是它也有一种独立模式。它可以作为 Hadoop模块来运行，也可以作为独立解决方案来运行。

MapReduce和Spark的主要区别在于，MapReduce使用持久存储，而Spark使用弹性分布式数据集(RDDS)。

性能

Spark之所以如此快速，原因在于它在内存中处理一切数据。没错，它还可以使用磁盘来处理未全部装入到内存中的数据。

Spark的内存处理为来自多个来源的数据提供了近乎实时分析的功能：营销活动、机器学习、物联网传感器、日志监控、安全分析和社交媒体网站。另外，MapReduce使用批量处理，其实从来就不是为惊人的速度设计的。它的初衷是不断收集来自网站的信息，不需要这些数据具有实时性或近乎实时性。

易用性

支持Scala(原生语言)、Java、Python和Spark SQL。Spark SQL非常类似于SQL 92，所以几乎不需要经历一番学习，马上可以上手。

Spark还有一种交互模式，那样开发人员和用户都可以获得查询和其他操作的即时反馈。MapReduce没有交互模式，不过有了Hive和Pig等附加模块，采用者使用MapReduce来得容易一点。

成本

“Spark已证明在数据多达PB的情况下也轻松自如。它被用于在数量只有十分之一的机器上，对100TB数据进行排序的速度比Hadoop MapReduce快3倍。”这一成绩让Spark成为2014年Daytona GraySort基准。

兼容性

MapReduce和Spark相互兼容;MapReduce通过JDBC和ODC兼容诸多数据源、文件格式和商业智能工具，Spark具有与MapReduce同样的兼容性。

数据处理

MapReduce是一种批量处理引擎。MapReduce以顺序步骤来操作，先从集群读取数据，然后对数据执行操作，将结果写回到集群，从集群读取更新后的数据，执行下一个数据操作，将那些结果写回到结果，依次类推。Spark执行类似的操作，不过是在内存中一步执行。它从集群读取数据后，对数据执行操作，然后写回到集群。

Spark还包括自己的图形计算库GraphX。GraphX让用户可以查看与图形和集合同样的数据。用户还可以使用弹性分布式数据集(RDD)，改变和联合图形，容错部分作了讨论。

容错

至于容错，MapReduce和Spark从两个不同的方向来解决问题。MapReduce使用TaskTracker节点，它为 JobTracker节点提供了心跳(heartbeat)。如果没有心跳，那么JobTracker节点重新调度所有将执行的操作和正在进行的操作，交给另一个TaskTracker节点。这种方法在提供容错性方面很有效，可是会大大延长某些操作(即便只有一个故障)的完成时间。

Spark使用弹性分布式数据集(RDD)，它们是容错集合，里面的数据元素可执行并行操作。RDD可以引用外部存储系统中的数据集，比如共享式文件系统、HDFS、HBase，或者提供Hadoop InputFormat的任何数据源。Spark可以用Hadoop支持的任何存储源创建RDD，包括本地文件系统，或前面所列的其中一种文件系统。

RDD拥有五个主要属性：

分区列表
计算每个分片的函数
依赖其他RDD的项目列表
面向键值RDD的分区程序(比如说RDD是散列分区)，这是可选属性
计算每个分片的首选位置的列表(比如HDFS文件的数据块位置)，这是可选属性

RDD可能具有持久性，以便将数据集缓存在内存中。这样一来，以后的操作大大加快，最多达10倍。Spark的缓存具有容错性，原因在于如果RDD的任何分区丢失，就会使用原始转换，自动重新计算。

可扩展性

按照定义，MapReduce和Spark都可以使用HDFS来扩展。那么，Hadoop集群能变得多大呢?

据称雅虎有一套42000个节点组成的Hadoop集群，可以说扩展无极限。最大的已知Spark集群是8000个节点，不过随着大数据增多，预计集群规模也会随之变大，以便继续满足吞吐量方面的预期。

安全

Hadoop支持Kerberos身份验证，这管理起来有麻烦。然而，第三方厂商让企业组织能够充分利用活动目录Kerberos和LDAP用于身份验证。同样那些第三方厂商还为传输中数据和静态数据提供数据加密。

Hadoop分布式文件系统支持访问控制列表(ACL)和传统的文件权限模式。Hadoop为任务提交中的用户控制提供了服务级授权(Service Level Authorization)，这确保客户拥有正确的权限。

Spark的安全性弱一点，目前只支持通过共享密钥(密码验证)的身份验证。Spark在安全方面带来的好处是，如果你在HDFS上运行Spark，它可以使用HDFS ACL和文件级权限。此外，Spark可以在YARN上运行，因而能够使用Kerberos身份验证。

总结

Spark与MapReduce是一种相互共生的关系。Hadoop提供了Spark所没有的功能特性，比如分布式文件系统，而Spark 为需要它的那些数据集提供了实时内存处理。完美的大数据场景正是设计人员当初预想的那样：让Hadoop和Spark在同一个团队里面协同运行。

然后看这篇文章：Link

2009年加州大学伯克利分校团队开始了Apache Spark项目，旨在为分布式数据处理设计一个统一的引擎。 Spark具有类似于MapReduce的编程模型，但是使用称为“弹性分布式数据集”RDDs的数据共享抽象扩展。

Spark的通用性有几个重要的好处。

首先，应用程序更容易开发，因为它们使用统一的API。

第二，结合处理任务更有效；而先前的系统需要将数据写入存储以将其传递给另一个引擎，Spark可以在相同的数据（通常在存储器中）上运行不同的功能。

最后，Spark启用了以前系统无法实现的新应用程序（如图形上的交互式查询和流式计算机学习）。自2010年发布以来，Spark已经发展成为最活跃的开源项目或大数据处理，拥有超过1,000名贡献者。该项目已在超过1,000个组织中使用，从技术公司到银行、零售、生物技术和天文学。

Spark中的关键编程抽象是RDD，它是容错集合，可以并行处理集群中的对象。用户通过“转换”（例如map、filter和groupBy）操作来创建RDD。

lines = spark.textFile("hdfs://...")

errors = lines.filter(s => s.startsWith("ERROR"))

println("Total errors: "+errors.count())

Spark评估RDDs延迟，尝试为用户运算找到一个有效的计划。特别的是，变换返回表示计算结果的新RDD对象，但不立即计算它。当一个动作被调用时，Spark查看整个用于创建执行计划的转换的图。例如，如果一行中有多个过滤器或映射操作，Spark可以将它们融合到一个传递中，或者如果知道数据是被分区的，它可以避免通过网络为groupBy进行数据传递。因此用户可以实现程序模块化，而不会造成性能低下。

最后，RDDs为计算之间的数据共享提供了明确的支持。默认情况下，RDD是“短暂的”，因为它们每次在动作（例如count）使用时被重新计算。但是，用户还可以将所选的RDD保留在内存中或快速重用。（如果数据不适合内存，Spark还会将其溢出到磁盘。）例如，用户在HDFS中搜索大量日志数据集来进行错误调试时，可以通过调用以下函数来载入不同集群的错误信息到内存中：

errors.persist()

随后，用户可以在该内存中数据上运行不同的查询：

// Count errors mentioning MySQL

errors.filter(s => s.contains("MySQL")).count()

// Fetch back the time fields of errors that

// mention PHP, assuming time is field #3:

errors.filter(s => s.contains("PHP")).map(line => line.split('t')()).collect()

容错

除了提供数据共享和各种并行操作，RDDs还可以自动从故障中恢复。传统上，分布式计算系统通过数据复制或检查点提供了容错。 Spark使用一种称为“lineage”的新方法。每个RDD跟踪用于构建它的转换图，并对基本数据重新运行这些操作，以重建任何丢失的分区。

下图显示了我们以前的查询中的RDD，其中我们通过应用两个过滤器和一个映射来获取错误的时间字段。如果RDD的任何分区丢失（例如保存内存分区的错误的节点失败），Spark将通过在HDFS文件的相应块上的应用过滤器来重建它。对于将数据从所有节点发送到所有其他节点（例如reduceByKey）的“shuffle”操作，发送方在本地保留其输出数据，以防接收器出现错误。

基于沿袭的恢复比数据密集型工作负载中的复制效率高得多。它节省了时间，因为写入RAM要比通过网络写入数据快。恢复通常比简单地重新运行程序快得多，因为故障节点通常包含多个RDD分区，这些分区可以在其他节点上并行重建。

另外一个复杂些的例子:

Spark中逻辑回归的实现。它使用批量梯度下降，一个简单的迭代算法，重复计算数据上的梯度函数作为并行求和。 Spark可以方便地将数据加载到RAM中，并运行多个求和。因此，它运行速度比传统的MapReduce快。例如，在100GB作业中，MapReduce每次迭代需要110秒，因为每次迭代需从磁盘加载数据，而Spark在第一次加载后每次迭代只需要一秒。

与存储系统的整合

与Google的MapReduce非常相似，Spark旨在与多个外部系统一起使用持久存储。Spark最常用于集群文件系统，如HDFS和键值存储，如S3和Cassandra。它还可以作为数据目录与Apache Hive连接。 RDD通常仅在应用程序中存储临时数据，但某些应用程序（例如Spark SQL JDBC服务器）也在多个用户之间共享RDD。Spark作为存储系统无关引擎的设计，使用户可以轻松地对现有数据进行运算和连接各种数据源。

库

Spark SQL中尚未实现的一种技术是索引，尽管Spark上的其他库（如IndexedRDDs）确实使用它。

Spark Streaming(流)。 Spark Streaming使用称为“离散流”的模型实现增量流处理。为了通过Spark实现流式传输，我们将输入数据分成小批量（例如每200毫秒），我们定期与RDD中存储的状态组合以产生新结果。以这种方式运行流计算比传统的分布式流系统有几个好处。例如，由于使用沿袭，故障恢复更便宜，并且可以将流与批处理和交互式查询组合。

GraphX。 GraphX提供了类似于Pregel和GraphLab的图形计算接口，1通过为其构建的RDD选择分区函数来实现与这些系统相同的布局优化（例如顶点分区方案）。

MLlib。 MLlib，Spark的机器学习库，实现了50多种常见的分布式模型训练算法。例如，它包括决策树（PLANET），Latent Dirichlet分布和交替最小二乘矩阵分解的常见分布式算法。

Spark的库都对RDD进行操作，作为数据抽象，使得它们在应用程序中易于组合。例如，下图显示了一个程序，它使用Spark SQL读取一些历史Twitter数据，使用MLlib训练一个K-means聚类模型，然后将该模型应用于一个新的tweet流。每个库返回的数据任务（这里是历史性的tweet RDD和K-means模型）很容易传递给其他库。

性能

比较了Spark对三个简单任务（SQL查询，流字计数和交替最小二乘矩阵分解）与其他引擎的性能。虽然结果随着工作负载的不同而不同，但Spark通常与Storm，GraphLab和Impala等专用系统相当。对于流处理，虽然我们显示了Storm上分布式实现的结果，但是每个节点的吞吐量也可以与商业流引擎如Oracle CEP相媲美。

交互式查询

互动使用Spark分为三个主要类别。首先，组织通常通过商业智能工具（如Tableau）使用Spark SQL进行关系查询。例子包括eBay和百度。第二，开发人员和数据科学家可以通过shell或可视化笔记本环境以交互方式使用Spark的Scala，Python和R接口。这种交互式使用对于提出更高级的问题和设计最终导致生产应用程序的模型至关重要，并且在所有部署中都很常见。第三，一些供应商已经开发了在Spark上运行的特定领域的交互式应用程序。示例包括Tresata（反洗钱），Trifacta（数据清理）和PanTera。

使用的Spark组件

我们看到许多组件被广泛使用，Spark Core和SQL最受欢迎。 Streaming在46％的组织中使用，机器学习在54％中使用。虽然在图9中未直接示出，但大多数组织使用多个组件; 88％使用其中至少两个，60％使用至少三个（如Spark Core和两个库），27％使用至少四个组件。

部署环境

虽然第一个Spark部署通常在Hadoop环境中，在2015年7月Spark调查中，仅有40％的部署在Hadoop YARN集群管理器上。此外，52％的受访者在公共云上运行Spark。

模型能力

MapReduce在跨时间段共享数据方面效率低下，因为它依赖于复制的外部存储系统来实现此目的。

RDDs建立在Map-Reduce模拟任何分布式计算的能力之上，但更有效率。它们的主要限制是由于每个通信步骤中的同步而增加的等待时间，但是该等待时间的损失与所得相比是可以忽略的。

典型的Hadoop集群可能具有以下特性：

本地存储。每个节点具有本地存储器，大约50GB/s的带宽，以及10到20个本地磁盘，大约1GB/s到2GB/ s的磁盘带宽。

链接。每个节点具有10Gbps（1.3GB/s）链路，或者比其存储器带宽小约40x，并且比其总的磁盘带宽小2倍。

机架。节点被组织成20到40台机器的机架，每个机架的带宽为40Gbps-80Gbps，或者机架内网络性能的2-5倍。

给定这些属性，在许多应用中最重要的性能问题是在网络中放置数据和计算。幸运的是，RDD提供了控制这种放置的设施;该接口允许应用程序在输入数据附近放置计算（通过用于输入源25的“优选位置”的API），并且RDD提供对数据分区和共置（例如指定数据被给定密钥散列）的控制。

除了网络和I / O带宽，最常见的瓶颈往往是CPU时间，特别是如果数据在内存中。在这种情况下，Spark可以运行在每个节点上的专用系统中使用的相同的算法和库。例如，它使用Spark SQL中的列存储和处理，MLlib中的本机BLAS库等。正如我们之前讨论的，RDD明显增加成本的唯一区域是网络延迟。

Spark在shuffle阶段实现了一个障碍，所以reduce任务不会开始，直到所有的Map已经完成。这避免了故障恢复所需的一些复杂性。虽然删除一些这些功能将加快系统。但默认情况下，我们在Spark中会保持开启容错，以便于对应用程序进行容错处理。

结语

可扩展数据处理对于下一代计算机应用是必不可少的，但通常涉及不同的计算系统。为了简化这个任务，Spark项目为大数据应用程序引入了统一的编程模型和引擎。实践证明，这样的模型可以有效地支持当前的工作负荷，并为用户带来实质性的好处。

然后看这一篇(我觉得这几篇的水平，这一篇>第一篇>第二篇)：

http://blog.csdn.net/archleaner/article/details/50988258

目前Hadoop生态系统主要包括：

HDFS—Hadoop分布式文件系统。它是一个分布式的、面向块的、不可更新的（hdfs文件只能写一次，一旦关闭就再也不能修改了）、高度伸缩性的、可运行在集群中普通硬盘上的文件系统。此外，HDFS还是一个独立的工具，它可以独立于Hadoop生态系统中其他组件而运行(但是如果我们想要使HDFS高可用时，还需要依赖zookeeper和日志管理器，但这又是另外一码事了)。
MapReduce框架—这是一个基本的在集群中一组标准硬件上执行的分布式计算框架。我们没必要一定在HDFS张使用它—因为文件系统是可插拔的；同样的，我们也没必要一定在yarn中使用它，因为资源管理器是可插拔的：例如我们可以用Mesos来替换它。
YARN—Hadoop集群中默认的资源管理器。但是我们可以在集群中不使用yarn，而是将我们的mr(译注:map/reduce)任务运行在Mesos之上；或者仅仅在集群中运行不需要依赖yarn的hbase。
Hive—Hive是一个构建在MapReduce框架之上的类sql查询引擎，它可以将hiveQL语句转换为一系列运行在集群中的mapReduce任务。此外，hdfs也不是唯一的存储系统，也不一定非得使用MapReduce框架，比如在这里我么可以替换为Tez。
Hbase—基于HDFS的键值对存储系统，为Hadoop提供了联机事务处理(OLTP)能力。Hbase仅仅依赖HDFS和zookeeper;但是Hbase只能依赖于HDFS吗？不是的，Hbase除了可以运行在HDFS上之外，还可以运行在Tachyon(内存文件系统)、MapRFS、IBM GPFS以及其他一些框架之上。

此外你可能还会想到storm可以处理数据流，但是它完全独立于hadoop，可以独立运行；你可能还会想到运行于MapReduce之上的机器学习框架Mahout,但它在之前被社区关注的越来越少。下图为Mahout被反馈的问题(红色)和被解决的问题(绿色)趋势图：

下面我们来说说spark，它主要包含以下几个方面：
Spark Core – 用于通用分布式数据处理的引擎。它不不依赖于任何其他组件，可以运行在任何商用服务器集群上。
Spark Sql – 运行在Spark上的SQL查询语句，支持一系列SQL函数和HiveQL。但是还不是很成熟，所以不要在生产系统中使用；而HiveQL集成了需要的hive元数据和Hive相关的jar包。
Spark Streaming – 基于spark的微批处理引擎，支持各种各样数据源的导入。唯一依赖的是Spark Core引擎。
MLib – 构建在spark之上的机器学习库，支持一系列数据挖掘算法。

注：对下面这一段持保留意见：

此外我们这里还要讲到的是一个关于spark的重要误区—“spark是基于内存的技术”。它不是基于内存的技术；spark是一个管道式的执行引擎，而且在shuffle的过程中会将数据写入磁盘(比如说，如果我们想针对某个字段做聚合操作)、如果内存不够的话也一样会内存溢出(但是内存可以调整)。因此，spark之所以比MapReduce快主要是因为它是管道式处理方式而不是有些人说的“基于内存的优化”。当然，spark在内存中做了缓存来提高性能，但这不是spark真正工作快的原因。

现在，我们再来完整比对一下：

1. MapReduce可以被Spark Core替换？是的，它会随着时间的推移被替代，而且这种替代是合理的。但是spark目前还不是特别成熟能完全替代MapReduce。此外，也没有人会完全放弃MapReduce,除非所有依赖MapReduce的工具都有可替代方案。比如说，想要在pig上运行的脚本能在spark上执行还是有些工作要做的。

（注：Pig是一种数据流语言，用来快速轻松的处理巨大的数据，雅虎推出的，现在正在走下坡路。Pig可以非常方便的处理HDFS和HBase的数据，和Hive一样,Pig可以非常高效的处理其需要做的，通过直接操作Pig查询可以节省大量的劳动和时间。当你想在你的数据上做一些转换，并且不想编写MapReduce jobs就可以用Pig.）

2. Hive可以被Spark SQL替换？是的，这又是对的。但是我们需要理解的是Spark SQL对于spark本身来说还是比较年轻的，大概要年轻1.5倍。相对于比较成熟的Hive来说它只能算是玩具了吧，我将在一年半到两年之内再回头来看Spark SQL.。如果我们还记得的话，两到三年前Impala就号称要终结Hive,但是截止到目前两种技术也还是共存状态，Impala并没有终结Hive。在这里对于Spark SQL来说也是一样的。

3. Storm可以被Spark Streaming替换？ 是的，可以替换。只不过平心而论storm并不是Hadoop生态系统中的一员，因为它是完全独立的工具。他们的计算模型并不太形同，所以我不认为storm会消失，反而仍会作为一个商业产品。

4. Mahout可以被MLib替换？公平的讲，Machout已经失去了市场，而且从过去的几年来看它正在快速失去市场。对于这个工具，我们可以说这里是Spark真正可以替换Hadoop生态系统中的地方。 (注：同意！Spark的ML非常好用！要好好学！)

因此，总的来说，这篇文章的结论是：

1. 不要被大数据供应商的包装所愚弄。他们大量推进的是市场而不是最终的真理。Hadoop最开始是被设计为可扩展的框架，而且其中很多部分是可替换的：可以将HDFS替换为Tachyon（现在新的名字是Alluxio），可以将YARN替换为Mesos，可以将MapReduce替换为Tez并且在Tez之上可以运行Hive。这将会是Hadoop技术栈的可选方案或者完全替代方案？倘若我们放弃的MR（MapReduce）而使用Tez,那么它还会是Hadoop吗？

2. Spark不能为我们提供完整的技术栈。它允许我们将它的功能集成到我们的Hadoop集群中并且从中获益，而不用完全脱离我们老的集群方案。

3. Spark还不够成熟。我认为在过三到四年我们就不会再叫“Hadoop栈”而是叫它“大数据栈”或者类似的称呼。因为在大数据栈中我们有很广泛的选择可以选出不同的开源产品来组合在一起形成一个单独的技术栈使用。