hadoop与spark的异同

解决问题的层面不一样
首先，Hadoop和Apache Spark两者都是大数据框架，但是各自存在的目的不尽相同。Hadoop实质上更多是一个分布式数据基础设施: 它将巨大的数据集分派到一个由普通计算机组成的集群中的多个节点进行存储，意味着您不需要购买和维护昂贵的服务器硬件。
同时，Hadoop还会索引和跟踪这些数据，让大数据处理和分析效率达到前所未有的高度。Spark，则是那么一个专门用来对那些分布式存储的大数据进行处理的工具，它并不会进行分布式数据的存储。
两者可合可分
Hadoop除了提供为大家所共识的HDFS分布式数据存储功能之外，还提供了叫做MapReduce的数据处理功能。所以这里我们完全可以抛开Spark，使用Hadoop自身的MapReduce来完成数据的处理。
相反，Spark也不是非要依附在Hadoop身上才能生存。但如上所述，毕竟它没有提供文件管理系统，所以，它必须和其他的分布式文件系统进行集成才能运作。这里我们可以选择Hadoop的HDFS,也可以选择其他的基于云的数据系统平台。但Spark默认来说还是被用在Hadoop上面的，毕竟，大家都认为它们的结合是最好的。
以下是从网上摘录的对MapReduce的最简洁明了的解析:
  我们要数图书馆中的所有书。你数1号书架，我数2号书架。这就是“Map”。我们人越多，数书就更快。
现在我们到一起，把所有人的统计数加在一起。这就是“Reduce”。
Spark数据处理速度秒杀MapReduce
Spark因为其处理数据的方式不一样，会比MapReduce快上很多。MapReduce是分步对数据进行处理的: ”从集群中读取数据，进行一次处理，将结果写到集群，从集群中读取更新后的数据，进行下一次的处理，将结果写到集群，等等…“ Booz Allen Hamilton的数据科学家Kirk Borne如此解析。
反观Spark，它会在内存中以接近“实时”的时间完成所有的数据分析：“从集群中读取数据，完成所有必须的分析处理，将结果写回集群，完成，” Born说道。Spark的批处理速度比MapReduce快近10倍，内存中的数据分析速度则快近100倍。
如果需要处理的数据和结果需求大部分情况下是静态的，且你也有耐心等待批处理的完成的话，MapReduce的处理方式也是完全可以接受的。
但如果你需要对流数据进行分析，比如那些来自于工厂的传感器收集回来的数据，又或者说你的应用是需要多重数据处理的，那么你也许更应该使用Spark进行处理。
大部分机器学习算法都是需要多重数据处理的。此外，通常会用到Spark的应用场景有以下方面：实时的市场活动，在线产品推荐，网络安全分析，机器日记监控等。
灾难恢复
两者的灾难恢复方式迥异，但是都很不错。因为Hadoop将每次处理后的数据都写入到磁盘上，所以其天生就能很有弹性的对系统错误进行处理。
Spark的数据对象存储在分布于数据集群中的叫做弹性分布式数据集(RDD: Resilient Distributed Dataset)中。“这些数据对象既可以放在内存，也可以放在磁盘，所以RDD同样也可以提供完成的灾难恢复功能，”Borne指出。


