hadoop与spark

1、SparkVSHadoop有哪些异同点？Hadoop:分布式批处理计算，强调批处理，常用于数据挖掘、分析Spark:是一个基于内存计算的开源的集群计算系统，目的是让数据分析更加快速,Spark是一种与Hadoop相似的开源集群计算环境，但是两者之间还存在一些不同之处，这些有用的不同之处使Spark在某些工作负载方面表现得更加优越，换句话说，Spark启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。Spark是在Scala语言中实现的，它将Scala用作其应用程序框架。与Hadoop不同，Spark和Scala能够紧密集成，其中的Scala可以像操作本地集合对象一样轻松地操作分布式数据集。尽管创建Spark是为了支持分布式数据集上的迭代作业，但是实际上它是对Hadoop的补充，可以在Hadoop文件系统中并行运行。通过名为Mesos的第三方集群框架可以支持此行为。Spark由加州大学伯克利分校AMP实验室(Algorithms,Machines,andPeopleLab)开发，可用来构建大型的、低延迟的数据分析应用程序。虽然Spark与Hadoop有相似之处，但它提供了具有有用差异的一个新的集群计算框架。首先，Spark是为集群计算中的特定类型的工作负载而设计，即那些在并行操作之间重用工作数据集（比如机器学习算法）的工作负载。为了优化这些类型的工作负载，Spark引进了内存集群计算的概念，可在内存集群计算中将数据集缓存在内存中，以缩短访问延迟.在大数据处理方面相信大家对hadoop已经耳熟能详，基于GoogleMap/Reduce来实现的Hadoop为开发者提供了map、reduce原语，使并行批处理程序变得非常地简单和优美。Spark提供的数据集操作类型有很多种，不像Hadoop只提供了Map和Reduce两种操作。比如map,filter,flatMap,sample,groupByKey,reduceByKey,union,join,cogroup,mapValues,sort,partionBy等多种操作类型，他们把这些操作称为Transformations。同时还提供Count,collect,reduce,lookup,save等多种actions。这些多种多样的数据集操作类型，给上层应用者提供了方便。各个处理节点之间的通信模型不再像Hadoop那样就是唯一的DataShuffle一种模式。用户可以命名，物化，控制中间结果的分区等。可以说编程模型比Hadoop更灵活.2、Spark在容错性方面是否比其他工具更有优越性？从Spark的论文《ResilientDistributedDatasets:AFault-TolerantAbstractionforIn-MemoryClusterComputing》中没看出容错性做的有多好。倒是提到了分布式数据集计算，做checkpoint的两种方式，一个是checkpointdata，一个是loggingtheupdates。貌似Spark采用了后者。但是文中后来又提到，虽然后者看似节省存储空间。但是由于数据处理模型是类似DAG的操作过程，由于图中的某个节点出错，由于lineagechains的依赖复杂性，可能会引起全部计算节点的重新计算，这样成本也不低。他们后来说，是存数据，还是存更新日志，做checkpoint还是由用户说了算吧。相当于什么都没说，又把这个皮球踢给了用户。所以我看就是由用户根据业务类型，衡量是存储数据IO和磁盘空间的代价和重新计算的代价，选择代价较小的一种策略。取代给中间结果进行持久化或建立检查点，Spark会记住产生某些数据集的操作序列。因此，当一个节点出现故障时，Spark会根据存储信息重新构造数据集。他们认为这样也不错，因为其他节点将会帮助重建。3、Spark对于数据处理能力和效率有哪些特色？Spark提供了高的性能和大数据处理能力，使得用户可以快速得到反馈体验更好。另一类应用是做数据挖掘，因为Spark充分利用内存进行缓存，利用DAG消除不必要的步骤，所以比较合适做迭代式的运算。而有相当一部分机器学习算法是通过多次迭代收敛的算法，所以适合用Spark来实现。我们把一些常用的算法并行化用Spark实现，可以从R语言中方便地调用，降低了用户进行数据挖掘的学习成本。Spark配有一个流数据处理模型，与Twitter的Storm框架相比，Spark采用了一种有趣而且独特的办法。Storm基本上是像是放入独立事务的管道，在其中事务会得到分布式的处理。相反，Spark采用一个模型收集事务，然后在短时间内（我们假设是5秒）以批处理的方式处理事件。所收集的数据成为他们自己的RDD，然后使用Spark应用程序中常用的一组进行处理。作者声称这种模式是在缓慢节点和故障情况下会更加稳健，而且5秒的时间间隔通常对于大多数应用已经足够快了。这种方法也很好地统一了流式处理与非流式处理部分。随着大数据相关技术和产业的逐渐成熟，单个组织内往往需要同时进行多种类型的大数据分析作业：传统HadoopMapReduce最为擅长的批量计算、各种机器学习算法为代表的迭代型计算、流式计算、社交网络中常用的图计算、SQL关系查询、交互式即席查询等。在Spark出现前，要在一个组织内同时完成以上数种大数据分析任务，就不得不与多套独立的系统打交道，一方面引入了不容小觑的运维复杂性，另一方面还免不了要在多个系统间频繁进行代价高昂的数据转储。Spark是发源于美国加州大学伯克利分校AMPLab的集群计算平台，它立足于内存计算，性能超过Hadoop百倍，从多迭代批量处理出发，兼收并蓄数据仓库、流处理和图计算等多种计算范式，是罕见的全能选手。Spark当下已成为Apache基金会的顶级开源项目，拥有着庞大的社区支持（活跃开发者人数已超过HadoopMapReduce），技术也逐渐走向成熟。Spark比Hadoop受追捧有多重原因摘要：当下，Spark已得到了多方追捧，基于MapReduce的分布式计算方法使Spark类似于Hadoop，却又比Hadoop的通用性更好，迭代运算效率更高，容错能力更强，未来的Spark将会是非常成功的并行计算框架。作者：MikioBraun来源：CSDN|2014年01月29日10:12:11关键字：大数据HadoopSparkZDNet至顶网服务器频道01月29日：当下，Spark已得到了多方追捧，基于MapReduce的分布式计算方法使Spark类似于Hadoop，却又比Hadoop的通用性更好，迭代运算效率更高，容错能力更强，未来的Spark将会是非常成功的并行计算框架。ApacheSpark现在名声大噪。为支持Spark项目成立的Databricks公司从AndereessenHorowittz那里募集了1400万美元，Cloudera也已决定全力支持Spark，还有众多其它公司也积极地加入这件大事。所以我觉得这正是我应该认真了解一下这场躁动的时候。我研究了一段时间的ScalaAPI（用Scala写的Spark），老实说一开始我很失望，因为Spark看起来真的太不起眼了。基本的抽象是ResilientDistributedDatasets（RDDs）和基本分布式不可变集，可以基于本地文件或通过HDFS存储在Hadoop上的文件定义，提供常用的Scala-style集合操作（如映射，foreach等）。我的第一反应是没搞错吧，这真是基本分布式集合吗？。相比之下Hadoop就显得丰富多了：分布式文件系统，众所周知的MapReduce，支持所有类型的数据格式、数据源、单元测试、聚类变量等。其他人很快就指出还有更多，事实上Spark也提供更复杂的操作（如join、依据操作分组或规约），这样你就可以为相当复杂的数据流建模（虽然没有迭代）。随着时间的推移我恍然大悟，原来Spark所谓的简单其实说的大多是关于Hadoop中的JavaAPI而不是Spark本身。即使是简单的例子在Hadoop中通常也会有大量的样板代码。但从概念上讲，Hadoop非常简单，它只提供了两种基本操作：并行的映射（Map）和规约（Reduce）操作。如果用相同的方式，对表示相似分布式集合，事实上将有更小的接口（有些项目像Scalding就是处理类似的事情，并且代码看起来很类似Spark）。Spark实际上提供了一组重要的操作，在这一点让我信服以后，我通过这个论文进行了更深入的研究，它描述了通用的架构。RDDs是Spark的基本构造模块，实际上真的很像分布式不可变集。这些定义的操作（如map或foreach），容易地进行并行处理；还有join运算，需要两个RDDs和收集基于一个共同键的条目；以及依据操作规约，通过用户指定基于键的函数来聚合条目。在单词计数示例中，计数一次就将文本映射到所有的单词，然后用键对他们进行规约，以此来实现字数统计。RDDs可以从磁盘中读取，然后为提高速度而保留在内存中，他们也可以被缓存，那样你就不需要每次都重读他们。仅那样就比Hadoop快了很多，这大部分是基于磁盘的速度。容错机制也是Spark的亮点之一。取代给中间结果进行持久化或建立检查点，Spark会记住产生某些数据集的操作序列。因此，当一个节点出现故障时，Spark会根据存储信息重新构造数据集。他们认为这样也不错，因为其他节点将会帮助重建。所以本质上，Spark相比纯粹的Hadoop，有更小的接口（可能在将来也会变得臃肿)，但有许多基于之上的项目（例如像Twitter的Scalding）达到了类似水平的表现。其他的主要区别是Spark默认情况下是在内存中，这自然带来性能上很大的改善，甚至允许运行的迭代算法。虽然Spark已也没有内置对迭代的支持，不过，就像他们宣称的那样：只要你想要，它就可以快到让你可以进行迭代。Spark流——微批处理的回归Spark还配有一个流数据处理模型，这当然让我很感兴趣。还有一篇对设计总结得很漂亮的论文。与Twitter的Storm框架相比，Spark采用了一种有趣而且独特的办法。Storm基本上是像是放入独立事务的管道，在其中事务会得到分布式的处理。相反，Spark采用一个模型收集事务，然后在短时间内（我们假设是5秒）以批处理的方式处理事件。所收集的数据成为他们自己的RDD，然后使用Spark应用程序中常用的一组进行处理。作者声称这种模式是在缓慢节点和故障情况下会更加稳健，而且5秒的时间间隔通常对于大多数应用已经足够快了。对于这一点，我不太确定，因为分布式计算总是很复杂，我不相信你能随意说有些东西是就比其他人的好。这种方法也很好地统一了流式处理与非流式处理部分，这一点是千真万确的。结束语Spark在我看来还是很有前途的，加上Spark被给予的支持和获得的关注，我坚信它将成熟起来并将在这个领域扮演更加重要的角色。当然，它不可能适用于所有场景，正如作者承认的那样，基于RDD稳定性只更改很少条目的操作就不适合。原则上，你必须对整个数据集备份，即使你只是想要更改一个条目。这可以很好地并行处理，但成本很高。copy-on-write在这里可能更有效，但是还未被实现。最上层是在TUBerlin的研究项目，有类似的目标，然而却通过更为复杂的操作（如迭代）来发展，不仅是为了容错能力存储一系列操作，而且要将它们用于全局调度优化和平行化。