一、 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