你好,游客 登录 注册 搜索
背景:
阅读新闻

Spark与Hadoop MapReduce大比拼,谁实力更强

[日期:2016-11-04] 来源:CSDN  作者: [字体: ]

  一提到大数据处理,相信很多人第一时间想到的是 Hadoop MapReduce。没错,Hadoop MapReduce 为大数据处理技术奠定了基础。近年来,随着 Spark 的发展,越来越多的声音提到了 Spark。而Spark相比Hadoop MapReduce有哪些优势?

Hadoop

  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 之间传输数据,相比内存读取速度来说,依然不抵。





收藏 推荐 打印 | 录入:elainebo | 阅读: