一、 Hive的历史价值
1， 大数据因Hadoop而知名，而Hadoop又因Hive而实用。Hive是Hadoop上的Killer Application，Hive是Hadoop上的数据仓库，同时Hive兼具有数据仓库中的存储和查询引擎。而Spark SQL是一个更加出色和高级的查询引擎，并不提供存储功能。所以Spark SQL无法取代Hive，在现在企业级应用中Spark SQL+Hive成为了业界使用的大数据最为高效和流行的趋势。
2，Hive是Facebook推出的，主要是为了让不懂java的工程师也能通过SQL来驾驭Hadoop集群进行数据分布式数据的多维度分析，甚至你可以只通过Web界面来直接操作Hive；
3，Hive的核心是把自己的SQL语言即HQL翻译成MapReduce代码，然后交给Hadoop集群执行，也就是说Hive本身是一个单机版本的软件！！！
4， 由于是用过写SQL来完成业务需求的，所以相对于编程MapReduce而言，非常的简单和灵活，能够非常轻易的满足业务的需要和多变的场景；
5， Hive几乎存在于一切使用大数据的公司中！
二、 Hive的架构设计
1，Hive的架构图如下：
2， 可以通过很多的方式连接到Hive中，Hive安装时只需在一台机器上安装。
3, Metastore（Hive中有哪些数据库，哪些表，表中有哪些列及其数据类型）；Hive的元数据，默认存储在Derby中，但是Derby只支持单用户，所以一般情况下使用MySQL数据库来存储Hive的元数据。
4， Hive要操作的数据本身由Hive的配置文件来决定，生产环境下该数据位于HDFS上（其实也就是HDFS上的普通文件，只不过安装Hive的方式进行组织）；
5，从Hive的角度看，数据就是一张张表，我们操作就是基于SQL的多维度查询Table 。
6，人们一直努力用Hive来取代传统的数据仓库（伸缩性，扩展性），但是以失败告终！因为Hive太慢了。所以业界目前趋势上的黄金组合是使用Hive（数据仓库的存储引擎）+Spark SQL(分布式分析计算查询引擎)
7，HQL会被Hive解释优化，并生成查询计划，一般情况下而言查询计划会被转化成MapReduce任务。但是型如select * from table 不会转化为MapReduce任务。
8，Hive没有索引（类似于传统数据库中的索引）！！
索引是标准的数据库技术，hive 0.7版本之后支持索引。Hive提供有限的索引功能，这不像传统的关系型数据库那样有“键(key)”的概念，用户可以在某些列上创建索引来加速某些操作，给一个表创建的索引数据被保存在另外的表中。 Hive的索引功能现在还相对较晚，提供的选项还较少。但是，索引被设计为可使用内置的可插拔的java代码来定制，用户可以扩展这个功能来满足自己的需求。 当然不是说有的查询都会受惠于Hive索引。用户可以使用EXPLAIN语法来分析HiveQL语句是否可以使用索引来提升用户查询的性能。像RDBMS中的索引一样，需要评估索引创建的是否合理，毕竟，索引需要更多的磁盘空间，并且创建维护索引也会有一定的代价。 用户必须要权衡从索引得到的好处和代价。
本文出自 “叮咚” 博客，请务必保留此出处http://lqding.blog.51cto.com/9123978/1750882