hive,shark,sparkSQL,hive on spark,impala,drill比较

时间  2019-11-05
标签 hive shark sparksql spark impala drill 比较 栏目 Hadoop 繁體版
原文   原文链接

Hive on Mapreduce

Hive的原理你们能够参考这篇大数据时代的技术hive：hive介绍，实际的一些操做能够看这篇笔记：新手的Hive指南，至于还有兴趣看Hive优化方法能够看看我总结的这篇Hive性能优化上的一些总结html

Hive on Mapreduce执行流程

这里写图片描述

执行流程详细解析java

  • Step 1：UI(user interface) 调用 executeQuery 接口，发送 HQL 查询语句给 Driver
  • Step 2：Driver 为查询语句建立会话句柄，并将查询语句发送给 Compiler， 等待其进行语句解析并生成执行计划
  • Step 3 and 4：Compiler 从 metastore 获取相关的元数据
  • Step 5：元数据用于对查询树中的表达式进行类型检查，以及基于查询谓词调整分区，生成计划
  • Step 6 (6.1，6.2，6.3)：由 Compiler 生成的执行计划是阶段性的 DAG，每一个阶段均可能会涉及到 Map/Reduce job、元数据的操做、HDFS 文件的操做，Execution Engine 将各个阶段的 DAG 提交给对应的组件执行。
  • Step 7, 8 and 9：在每一个任务（mapper / reducer）中，查询结果会以临时文件的方式存储在 HDFS 中。保存查询结果的临时文件由 Execution Engine 直接从 HDFS 读取，做为从 Driver Fetch API 的返回内容。

Hive on Mapreduce特色

  1. 关系数据库里，表的加载模式是在数据加载时候强制肯定的（表的加载模式是指数据库存储数据的文件格式），若是加载数据时候发现加载的数据不符合模式，关系数据库则会拒绝加载数据，这个就叫“写时模式”，写时模式会在数据加载时候对数据模式进行检查校验的操做。Hive在加载数据时候和关系数据库不一样，hive在加载数据时候不会对数据进行检查，也不会更改被加载的数据文件，而检查数据格式的操做是在查询操做时候执行，这种模式叫“读时模式”。在实际应用中，写时模式在加载数据时候会对列进行索引，对数据进行压缩，所以加载数据的速度很慢，可是当数据加载好了，咱们去查询数据的时候，速度很快。可是当咱们的数据是非结构化，存储模式也是未知时候，关系数据操做这种场景就麻烦多了，这时候hive就会发挥它的优点。
  2. 关系数据库一个重要的特色是能够对某一行或某些行的数据进行更新、删除操做，hive**不支持对某个具体行的操做，hive对数据的操做只支持覆盖原数据和追加数据**。Hive也不支持事务和索引。更新、事务和索引都是关系数据库的特征，这些hive都不支持，也不打算支持，缘由是hive的设计是海量数据进行处理，全数据的扫描时常态，针对某些具体数据进行操做的效率是不好的，对于更新操做，hive是经过查询将原表的数据进行转化最后存储在新表里，这和传统数据库的更新操做有很大不一样。
  3. Hive也能够在hadoop作实时查询上作一份本身的贡献，那就是和hbase集成，hbase能够进行快速查询，可是hbase不支持类SQL的语句，那么此时hive能够给hbase提供sql语法解析的外壳，能够用类sql语句操做hbase数据库。
  4. Hive能够认为是MapReduce的一个封装、包装。Hive的意义就是在业务分析中将用户容易编写、会写的Sql语言转换为复杂难写的MapReduce程序，从而大大下降了Hadoop学习的门槛，让更多的用户能够利用Hadoop进行数据挖掘分析。

与传统数据库之间对比—From：Hive和传统数据库进行比较python

比较项 SQL HiveQL
ANSI SQL 支持 不彻底支持
更新 UPDATE\INSERT\DELETE insert OVERWRITE\INTO TABLE
事务 支持 不支持
模式 写模式 读模式
数据保存 块设备、本地文件系统 HDFS
延时 低 高
多表插入 不支持 支持
子查询 彻底支持 只能用在From子句中
视图 Updatable Read-only
可扩展性 低 高
数据规模 小 大
…. …… ……

SparkSQL

SparkSQL简介

SparkSQL的前身是Shark，给熟悉RDBMS但又不理解MapReduce的技术人员提供快速上手的工具，hive应运而生，它是当时惟一运行在Hadoop上的SQL-on-hadoop工具。可是MapReduce计算过程当中大量的中间磁盘落地过程消耗了大量的I/O，下降的运行效率，为了提升SQL-on-Hadoop的效率，Shark应运而生，但又由于Shark对于Hive的太多依赖（如采用Hive的语法解析器、查询优化器等等),2014年spark团队中止对Shark的开发，将全部资源放SparkSQL项目上算法

​ 其中SparkSQL做为Spark生态的一员继续发展，而再也不受限于Hive，只是兼容Hive；而Hive on Spark是一个Hive的发展计划，该计划将Spark做为Hive的底层引擎之一，也就是说，Hive将再也不受限于一个引擎，能够采用Map-Reduce、Tez、Spark等引擎。sql

  • SparkSQL的两个组件shell

    1. SQLContext：Spark SQL提供SQLContext封装Spark中的全部关系型功能。能够用以前的示例中的现有SparkContext建立SQLContext。
    2. DataFrame：DataFrame是一个分布式的，按照命名列的形式组织的数据集合。DataFrame基于R语言中的data frame概念，与关系型数据库中的数据库表相似。经过调用将DataFrame的内容做为行RDD（RDD of Rows）返回的rdd方法，能够将DataFrame转换成RDD。能够经过以下数据源建立DataFrame：已有的RDD、结构化数据文件、JSON数据集、Hive表、外部数据库。

SparkSQL运行架构

相似于关系型数据库，SparkSQL也是语句也是由Projection（a1，a2，a3）、Data Source（tableA）、Filter（condition）组成，分别对应sql查询过程当中的Result、Data Source、Operation，也就是说SQL语句按Operation–>Data Source–>Result的次序来描述的。数据库

当执行SparkSQL语句的顺序apache

  1. 对读入的SQL语句进行解析（Parse），分辨出SQL语句中哪些词是关键词（如SELECT、FROM、WHERE），哪些是表达式、哪些是Projection、哪些是Data Source等，从而判断SQL语句是否规范； 
    • Projection：简单说就是select选择的列的集合，参考：SQL Projection
  2. 将SQL语句和数据库的数据字典（列、表、视图等等）进行绑定（Bind），若是相关的Projection、Data Source等都是存在的话，就表示这个SQL语句是能够执行的；
  3. 通常的数据库会提供几个执行计划，这些计划通常都有运行统计数据，数据库会在这些计划中选择一个最优计划（Optimize）；
  4. 计划执行（Execute），按Operation–>Data Source–>Result的次序来进行的，在执行过程有时候甚至不须要读取物理表就能够返回结果，好比从新运行刚运行过的SQL语句，可能直接从数据库的缓冲池中获取返回结果。

Hive on Spark

​ hive on Spark是由Cloudera发起，由Intel、MapR等公司共同参与的开源项目，其目的是把Spark做为Hive的一个计算引擎，将Hive的查询做为Spark的任务提交到Spark集群上进行计算。经过该项目，能够提升Hive查询的性能，同时为已经部署了Hive或者Spark的用户提供了更加灵活的选择，从而进一步提升Hive和Spark的普及率。编程

Hive on Spark与SparkSql的区别

​ hive on spark大致与SparkSQL结构相似，只是SQL引擎不一样，可是计算引擎都是spark！敲黑板！这才是重点！json

咱们来看下，在pyspark中使用Hive on Spark是中怎么样的体验

#初始化Spark SQL #导入Spark SQL from pyspark.sql import HiveContext,Row # 当不能引入Hive依赖时 # from pyspark.sql import SQLContext,Row # 注意，上面那一点才是关键的，他两来自于同一个包，大家区别能有多大 hiveCtx = HiveContext(sc) #建立SQL上下文环境 input = hiveCtx.jsonFile(inputFile) #基本查询示例 input.registerTempTable("tweets") #注册输入的SchemaRDD（SchemaRDD在Spark 1.3版本后已经改成DataFrame） #依据retweetCount(转发计数)选出推文 topTweets = hiveCtx.sql("SELECT text,retweetCount FROM tweets ORDER BY retweetCount LIMIT 10")

咱们能够看到，sqlcontext和hivecontext都是出自于pyspark.sql包，能够从这里理解的话，其实hive on spark和sparksql并无太大差异

结构上Hive On Spark和SparkSQL都是一个翻译层，把一个SQL翻译成分布式可执行的Spark程序。并且你们的引擎都是spark

SparkSQL和Hive On Spark都是在Spark上实现SQL的解决方案。Spark早先有Shark项目用来实现SQL层，不事后来推翻重作了，就变成了SparkSQL。这是Spark官方Databricks的项目，Spark项目自己主推的SQL实现。Hive On Spark比SparkSQL稍晚。Hive本来是没有很好支持MapReduce以外的引擎的，而Hive On Tez项目让Hive得以支持和Spark近似的Planning结构（非MapReduce的DAG）。因此在此基础上，Cloudera主导启动了Hive On Spark。这个项目获得了IBM，Intel和MapR的支持（可是没有Databricks）。—From SparkSQL与Hive on Spark的比较

Hive on Mapreduce和SparkSQL使用场景

Hive on Mapreduce场景

  • Hive的出现可让那些精通SQL技能、可是不熟悉MapReduce 、编程能力较弱与不擅长Java语言的用户可以在HDFS大规模数据集上很方便地利用SQL 语言查询、汇总、分析数据，毕竟精通SQL语言的人要比精通Java语言的多得多
  • Hive适合处理离线非实时数据

SparkSQL场景

  • Spark既能够运行本地local模式，也能够以Standalone、cluster等多种模式运行在Yarn、Mesos上，还能够运行在云端例如EC2。此外，Spark的数据来源很是普遍，能够处理来自HDFS、HBase、 Hive、Cassandra、Tachyon上的各类类型的数据。
  • 实时性要求或者速度要求较高的场所

Hive on Mapreduce和SparkSQL性能对比

具体实验参见：Spark SQL & Spark Hive编程开发， 并和Hive执行效率对比

结论：sparksql和hive on spark时间差很少，但都比hive on mapreduce快不少，官方数据认为spark会被传统mapreduce快10-100倍

关于Spark

简介

在Hadoop的整个生态系统中，Spark和MapReduce在同一个层级，即主要解决分布式计算框架的问题。

 

架构

Spark的架构以下图所示，主要包含四大组件：Driver、Master、Worker和Executor。

spark cluster

 

Spark特色

  • Spark能够部署在YARN上
  • Spark原生支持对HDFS文件系统的访问
  • 使用Scala语言编写

 

部署模型

  1. 单机模型：主要用来开发测试。特色：Driver、Master、Worker和Executor都运行在同一个JVM进程之中。
  2. 伪集群模型：主要用来开发测试。特色：Master、Worker都运行在同一个JVM进程之中；Master、Worker和Executor都运行于同一台机器，没法跨机器运行；
  3. 独立集群（又叫作原生集群模式）：在集群规模不是很是大的状况下，可用于生产环境。特色：Master、Worker和Executor都运行于独立的JVM进程。
  4. YARN集群：YARN生态中的ApplicationMaster角色使用Apache开发好的Spark ApplicationMaster代替，每个YARN生态中的NodeManager角色至关于一个Spark生态中的Worker角色，由NodeManger负责Executor的启动。
  5. Mesos集群：暂无详细调研。

关于Spark SQL

简介

它主要用于结构化数据处理和对Spark数据执行类SQL的查询。经过Spark SQL，能够针对不一样格式的数据执行ETL操做（如JSON，Parquet，数据库）而后完成特定的查询操做。通常来讲，Spark每支持一种新的应用开发，都会引入一个新的Context及相应的RDD，对于SQL这一特性来讲，引入的就是SQLContext和SchemaRDD。注意：在Spark1.3以后，SchemaRDD已经改名为DataFrame，但它本质就相似一个RDD，由于能够将DataFrame无缝的转换成一个RDD。

 

