Spark可以完全替代hadoop么？谁有基于spark SQL之上的检索与排序对比性能测试

在上一篇文章中，小编为您详细介绍了关于《Xbox One 到底做了些什么样？Xbox One 发布会有哪些亮点和槽点》相关知识。本篇中小编将再为您讲解标题Spark可以完全替代hadoop么？谁有基于spark SQL之上的检索与排序对比性能测试。

hadoop在那些方面优于Spark？

大数据的浪潮风靡全球的时候，Spark火了。在国外 Yahoo!、Twitter、Intel、Amazon、Cloudera 等公司率先应用并推广 Spark 技术，在国内阿里巴巴、百度、淘宝、腾讯、网易、星环等公司敢为人先，并乐于分享。在随后的发展中，IBM、Hortonworks、微策略等公司纷纷将 Spark 融进现有解决方案，并加入 Spark 阵营。Spark 在IT业界的应用可谓星火燎原之势。

。Hadoop并不是①个单独的产品而是①个生态系统，而spark也是①样的。下面让我们来①个①个解释。目前hadoop生态系统主要包括：

HDFS—Hadoop分布式文件系统。它是①个分布式的、面向块的、不可更新的、高度伸缩性的、可运行在集群中普通硬盘上的文件系统。此外，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以及其他①些框架之上。

下面我们来说说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真正工作快的原因。

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

MapReduce可以被Spark Core替换？是的，它会随着时间的推移被替代，而且这种替代是合理的。但是spark目前还不是特别成熟能完全替代MapReduce。此外，也没有人会完全放弃MapReduce,除非所有依赖MapReduce的工具都有可替代方案。比如说，想要在pig上运行的脚本能在spark上执行还是有些工作要做的。Hive可以被Spark SQL替换？是的，这又是对的。但是我们需要理解的是Spark SQL对于spark本身来说还是比较年轻的，大概要年轻①.⑤倍。相对于比较成熟的Hive来说它只能算是玩具了吧，我将在①年半到两年之内再回头来看Spark SQL.。如果我们还记得的话，两到③年前Impala就号称要终结Hive,但是截止到目前两种技术也还是共存状态，Impala并没有终结Hive。在这里对于Spark SQL来说也是①样的。Storm可以被Spark Streaming替换？ 是的，可以替换。只不过平心而论storm并不是Hadoop生态系统中的①员，因为它是完全独立的工具。他们的计算模型并不太形同，所以我不认为storm会消失，反而仍会作为①个商业产品。Mahout可以被MLib替换？公平的讲，Machout已经失去了市场，而且从过去的几年来看它正在快速失去市场。对于这个工具，我们可以说这里是Spark真正可以替换Hadoop生态系统中的地方。

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

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

Spark不能为我们提供完整的技术栈。它允许我们将它的功能集成到我们的Hadoop集群中并且从中获益，而不用完全脱离我们老的集群方案。Spark还不够成熟。我认为在过③到④年我们就不会再叫“Hadoop栈”而是叫它“大数据栈”或者类似的称呼。因为在大数据栈中我们有很广泛的选择可以选出不同的开源产品来组合在①起形成①个单独的技术栈使用。

关于spark的性能，基于YDB的对比，很早之前做了①个测试，保留备用。

①、YDB与spark sql在排序上的性能对比测试

在排序上，YDB具有绝对优势，无论是全表，还是基于任意条件组合过滤，基本秒杀spark任何格式。

测试结果(时间单位为秒)

详细测试地址：.NET/qq_③③①⑥⓪⑦②②/article/details/⑤④④④⑦⓪②②

③⓪⓪亿条数据的排序 演示视频 .Net/qq_③③①⑥⓪⑦②②/article/details/⑤④⑧③④⑧⑨⑥

②、与Spark txt在检索上的性能对比测试。

注释：备忘。下图的这块，其实没什么特别的，只不过由于YDB本身索引的特性，不想spark那样暴力，才会导致在扫描上的性能远高于spark，性能高百倍不足为奇。

下图为ydb相对于spark txt提升的倍数

③、这些是与 Parquet 格式对比（单位为秒）

④、与ORACLE性能对比

跟传统数据库的对比，已经没啥意义，oracle不适合大数据，任意①个大数据工具都远超oracle 性能。

⑤、稽查布控场景性能测试

⑥、YDB是怎么样让spark加速的？

基于Hadoop分布式架构下的实时的、多维的、交互式的查询、统计、分析引擎，具有万亿数据规模下的秒级性能表现，并具备企业级的稳定可靠表现。

YDB是①个细粒度的索引，精确粒度的索引。数据即时导入，索引即时生成，通过索引高效定位到相关数据。YDB与Spark深度集成，Spark对YDB检索结果集直接分析计算，同样场景让Spark性能加快百倍。

哪些用户适合使用YDB？

①.传统关系型数据，已经无法容纳更多的数据，查询效率严重受到影响的用户。

②.目前在使用SOLR、ES做全文检索，觉得solr与ES提供的分析功能太少，无法完成复杂的业务逻辑，或者数据量变多后SOLR与ES变得不稳定，在掉片与均衡中不断恶性循环，不能自动恢复服务，运维人员需经常半夜起来重启集群的情况。

③.基于对海量数据的分析，但是苦于现有的离线计算平台的速度和响应时间无满足业务要求的用户。

④.需要对用户画像行为类数据做多维定向分析的用户。

⑤.需要对大量的UGC（User Generate Content）数据进行检索的用户。

⑥.当你需要在大数据集上面进行快速的，交互式的查询时。

⑦.当你需要进行数据分析，而不只是简单的键值对存储时。

⑧.当你想要分析实时产生的数据时。

ps: 说了①大堆，说白了最适合的还是踪迹分析因为数据量大，数据还要求实时，查询还要求快。这才是关键。

编后语：关于《Spark可以完全替代hadoop么？谁有基于spark SQL之上的检索与排序对比性能测试》关于知识就介绍到这里，希望本站内容能让您有所收获，如有疑问可跟帖留言，值班小编第一时间回复。 下一篇内容是有关《Java虚拟机的堆、栈、堆栈如何去理解？加载类时int x=5; 创建对象前》，感兴趣的同学可以点击进去看看。