对Hadoop与Spark孰优孰劣这个问题，最准确的观点就是，设计人员旨在让Hadoop和Spark在同一个团队里面协同运行。
直接比较Hadoop和Spark有难度，因为它们处理的许多任务都一样，但是在一些方面又并不相互重叠。
比如说，Spark没有文件管理功能，因而必须依赖Hadoop分布式文件系统(HDFS)或另外某种解决方案。将Hadoop MapReduce与Spark作一番比较来得更明智，因为它们作为数据处理引擎更具有可比性。
过去几年，随着数据科学趋于成熟，也日益需要用一种不同的方法来处理大数据。Hadoop在一些业务应用领域的表现比后起之秀Spark更胜一筹， 不过Spark在大数据领域有其一席之地，这归功于它具有速度快、易于使用的优点。本文剖析了两大平台的一系列常见属性，包括性能、容错、成本、易用性、 数据处理、兼容性和安全性。
Hadoop和Spark方面要记住的最重要一点就是，它们并不是非此即彼的关系，因为它们不是相互排斥，也不是说一方是另一方的简易替代者。两者彼此兼容，这使得这对组合成为一种功能极其强大的解决方案，适合诸多大数据应用场合。
Hadoop的定义
Hadoop是Apache.org的一个项目，其实是一种软件库和框架，以便使用简单的编程模型，跨计算器集群对庞大数据集(大数据)进行分布式 处理。Hadoop可灵活扩展，从单一计算机系统，到提供本地存储和计算能力的数千个商用系统，它都能轻松支持。实际上，Hadoop就是大数据分析领域 的重量级大数据平台。
Hadoop由协同运行、构建Hadoop框架的多个模块组成。Hadoop框架的主要模块包括如下：
Hadoop Common Hadoop分布式文件系统(HDFS) Hadoop YARN Hadoop MapReduce
虽然上述四个模块构成了Hadoop的核心，不过还有其他几个模块。这些模块包括：Ambari、Avro、Cassandra、Hive、 Pig、Oozie、Flume和Sqoop，它们进一步增强和扩展了Hadoop的功能，得以扩大到大数据应用领域，处理庞大数据集。
许多使用大数据集和分析工具的公司使用Hadoop。它已成为大数据应用系统中事实上的标准。设计Hadoop的初衷是处理这项任务：搜寻和搜索数 十亿个网页，将这些信息收集到数据库中。正是由于渴望搜寻和搜索互联网，才有了Hadoop的HDFS及分布式处理引擎MapReduce。
如果数据集变得极其庞大或极其复杂，以至于当前的解决方案无法在数据用户认为合理的时间段内有效地处理信息，Hadoop对公司就会大有用处。
MapReduce是一种出色的文本处理引擎，它理应如此，因为搜寻互联网和搜索互联网(它的首要任务)都是基于文本的任务。
Spark的定义
Apache Spark开发人员声称它是“一种用于数据大规模处理的快速通用引擎”。相比之下，如果说Hadoop的大数据框架好比是800磅重的大猩猩，Spark就好比是130磅重的猎豹。
虽然批评Spark的内存处理技术的人士承认，Spark确实速度很快(最多比Hadoop MapReduce快100倍)，但他们可能并不愿意承认它在磁盘上运行起来速度最多快10倍。Spark还可以执行批量处理，然而它真正擅长的是处理流工作负载、交互式查询和基于机器的学习。
相比MapReduce基于磁盘的批量处理引擎，Spark赖以成名之处是其数据实时处理功能。Spark与Hadoop及其模块兼容。实际上，在Hadoop的项目页面上，Spark就被列为是一个模块。
Spark有自己的页面，因为虽然它可以通过YARN(另一种资源协调者)在Hadoop集群中运行，但是它也有一种独立模式。它可以作为 Hadoop模块来运行，也可以作为独立解决方案来运行;这样一来，很难直接比较两者。然而随着时间的推移，一些大数据科学家预计Spark会出现分叉，可能会取代Hadoop，尤其是在更快速地访问处理的数据至关重要的情况下。
Spark是一种集群计算框架，这意味着它更多地与MapReduce竞争，而不是与整个Hadoop生态系统竞争。比如说，Spark没有自己的分布式文件系统，但可以使用HDFS。
Spark使用内存，也可以使用磁盘进行处理，而MapReduce完全基于磁盘。MapReduce和Spark的主要区别在于，MapReduce使用持久存储，而Spark使用弹性分布式数据集(RDDS)，下面容错部分有更详细的解释。
性能
网上不缺关于Spark与MapReduce相比有多快的信息。对两者进行比较有个问题，那就是它们处理数据的方式不一样，数据处理部分有介绍。Spark之所以如此快速，原因在于它在内存中处理一切数据。没错，它还可以使用磁盘来处理未全部装入到内存中的数据。
Spark的内存处理为来自多个来源的数据提供了近乎实时分析的功能：营销活动、机器学习、物联网传感器、日志监控、安全分析和社交媒体网站。另 外，MapReduce使用批量处理，其实从来就不是为惊人的速度设计的。它的初衷是不断收集来自网站的信息，不需要这些数据具有实时性或近乎实时性。
易用性
众所周知，Spark以性能见长，但是它也因易用性而小有名气，原因是它随带易于使用的API，支持Scala(原生语言)、Java、Python和Spark SQL。Spark SQL非常类似于SQL 92，所以几乎不需要经历一番学习，马上可以上手。
Spark还有一种交互模式，那样开发人员和用户都可以获得查询和其他操作的即时反馈。MapReduce没有交互模式，不过有了Hive和Pig等附加模块，采用者使用MapReduce来得容易一点。
成本
MapReduce和Spark都是Apache项目，这意味着它们是开源免费软件产品。虽然软件不需要成本，但是派人用硬件运行任何一种平台带来了成本。这两种产品都设计成可以在商用硬件上运行，比如所谓的低成本白盒服务器系统。
MapReduce和Spark在同样的硬件上运行，那么这两种解决方案的成本差异体现在哪里?MapReduce使用常规数量的内存，因为数据处 理基于磁盘，所以公司得购买速度更快的磁盘和大量磁盘空间来运行MapReduce。MapReduce还需要更多的系统，将磁盘输入/输出分布到多个系 统上。
Spark需要大量内存，但是可以使用常规数量的常规转速磁盘。一些用户抱怨会产生临时文件，需要清理。这些临时文件通常保存7天，以便加快针对同 一数据集的任何处理。磁盘空间相对便宜，由于Spark不使用磁盘输入/输入用于处理，已使用的磁盘空间可以用于SAN或NAS。
然而，由于需要大量内存在内存中处理一切数据，Spark系统的成本更高，这点没错。但是Spark的技术同时减少了所需的系统数量。所以，最后的 情形是，系统成本较高，但是数量大大减少。也许到时候，Spark实际上可以降低每个计算单位的成本，尽管内存方面有额外的要求。
举例说明，“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身份验证。
总结Hadoop vs Spark
乍一看，对任何大数据应用而言，使用Spark似乎是默认选择。然而，事实并非如此。MapReduce已在大数据市场取得了进展，尤其受到这种公司企业的追捧：需要由商用系统对庞大数据集加以控制。Spark的速度、灵活性和相对易用性对MapReduce的低操作成本来说是绝对补充。
实际上，Spark与MapReduce是一种相互共生的关系。Hadoop提供了Spark所没有的功能特性，比如分布式文件系统，而Spark 为需要它的那些数据集提供了实时内存处理。完美的大数据场景正是设计人员当初预想的那样：让Hadoop和Spark在同一个团队里面协同运行。


来源：http://www.techweb.com.cn/network/system/2016-03-09/2292838.shtml；http://www.techweb.com.cn/network/system/2016-01-25/2267414.shtml