架构

Spark要很好的支持SQL，要完成解析(parser)、优化(optimizer)、执行(execution)三大过程。

spark cluster


处理顺序大体以下：

  1. SQlParser生成LogicPlan Tree；
  2. Analyzer和Optimizer将各类Rule做用于LogicalPlan Tree；
  3. 最终优化生成的LogicalPlan生成SparkRDD；
  4. 最后将生成的RDD交由Spark执行；

关于Hive on Spark

背景

Hive on Spark是由Cloudera发起，由Intel、MapR等公司共同参与的开源项目，其目的是把Spark做为Hive的一个计算引擎，将Hive的查询做为Spark的任务提交到Spark集群上进行计算。经过该项目，能够提升Hive查询的性能，同时为已经部署了Hive或者Spark的用户提供了更加灵活的选择，从而进一步提升Hive和Spark的普及率。

 

简介

Hive on Spark是从Hive on MapReduce演进而来，Hive的总体解决方案很不错，可是从查询提交到结果返回须要至关长的时间，查询耗时太长，这个主要缘由就是因为Hive原生是基于MapReduce的，那么若是咱们不生成MapReduce Job，而是生成Spark Job，就能够充分利用Spark的快速执行能力来缩短HiveQL的响应时间。

Hive on Spark如今是Hive组件(从Hive1.1 release以后)的一部分。

 

与SparkSQL的区别

SparkSQL和Hive On Spark都是在Spark上实现SQL的解决方案。Spark早先有Shark项目用来实现SQL层，不事后来推翻重作了，就变成了SparkSQL。这是Spark官方Databricks的项目，Spark项目自己主推的SQL实现。Hive On Spark比SparkSQL稍晚。Hive本来是没有很好支持MapReduce以外的引擎的，而Hive On Tez项目让Hive得以支持和Spark近似的Planning结构（非MapReduce的DAG）。因此在此基础上，Cloudera主导启动了Hive On Spark。这个项目获得了IBM，Intel和MapR的支持（可是没有Databricks）。

 

使用示例

大致与SparkSQL结构相似，只是SQL引擎不一样。部分核心代码以下：

val hiveContext = new HiveContext(sc)

import hiveContext._

hql("CREATE TABLE IF NOT EXIST src(key INT, value STRING)")

hql("LOAD DATA LOCAL PATH '/Users/urey/data/input2.txt' INTO TABLE src")

hql("FROM src SELECT key, value").collect().foreach(println)
  •  

小结

结构上Hive On Spark和SparkSQL都是一个翻译层，把一个SQL翻译成分布式可执行的Spark程序。好比一个SQL：

SELECT item_type, sum(price)
FROM item
GROUP item_type;

上面这个SQL脚本交给Hive或者相似的SQL引擎，它会“告诉”计算引擎作以下两个步骤：读取item表，抽出item_type,price这两个字段；对price计算初始的SUM（其实就是每一个单独的price做为本身的SUM）由于GROUP BY说须要根据item_type分组，因此设定shuffle的key为item_type从第一组节点分组后分发给聚合节点，让相同的item_type汇总到同一个聚合节点，而后这些节点把每一个组的Partial Sum再加在一块儿，就获得了最后结果。无论是Hive仍是SparkSQL大体上都是作了上面这样的工做。

须要理解的是，Hive和SparkSQL都不负责计算，它们只是告诉Spark，你须要这样算那样算，可是自己并不直接参与计算。

Spark Shark | 即 Hive on Spark

a.在实现上是把HQL翻译成Spark上的RDD操做，而后经过Hive的metadata获取数据库里的表信息，Shark获取HDFS上的数据和文件夹放到Spark上运算。

b.它的最大特性就是快以及与Hive彻底兼容

c.Shark使用了Hive的API来实现query parsing和logic plan generation,最后的Physical Plan execution阶段用Spark代替Hadoop MR。

d.经过配置Shark参数，Shark能够自动在内存中缓存特定的RDD,实现数据重用，进而加快特定数据集的检索。

e.Shark经过UDF实现特定的数据分析学习算法，使得SQL数据查询和运算分析结合在一块儿，最大化RDD的重复使用。

