Spark 和 Hadoop MapReduce 对比

96 阅读 0 评论 64 点赞

我是靠谱客的博主魁梧向日葵，最近开发中收集的这篇文章主要介绍Spark 和 Hadoop MapReduce 对比，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

小编说：一提到大数据处理，相信很多人第一时间想到的是 Hadoop MapReduce。没错，Hadoop MapReduce 为大数据处理技术奠定了基础。近年来，随着 Spark 的发展，越来越多的声音提到了 Spark。而Spark相比Hadoop MapReduce有哪些优势？
本文选自《大数据处理之道》
图片描述
Spark与Hadoop MapReduce在业界有两种说法：一是 Spark 将代替 Hadoop MapReduce，成为未来大数据处理发展的方向；二是 Spark 将会和 Hadoop 结合，形成更大的生态圈。其实 Spark 和 Hadoop MapReduce 的重点应用场合有所不同。相对于 Hadoop MapReduce 来说，Spark 有点“青出于蓝”的感觉，Spark 是在Hadoop MapReduce 模型上发展起来的，在它的身上我们能明显看到 MapReduce的影子，所有的 Spark 并非从头创新，而是站在了巨人“MapReduce”的肩膀上。千秋功罪，留于日后评说，我们暂且搁下争议，来看看相比 Hadoop MapReduce，Spark 都有哪些优势。

1计算速度快
大数据处理首先追求的是速度。Spark 到底有多快？用官方的话说，“Spark 允许 Hadoop 集群中的应用程序在内存中以 100 倍的速度运行，即使在磁盘上运行也能快 10 倍”。可能有的读者看到这里会大为感叹，的确如此，在有迭代计算的领域，Spark 的计算速度远远超过 MapReduce，并且迭代次数越多，Spark 的优势越明显。这是因为 Spark 很好地利用了目前服务器内存越来越大这一优点，通过减少磁盘 I/O 来达到性能提升。它们将中间处理数据全部放到了内存中，仅在必要时才批量存入硬盘中。或许读者会问：如果应用程序特别大，内存能放下多少 GB ？答曰：什么？ GB ？目前 IBM 服务器内存已经扩展至几 TB 了。

2应用灵活，上手容易
知道 AMPLab 的 Lester 为什么放弃 MapReduce 吗？因为他需要把很多精力放到Map和Reduce的编程模型上，极为不便。 Spark在简单的Map及Reduce操作之外，还支持 SQL 查询、流式查询及复杂查询，比如开箱即用的机器学习算法。同时，用户可以在同一个工作流中无缝地搭配这些能力，应用十分灵活。
Spark 核心部分的代码为 63 个 Scala 文件，非常的轻量级。并且允许 Java、Scala、Python 开发者在自己熟悉的语言环境下进行工作，通过建立在 Java、Scala、Python、SQL（应对交互式查询）的标准 API 以方便各行各业使用，同时还包括大量开箱即用的机器学习库。它自带 80 多个高等级操作符，允许在 Shell中进行交互式查询。即使是新手，也能轻松上手应用。

3兼容竞争对手
Spark 可以独立运行，除了可以运行在当下的 YARN 集群管理外，还可以读取已有的任何 Hadoop 数据。它可以运行在任何 Hadoop 数据源上，比如 HBase、HDFS 等。有了这个特性，让那些想从 Hadoop 应用迁移到 Spark 上的用户方便了很多。Spark 有兼容竞争对手的胸襟，何愁大事不成？

4实时处理性能非凡
MapReduce 更加适合处理离线数据（当然，在 YARN 之后，Hadoop 也可以借助其他工具进行流式计算）。Spark 很好地支持实时的流计算，依赖Spark Streaming 对数据进行实时处理。Spark Streaming 具备功能强大的 API，允许用户快速开发流应用程序。而且不像其他的流解决方案，比如 Storm，Spark Streaming 无须额外的代码和配置，就可以做大量的恢复和交付工作。

5社区贡献力量巨大
从 Spark 的版本演化来看，足以说明这个平台旺盛的生命力及社区的活跃度。尤其自 2013 年以来，Spark 一度进入高速发展期，代码库提交与社区活跃度都有显著增长。以活跃度论，Spark 在所有的 Apache 基金会开源项目中位列前三，相较于其他大数据平台或框架而言，Spark 的代码库最为活跃。
Spark 非常重视社区活动，组织也极为规范，会定期或不定期地举行与 Spark相关的会议。会议分为两种：一种是 Spark Summit，影响力极大，可谓全球 Spark顶尖技术人员的峰会，目前已于 2013—2015 年在 San Francisco 连续召开了三届Summit 大会；另一种是 Spark 社区不定期地在全球各地召开的小型 Meetup 活动。Spark Meetup 也会在我国的一些大城市定期召开，比如北京、深圳、西安等地，读者可以关注当地的微信公众号进行参与。

Spark 的适用场景
从大数据处理需求来看，大数据的业务大概可以分为以下三类：
（1）复杂的批量数据处理，通常的时间跨度在数十分钟到数小时之间。
（2）基于历史数据的交互式查询，通常的时间跨度在数十秒到数分钟之间。
（3）基于实时数据流的数据处理，通常的时间跨度在数百毫秒到数秒之间。
目前已有很多相对成熟的开源和商业软件来处理以上三种情景：第一种业务，可以利用 MapReduce 来进行批量数据处理；第二种业务，可以用 Impala 来进行交互式查询；对于第三种流式数据处理，可以想到专业的流数据处理工具 Storm。但是这里有一个很重要的问题：对于大多数互联网公司来说，一般会同时遇到以上三种情景，如果采用不同的处理技术来面对这三种情景，那么这三种情景的输入/ 输出数据无法无缝共享，它们之间可能需要进行格式转换，并且每个开源软件都需要一支开发和维护团队，从而提高了成本。另外一个不便之处就是，在同一个集群中对各个系统协调资源分配比较困难。
那么，有没有一种软件可以同时处理以上三种情景呢？ Spark 就可以，或者说有这样的潜力。Spark 同时支持复杂的批处理、互操作和流计算，而且兼容支持HDFS 和 Amazon S3 等分布式文件系统，可以部署在 YARN 和 Mesos 等流行的集群资源管理器上。
从 Spark 的设计理念（基于内存的迭代计算框架）出发，其最适合有迭代运算的或者需要多次操作特定数据集的应用场合。并且迭代次数越多，读取的数据量越大，Spark 的应用效果就越明显。因此，对于机器学习之类的“迭代式”应用，Spark 可谓拿手好戏，要比 Hadoop MapReduce 快数十倍。另外，Spark Streaming因为内存存储中间数据的特性，处理速度非常快，也可以应用于需要实时处理大数据的场合。
当然，Spark 也有不适用的场合。对于那种异步细粒度更新状态的应用，例如 Web 服务的存储或增量的 Web 爬虫和索引，也就是对于那种增量修改的应用模型不适合。Spark 也不适合做超级大的数据量的处理，这里所说的“超级大”是相对于这个集群的内存容量而言的，因为 Spark 要将数据存储在内存中。一般来说，10TB 以上（单次分析）的数据就可以算是“超级大”的数据了。
一般来说，对于中小企业的数据中心而言，在单次计算的数据量不大的情况下，Spark 都是很好的选择。另外，Spark 也不适合应用于混合的云计算平台，因为混合的云计算平台的网络传输是很大的问题，即便有专属的宽带在云端 Cluster 和本地 Cluster 之间传输数据，相比内存读取速度来说，依然不抵。
图片描述