Hive的原理大家可以参考这篇大数据时代的技术hive：hive介绍，实际的一些操作可以看这篇笔记：新手的Hive指南，至于还有兴趣看Hive优化方法可以看看我总结的这篇Hive性能优化上的一些总结
执行流程详细解析
Step 1：UI(user interface) 调用 executeQuery 接口，发送 HQL 查询语句给 DriverStep 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 的返回内容。与传统数据库之间对比—From：Hive和传统数据库进行比较
比较项SQLHiveQLANSI SQL支持不完全支持更新UPDATE\INSERT\DELETEinsert OVERWRITE\INTO TABLE事务支持不支持模式写模式读模式数据保存块设备、本地文件系统HDFS延时低高多表插入不支持支持子查询完全支持只能用在From子句中视图UpdatableRead-only可扩展性低高数据规模小大………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等引擎。
SparkSQL的两个组件 SQLContext：Spark SQL提供SQLContext封装Spark中的所有关系型功能。可以用之前的示例中的现有SparkContext创建SQLContext。DataFrame：DataFrame是一个分布式的，按照命名列的形式组织的数据集合。DataFrame基于R语言中的data frame概念，与关系型数据库中的数据库表类似。通过调用将DataFrame的内容作为行RDD（RDD of Rows）返回的rdd方法，可以将DataFrame转换成RDD。可以通过如下数据源创建DataFrame：已有的RDD、结构化数据文件、JSON数据集、Hive表、外部数据库。类似于关系型数据库，SparkSQL也是语句也是由Projection（a1，a2，a3）、Data Source（tableA）、Filter（condition）组成，分别对应sql查询过程中的Result、Data Source、Operation，也就是说SQL语句按Operation–>Data Source–>Result的次序来描述的。
当执行SparkSQL语句的顺序
对读入的SQL语句进行解析（Parse），分辨出SQL语句中哪些词是关键词（如SELECT、FROM、WHERE），哪些是表达式、哪些是Projection、哪些是Data Source等，从而判断SQL语句是否规范； Projection：简单说就是select选择的列的集合，参考：SQL Projection 将SQL语句和数据库的数据字典（列、表、视图等等）进行绑定（Bind），如果相关的Projection、Data Source等都是存在的话，就表示这个SQL语句是可以执行的；一般的数据库会提供几个执行计划，这些计划一般都有运行统计数据，数据库会在这些计划中选择一个最优计划（Optimize）；计划执行（Execute），按Operation–>Data Source–>Result的次序来进行的，在执行过程有时候甚至不需要读取物理表就可以返回结果，比如重新运行刚运行过的SQL语句，可能直接从数据库的缓冲池中获取返回结果。解析方式如下
From：https://www.linkedin.com/pulse/hive-spark-vs-sparksql-sumit-vyas
hive on Spark是由Cloudera发起，由Intel、MapR等公司共同参与的开源项目，其目的是把Spark作为Hive的一个计算引擎，将Hive的查询作为Spark的任务提交到Spark集群上进行计算。通过该项目，可以提高Hive查询的性能，同时为已经部署了Hive或者Spark的用户提供了更加灵活的选择，从而进一步提高Hive和Spark的普及率。
在hive中使用以下语句开启；当然引擎还可以使用tez，一样的方式 hive> set hive.execution.engine=spark;
解析方式如下：
hive on spark大体与SparkSQL结构类似，只是SQL解析器不同，但是计算引擎都是spark！（比如sparksql的解析过程中多了很多优化，cbo这类的）敲黑板！这才是重点！
我们来看下，在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")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的比较
具体实验参见：Spark SQL & Spark Hive编程开发， 并和Hive执行效率对比
结论：sparksql和hive on spark时间差不多，但都比hive on mapreduce快很多，官方数据认为spark会被传统mapreduce快10-100倍
对比试验详见：https://hivevssparksql.wordpress.com/