Spark SQL

a.是基于Catalyst(翻译为催化剂)引擎的交互式大数据SQL技术,使用SchemaRDD来操做SQL,比Shark支持更过的查询表达式。

b.支持Hive|HBase|Oracle

交互式SQL处理框架Spark SQL

a.SparkSQL的四个特色：

1.能在Scala代码里写SQL,支持简单的SQL语法检查，能把RDD指定为Table存储起来。对SQL的支持主要依赖Catalyst(催化剂)查询优化框架，在把SQL解析成逻辑执行计划以后，利用Catalyst包里的一些类和接口，执行了一些简单的执行计划优化

最后变成RDD的计算。

2.支持Parquet(arquet是面向分析型业务的列式存储格式)文件的读写，且保留Schem.Parquet是一个列式存储格式的文件系统，使用Parquet进行文件读写能够极大地下降对CPU和磁盘I/O的消耗。

3.支持直接多JSON格式数据的操做。

4.能在Scala代码里访问Hive元数据，能执行hive语句，而且把结果取回做为RDD使用。Shark依赖Hive的metastore,解析器能把hql执行变成Spark的计算，SparkSQL的前身是Shark，而Shark的前身是HIVE.

5.Shark对于Hive的依赖太多，为了摆脱依赖性，SparkSQL不管在数据兼容|性能优化|组件扩展都获得了极大的方便。

b.SparkSQL的性能：

1.Shark的出现，使得SQL-on-hadoop的性能比hive有了10~100倍的提升。摆脱Hive的限制，SSQL的性能也很优秀

在2014年7月1日的Spark Summit上，Databricks宣布终止对Shark的开发，将重点放到Spark SQL上。Databricks表示，Spark SQL将涵盖Shark的全部特性，用户能够从Shark 0.9进行无缝的升级。

Databricks
本次Databricks推广的Shark相关项目一共有两个，分别是Spark SQL和新的Hive on Spark（HIVE-7292），在介绍这两个项目以前，咱们首先关注下被终止的项目Shark。

Shark及项目终止缘由

About Shark

Shark发布于3年前，那个时候，Hive能够说是SQL on Hadoop的惟一选择，负责将SQL编译成可扩展的MapReduce做业。鉴于Hive的性能以及与Spark的兼容，Shark项目由此而生。

Shark即Hive on Spark，本质上是经过Hive的HQL解析，把HQL翻译成Spark上的RDD操做，而后经过Hive的metadata获取数据库里的表信息，实际HDFS上的数据和文件，会由Shark获取并放到Spark上运算。

Shark的最大特性就是快和与Hive的彻底兼容，且能够在shell模式下使用rdd2sql()这样的API，把HQL获得的结果集，继续在scala环境下运算，支持本身编写简单的机器学习或简单分析处理函数，对HQL结果进一步分析计算。

除去Spark自己的迭代计算，Shark速度快的缘由还在于其自己的改造，好比：

partial DAG execution：对join优化，调节并行粒度，由于Spark自己的宽依赖和窄依赖会影响并行计算和速度
基于列的压缩和存储：把HQL表数据按列存，每列是一个array，存在JVM上，避免了JVM GC低效，而压缩和解压相关的技术是Yahoo!提供的。
终止Shark的缘由

在会议上，Databricks表示，Shark更可能是对Hive的改造，替换了Hive的物理执行引擎，所以会有一个很快的速度。然而，不容忽视的是，Shark继承了大量的Hive代码，所以给优化和维护带来了大量的麻烦。随着性能优化和先进分析整合的进一步加深，基于MapReduce设计的部分无疑成为了整个项目的瓶颈。

所以，为了更好的发展，给用户提供一个更好的体验，Databricks宣布终止Shark项目，从而将更多的精力放到Spark SQL上。

两个相关/替代项目介绍

About Spark SQL

既然不是基于Hive，Spark SQL究竟有什么样的改变，这里咱们不妨看向 张包峰的博客。Spark新发布的Spark SQL组件让Spark对SQL有了别样于Shark基于Hive的支持。参考官方手册，具体分三部分：

