5.1 Hive概述

从早期的互联网主流大爆发开始，主要的搜索引擎公司和电子商务公司就一直在跟不断增长的数据进行较量。同时，不断增长的数据所带来的价值也不言而喻，但要让蕴藏在海量数据中的价值高效地体现出来，必然涉及海量数据的计算，而传统的数据处理方式面对海量数据的挖掘计算可谓“心有余而力不足”。

因此，Hadoop生态系统应运而生，Hadoop实现了一个特别的计算模型—Map-Reduce，它可以实现分布式处理，而数据的存储依赖于Hadoop分布式文件系统（HDFS）。

不过，仍然存在一个挑战，就是用户如何从一个现有的数据基础架构转移到Hadoop上，而这个基础架构是基于传统关系型数据库和结构化查询语句（SQL）的。

对于大量的SQL用户（包括专业数据库设计师、管理员及那些使用SQL从数据仓库中抽取信息的临时用户）来说，这个问题又将如何解决呢？

Hive的出现正好可以解决这一系列问题，Hive最初是由Facebook设计的，是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的类SQL查询语言（称为HiveQL）。底层将HiveQL语句转换为MapReduce任务运行，它允许熟悉SQL的用户基于Hadoop框架分析数据。其优点是学习成本低，对于简单的统计分析，不必开发专门的MapReduce程序，直接通过HiveQL即可实现。

简单的说：

1. 设计目标：让精通SQL而Java技能较弱的数据分析师能利用Hadoop数据分析。
2. 使用率：实际开发中，80%操作使用Hive完成，20%使用MapReduce。
3. HiveQL：未严格实现SQL-92标准。
4. 本质：将HiveQL转化为一个或多个MapReduce作业并在集群上运行，但并不是所有HiveQL都会转为MapReduce作业。

上图为Hive的体系架构。

1. 用户接口。用户与Hive交互主要有3种方式：CLI、Client和WUI。CLI方式主要用于Linux平台命令行查询。WUI方式是Hive的Web界面访问方式，通过浏览器访问Hive,但是WUI由于没有多大的用处，已经在hive 2.2.0版本中移除了。Client是Hive的客户端，连接至远程服务HiveServer2。
2. 元数据存储。Hive将元数据存储在数据库中，如MySQL、Derby等，其中元数据存储依赖于Metastore DB服务。Hive中的元数据包括表名、表的列和分区及其属性、表的属性（是否为外部表）、表的数据所在目录等。
3. 解析器、编译器、优化器。完成HQL查询语句从词法分析、语法分析、编译、优化以及查询计划的生成，随后由MapReduce调用执行。
4. 数据存储。Hive中表的数据存储在HDFS中，包含表（Table）、外部表（External Table）、分区（Partition）、桶（Bucket）等数据模型，其中数据库、分区、表都对应HDFS上的某个目录，Hive表里的数据存储在表目录下面。

HiveQL执行过程：用户通过CLI、JDBC/ODBC或WUI接口提交HiveQL到Hive-Server2服务，通过解释器、编译器、优化器完成HiveQL查询语句从词法分析、语法分析、编译、优化以及查询计划的生成，将元数据存储到数据库中，执行器完成查询计划的处理，由MapReduce调用执行。

从图中也能看出Hive和Hadoop的关系，Hive构建在 Hadoop 之上

• HQL 中对查询语句的解释、优化、生成查询计划是由 Hive 完成的
• 所有的数据都是存储在 Hadoop 中
• 查询计划被转化为 MapReduce 任务，在 Hadoop 中执行（有些查询没有 MR 任务，如：select * from table）
• Hadoop和Hive都是用UTF-8编码的

Hive与关系型数据库的比对