Hive查询跟普通的Hadoop MapReduce相比没有大的区别，都是对原始数据的暴力扫描，如果能够像数据库那样建立索引，数据扫描的速度将会大幅度提升。
索引是标准的数据库技术，Hive 0.7版本之后支持索引。Hive索引采用的不是'one size fites all'的索引实现方式，而是提供插入式接口，并且提供一个具体的索引实现作为参考。
Hive索引具有以下特点：
1）索引 Key 冗余存储，提供基于Key的数据视图
2）存储设计以优化查询和检索性能
3）对于某些查询检索I/O，从而提高性能
4）视图上不能创建索引
hive索引机制和原理
在指定列上建立索引，会产生一张索引表（Hive的一张物理表），里面的字段包括，索引列的值、该值对应的HDFS文件路径、该值在文件中的偏移量;
在执行索引字段查询时候，首先额外生成一个MR job，根据对索引列的过滤条件，从索引表中过滤出索引列的值对应的hdfs文件路径及偏移量，输出到hdfs上的一个文件中，然后根据这些文件中的hdfs路径和偏移量，筛选原始input文件，生成新的split,作为整个job的split,这样就达到不用全表扫描的目的。
例如:
select * from t_student where name = 'zzq';
1
首先用一个job，从索引表中过滤出key = ‘zzq’的记录，将其对应的HDFS文件路径及偏移量输出到HDFS临时文件中
接下来的job中以临时文件为input，根据里面的HDFS文件路径及偏移量，生成新的split，作为查询job的map任务input
不使用索引时候，如下图所示：
table t_student的每一个split都会用一个map task去扫描，但其实只有split2中有我们想要的结果数据，map task1和map task3造成了资源浪费。
使用索引后，如下图所示：
查询提交后，先用一个MR，扫描索引表，从索引表中找出key=’xx’的记录，获取到HDFS文件名和偏移量；
接下来，直接定位到该文件中的偏移量，用一个map task即可完成查询，其最终目的就是为了减少查询时候的input size
hive索引优点
索引可以避免全表扫描和资源浪费
索引可以加快含有group by语句的查询的计算速度
缺点
从以上过程可以看出，Hive索引的使用过程比较繁琐：
每次查询时候都要先用一个job扫描索引表，如果索引列的值非常稀疏，那么索引表本身也会非常大；
索引表不会自动rebuild，如果表有数据新增或删除，那么必须手动rebuild索引表数据；
原理总结：索引表的基本包含几列：1. 源表的索引列；2. _bucketname hdfs中文件地址 3. 索引列在hdfs文件中的偏移量。原理是通过记录索引列在HDFS中的偏移量，精准获取数据，避免全表扫描。
总结
我们可以发现Hive的索引功能现在还相对较晚，提供的选项还较少。但是，索引被设计为可使用内置的可插拔的java代码来定制，用户可以扩展这个功能来满足自己的需求。 当然不是说所有的查询都会受惠于Hive索引。用户可以使用EXPLAIN语法来分析HiveQL语句是否可以使用索引来提升用户查询的性能。像RDBMS中的索引一样，需要评估索引创建的是否合理，毕竟，索引需要更多的磁盘空间，并且创建维护索引也会有一定的代价。 用户必须要权衡从索引得到的好处和代价