其一，能在Scala代码里写SQL，支持简单的SQL语法检查，能把RDD指定为Table存储起来。此外支持部分SQL语法的DSL。
其二，支持Parquet文件的读写，且保留Schema。
其三，能在Scala代码里访问Hive元数据，能执行Hive语句，而且把结果取回做为RDD使用。
第一点对SQL的支持主要依赖了Catalyst这个新的查询优化框架（下面会给出一些Catalyst的简介），在把SQL解析成逻辑执行计划以后，利用Catalyst包里的一些类和接口，执行了一些简单的执行计划优化，最后变成RDD的计算。虽然目前的SQL解析器比较简单，执行计划的优化比较通配，还有些参考价值，因此看了下这块代码。目前这个PR在昨天已经merge进了主干，能够在SQL模块里看到这部分实现，还有catalyst模块看到Catalyst的代码。下面会具体介绍Spark SQL模块的实现。

第二点对Parquet的支持不关注，由于咱们的应用场景里不会使用Parquet这样的列存储，适用场景不同。

第三点对Hive的这种结合方式，没有什么核心的进展。与Shark相比，Shark依赖Hive的Metastore，解析器等能把hql执行变成Spark上的计算，而Hive的如今这种结合方式与代码里引入Hive包执行hql没什么本质区别，只是把hive hql的数据与RDD的打通这种交互作得更友好了。

About HIVE-7292

HIVE-7292更像是Spark SQL成为标准SQL on Spark项目的补充，首先它是一个Hive on Spark Project，旨在服务已有Hive投入的机构，这个项目将Spark做为一个替代执行引擎提供给Hive，从而为这些机构提供一个迁往Spark的途径，提供一个更流畅的Hive体验。

随着Spark SQL的引入和新的Hive on Apache Spark方向的努力（HIVE-7292），许多人询问咱们在这两个项目中的位置，以及它们与Shark的关系。在今天的Spark峰会上，咱们宣布，咱们中止了Shark的开发，并会专一于Spark SQL，它将提供Shark特性的超集，以便于现有的Shark用户继续使用。Spark SQL提供了从Shark 0.9的无缝升级，以及一些诸如通用Spark程序的集成等新特性。

image

Shark

三年前Shark项目开始的时候，Hive（on MapReduce）是SQL on Hadoop的惟一选择。Hive把SQL编译成可扩展的MapReduce做业，并且能够支持多种格式（经过它的SerDes）。可是其性能并不理想。为了交互式地执行查询，许多公司部署了昂贵的专用企业数据仓库（EDWs），这须要严格的、冗长的ETL流程。

Hive和EDWs之间的性能对比在工业界引发了关于在通用数据处理引擎上进行查询处理的内在缺陷的巨大争论。许多人认为SQL交互须要一个昂贵的专用系统用于查询处理（如EDWs）。Shark成为了一种较早的交互式SQL on Hadoop系统，并且是惟一一种基于通用运行环境（Spark）构建的。它代表了全部致使Hive慢的缺陷都不是根本性的，像Spark这样的通用引擎就能同时达到两方面的要求：和EDW同样快，和Hive/MapReduce同样可扩展。

为何你应该关注这个看似比较学术的争论呢？各类组织都在寻找能给它们带来商业优点的方法，它们使用了不少超出SQL提供的上卷和下钻能力的技术。基于通用环境构建一个SQL查询引擎统一了许多不一样的、强大的模型，例如batch、streaming、机器学习。这使得数据科学家和工程师可以更快的执行更复杂的方法。Shark的观点很快被接受了，甚至催生了Hive的一些重要改进。

从Shark到Spark SQL

Shark基于Hive源码构建，并经过替换Hive的物理执行引擎得到了性能上的提高。虽然这种方法让Shark用户能更快的执行Hive查询，可是Shark从Hive继承了大量复杂的源码，于是致使难以优化和维护。随着咱们逐步逼近性能优化的极限和集成复杂的SQL分析，咱们被那些按照MapReduce设计的遗产所束缚。

正由于如此，咱们中止了Spark做为一个单独项目的开发，并把全部的开发资源转向Spark SQL，Spark的一个新组件。咱们借鉴了Shark的经验用到Spark SQL中，并从新设计以更好了利用Spark。这种新途径让咱们更快的创新，最终为用户交付更好的体验。

对于SQL用户，Spark SQL提供了最早进的SQL性能并兼容Shark/Hive。像Shark同样，Spark SQL支持全部的Hive数据格式，用户定义函数（UDF），和Hive metastore。Spark1.1.0引入新的特性后，TPC-DS performance中，Spark SQL性能比Shark高一个数量级。

对于Spark用户，Spark SQL成为了处理（半）结构化数据和诸如JSON、Parquet、Hive或EDWs等有模式的数据源的细腰（narrow-waist）。它确实统一了SQL和复杂分析，容许用户混合SQL和更多编程API以实现高级分析。

对于开源黑客，Spark SQL提供了一种新的简洁的方法去构建查询计划。在这个框架下添加新的优化很简单。咱们已经彻底被开源社区对于Spark SQL的热情所折服，多亏这个新设计。仅仅三个月，就有40多为贡献者提交了代码。谢谢。

Hive on Spark（HIVE-7292）

虽然Spark SQL逐渐成为SQL on Spark的标准，可是咱们知道许多组织已经使用了Hive。这里面也有不少公司想迁移到Spark。Hive社区提出了一个新举措，这样能使Spark做为Hive的一个可选执行引擎。对于上述组织，参照上述引文能够把执行引擎迁移到Spark。咱们很高兴能与Hive社区一块儿为用户提供更平顺的体验。

总之，咱们坚信Spark SQL会是基于Spark的SQL和结构化数据处理的将来。咱们将努力工做，并在随后几个releases带来更多特性。对于有遗留Hive部署的公司，Hive on Spark会为他们提供支持。

英文原文：发表于2014年7月1日 
Shark, Spark SQL, Hive on Spark, and the future of SQL on Apache Spark

Impala与Shark，Drill等的比较

开源组织Apache也发起了名为Drill的项目来实现Hadoop上的Dremel，目前该项目正在开发当中，相关的文档和代码还很少，能够说暂时还未对Impala构成足够的威胁。从Quora上的问答来看，Cloudera有7-8名工程师全职在Impala项目上，而相比之下Drill目前的动做稍显迟钝。具体来讲，截止到2012年10月底，Drill的代码库里实现了query parser, plan parser，及能对JSON格式的数据进行扫描的plan evaluator；而Impala同期已经有了一个比较完毕的分布式query execution引擎，并对HDFS和HBase上的数据读入，错误检测，INSERT的数据修改，LLVM动态翻译等都提供了支持。固然，Drill做为Apache的项目，从一开始就避免了某个vendor的一家独大，并且对全部Hadoop流行的发行版都会作相应的支持，不像Impala只支持Cloudera本身的发行版CDH。从长远来看，谁会占据上风还真不必定。

除此以外，加州伯克利大学AMPLab也开发了名为Shark的大数据分析系统。从长远目标来看，Shark想成为一个既支持大数据SQL查询，又能支持高级数据分析任务的一体化数据处理系统。从技术实现的角度上来看，Shark基于Scala语言的算子推导实现了良好的容错机制，所以对失败了的长任务和短任务都能从上一个“快照点”进行快速恢复。相比之下，Impala因为缺失足够强大的容错机制，其上运行的任务一旦失败就必须“从头来过”，这样的设计必然会在性能上有所缺失。并且Shark是把内存看成第一类的存储介质来作的系统设计，因此在处理速度上也会有一些优点。实际上，AMPLab最近对Hive，Impala，Shark及Amazon采用的商业MPP数据库Redshift进行了一次对比试验，在Scan Query，Aggregation Query和Join Query三种类型的任务中对它们进行了比较。图2就是AMPLab报告中Aggregation Query的性能对比。在图中咱们能够看到，商业版本的Redshift的性能是最好的， Impala和Shark则各有胜负，且二者都比Hive的性能高出了一大截。

impala-drill

参考：

Shark对Hive的兼容性总结

前世此生：Hive、Shark、spark SQL

impala与hive的比较以及impala的有缺点

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程