Hive数据仓库简介_hive数据库

Hive数据仓库简介

Hive起源于Facebook，Facebook公司有着大量的日志数据，而Hadoop是实现了MapReduce模式开源的分布式并行计算的框架，可轻松处理大规模数据。然而MapReduce程序对熟悉Java语言的工程师来说容易开发，但对于其他语言使用者则难度较大。因此Facebook开发团队想设计一种使用SQL语言对日志数据查询分析的工具，而Hive就诞生于此，只要懂SQL语言，就能够胜任大数据分析方面的工作，还节省了开发人员的学习成本。

一、数据仓库简介

1. 什么是数据仓库

数据仓库是一个面向主题的、集成的、随时间变化的，但信息本身相对稳定的数据集合，它用于支持企业或组织的决策分析处理，这里对数据仓库的定义，指出了数据仓库的三个特点。

（1）数据仓库是面向主题的。

操作型数据库的数据组织是面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织，这里说的“主题”是一个抽象的概念，它指的是用户使用数据仓库进行决策时关心的重点方面，一个主题通常与多个操作型信息系统相关。例如，商品的推荐系统就是基于数据仓库设计的，商品的信息就是数据仓库所面向的主题。

（2）数据仓库是随时间变化的。

数据仓库是不同时间的数据集合，它所拥有的信息并不只是反映企业当前的运营状态，而是记录了从过去某一时间点到当前各个阶段的信息。可以这么说，数据仓库中的数据保存时限要能满足进行决策分析的需要(如过去的5~10年），而且数据仓库中的数据都要标明该数据的历史时期。

（3）数据仓库相对稳定。

数据仓库是不可更新的。因为数据仓库主要目的是为决策分析提供数据，所涉及的操作主要是数据的查询，一旦某个数据存入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，修改和删除操作很少，通常只需要定期的加载、刷新来更新数据。

多学一招：OLTP和OLAP

数据处理大致可以分为两类，分别是联机事务处理（OLTP）和联机分析处理（OLAP)，其中：

(1)OLTP是传统关系数据库的主要应用，主要针对的是基本的日常事务处理，例如，银行转账。

(2）OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果，例如，商品的推荐系统。

接下来，通过一张表来比较OLTP和OLAP，具体如表所示。

对比项目	OLTP	OLAP
用户	操作人员、底层管理人员	决策人员、高级管理人员
功能	日常操作处理	分析决策
DB设计	基于ER模型，面向应用	星型/雪花型模型，面向主题
DB规模	GB至TB	≥TB
数据	最新的、细节的、二维的、分立的	历史的、聚集的、多维的、集成的
存储规模	读/写数条（甚至数百条）记录	读上百万条（甚至上亿条）记录
操作频度	非常频繁（以秒计）	比较稀松（以小时甚至以周计）
工作单元	严格的事务	复杂的查询
用户数	数百个至数千万个	数个至数百个
度量	事务吞吐量	查询吞吐量、响应时间

2. 数据仓库的结构

数据仓库的结构是由数据源、数据存储及管理、OLAP服务器和前端工具四个部分组成。

2.1 数据源

数据源是数据仓库的基础，即系统的数据来源，通常包含企业的各种内部信息和外部信息。

内部信息，例如存在数据操作数据库中的各种业务数据和自动化系统中包含的各类文档数据；外部信息，例如各类法律法规，市场信息、竞争对手的信息以及外部统计数据和其他相关文档等。

2.2 数据存储与管理

数据存储及管理是整个数据仓库的核心。数据仓库的组织管理方式决定了它有别于传统数据库，同时也决定了对外部数据的表现形式。针对系统现有的数据，进行抽取、清理并有效集成，按照主题进行组织。数据仓库按照数据的覆盖范围可以划分为企业级数据仓库和部门级数据仓库，也就是所谓的数据集市。数据集市可以理解为是一个小型的部门或者工作组级别的数据仓库。

2.3 OLAP服务器

OLAP服务器对需要分析的数据按照多维数据模型进行重组，以支持用户随时进行多角度、多层次的分析，并发现数据规律和趋势。

2.4 前端工具

前端工具主要包含各种数据分析工具、报表工具、查询工具、数据挖掘工具以及各种基于数据仓库或数据集市开发的应用。

3. 数据仓库的数据模型

在数据仓库建设中，一般会围绕着星状模型和雪花模型来设计数据模型。下面先来介绍这两种模型的概念。

3.1 星状模型

在数据仓库建模中，星状模型是维度建模中的一种选择方式。星状模型是由一个事实表和一组维度表组合而成，并且以事实表为中心，所有的维度表直接与事实表相连。

在上图中，所有的维度表都直接连接到事实表上，维度表的主键放置在事实表中，作为事实表与维度表连接的外键，因此，维度表和事实表是有关联的，然而，维度表与维度表并没有直接相连，因此，维度表之间是并没有关联的。

3.2 雪花模型

雪花模型也是维度建模中的另一种选择，它是对星型模型的扩展。

雪花模型是当有一个或多个维表没有直接连到事实表上，而是通过其他维表连到事实表上，其图解像多个雪花连在一起，故称雪花模型。雪花模型是对星型模型的扩展，原有的各维表可被扩展为小的事实表，形成一些局部的 "层次 " 区域，被分解的表都连主维度表而不是事实表。

多学一招：什么是事实表和维度表

1.事实表

每个数据仓库都包含一个或者多个事实数据表，事实表是对分析主题的度量，它包含了与各维度表相关联的外键，并通过连接(Join)方式与维度表关联。

事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。例如，现存在一张订单事实表，其字段Prod_id(商品id)可以关联商品维度表、TimeKey(订单时间）可以关联时间维度表等。

2.维度表

维度表可以看作用户分析数据的窗口，维度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息。

维度表包含帮助汇总数据的特性的层次结构，维度是对数据进行分析时特有的一个角度，站在不同角度看待问题,会有不同的结果。例如，当分析产品销售情况时，可以选择按照商品类别、商品区域进行分析，此时就构成一个类别、区域的维度。维度表信息较为固定，且数据量小，维度表中的列字段可以将信息分为不同层次的结构级。

二、Hive简介

1. 什么是Hive

Hive是建立在Hadoop文件系统上的数据仓库，它提供了一系列工具，能够对存储在HDFS中的数据进行数据提取、转换和加载（ETL），这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的工具。Hive定义简单的类SQL查询语言（即HQL），可以将结构化的数据文件映射为一张数据表，允许熟悉SQL的用户查询数据，允许熟悉MapReduce的开发者开发mapper和reducer来处理复杂的分析工作，与MapReduce相比较，Hive更具有优势。

2. Hive的发展历程

• 2007 年：Facebook 开始研究 Hadoop 平台，为了使更多人能够使用 Hadoop 分布式文件系统和 MapReduce 编程模型来处理大数据，他们创建了一个 SQL 类似的接口，用于 Hadoop 平台的数据处理。这个接口就是 Hive。
• 2008 年：Hive 成为了 Apache Hadoop 的子项目，并成为 Hadoop 生态系统中广泛使用的数据仓库工具之一。
• 2009 年：Hive 宣布支持 Amazon Elastic MapReduce 服务，并开发了对 HCatalog 的支持。Hive 0.4 版本也在这一年发布，它引入了分区表和分桶表的概念，并支持 Avro 序列化格式。
• 2010 年：Hive 0.5 版本发布，引入了 Hive Server2，支持多客户端并发查询，提高了 Hive 的性能和可扩展性。Hive 还开始支持更多的文件格式和编解码器，如 LZO。
• 2011 年：Hive 0.7 版本发布，引入了 Hive-on-Tez，将 Hive 与 Apache Tez（一种更快的数据处理引擎）集成，提高了 Hive 的性能和可扩展性。Hive 0.7 还引入了 Hive Metastore，使得元数据的管理更加方便和可扩展。
• 2012 年：Hive 0.8 版本发布，引入了 Vectorized Query Execution，一种新的查询执行引擎，提高了 Hive 的查询性能。Hive 0.8 还支持自定义聚合函数和 MapReduce 支持组合键。
• 2013 年：Hive 0.11 版本发布，引入了 Hiveserver2 的新特性，包括增强的安全机制、支持 Kerberos 和 LDAP 等多项功能。Hive 0.11 还支持语义完整的 ACID 事务处理，提供了一种更加可靠和可用性更高的数据仓库解决方案。
• 2015 年：Hive 1.2 版本发布，引入了 Hive on Spark，将 Hive 与 Apache Spark 集成，提供了更快的数据处理和更好的可扩展性。

从 2007 年至今，Hive 的开发和进化历程跟随着 Hadoop 生态系统的演变，始终致力于提供高效、可扩展、易用的数据仓库解决方案。

3. Hive的本质

Hive通过HQL语⾔进⾏数据查询，本质上是将HQL语句转化为MapReduce任务。下图展示HQL的查询过程。

• Hive中的数据存储在HDFS上
• Hive分析数据是通过MapReduce实现的
• Hive是运⾏在Yarn上的

所以Hive是运⾏在Hadoop之上的⼀种数据仓库⼯具。

4. Hive的优缺点

4.1 优点

• Hive的查询采⽤类 SQL 的HQL语⾔，提供快速开发的能⼒（简单、容易上⼿）。
• HQL可以⾃动转化成多个MapReduce任务，通过执⾏MapReduce任务达到数据操作的⽬的。避免了开发⼈员去写 MapReduce的过程，学习成本低。
• Hive 的执⾏延迟⽐较⾼，因此 Hive 常⽤于数据分析，对实时性要求不⾼的场合。
• Hive⼗分适合对数据仓库进⾏统计分析。
• Hive 优势在于处理⼤数据，对于处理⼩数据没有优势，因为 Hive 的执⾏延迟⽐较⾼。
• Hive ⽀持⽤户⾃定义函数，⽤户可以根据⾃⼰的需求来实现⾃⼰的函数。
• Hive具有良好的可申缩性、可扩展性、容错性、输⼊格式的松散耦合。

4.2 缺点

• Hive不适合⽤于联机事务处理（OLTP），也不提供实时查询功能。对实时性要求较⾼的OLAP也不适⽤。
• Hive 的 HQL 语⾔表达能⼒不⾜
  • ⽆法表达迭代式算法
  • 不擅⻓数据挖掘⼯作，由于 MapReduce 数据处理流程的限制，效率更⾼的算法⽆法实现。
•  Hive 的效率⽐较低
  • Hive ⾃动⽣成的 MapReduce 作业不够智能化，存在任务冗余及任务调度不合理情况。
  • Hive 调优⽐较困难，粒度较粗。

5. Hive系统架构

Hive是底层封装了Hadoop的数据仓库处理工具，运行在Hadoop基础上，其系统架构组成主要包含4部分，分别是用户接口、跨语言服务、底层驱动引擎及元数据存储系统。

下面针对Hive系统架构的组成部分进行讲解。

（1）用户接口：主要分为3个，分别是CLI、JDBC/ODBC和Web UI。其中，CLI即Shell终端命令行，它是最常用的方式。JDBC/ODBC是Hive的Java实现，与使用传统数据库JDBC的方式类似，Web UI指的是通过浏览器访问 Hive 。

（2）Driver

jdbc驱动程序

（3）SQL Parser解析器

将 SQL 字符串转换成抽象语法树 AST，这⼀步⼀般都⽤第三⽅⼯具库完成，⽐如antlr；对 AST 进⾏语法分析，⽐如表是否存在、字段是否存在、SQL 语义是否有误。

（4）底层的驱动引擎：主要包含编译器（Compiler），优化器（Optimizer）和执行器（Executor），他们用于完成 HQL 查询语句从词法分析、语法分析、编译、优化以及查询计划的生成，生成的查询计划储存在 HDFS 中，并在随后由MapReduce调用执行。

（5）元数据存储系统（Metastore）：Hive的元数据通常包含表名、列、分区及其相关属性，表数据所在目录的位置信息，Metastore默认存储在自带的Derby数据库中。由于Derby数据库不适合多用户操作，并且数据存储目录不固定，不方便管理，因此，通常都将元数据存储在MySQL数据库。

6. Hive工作原理

Hive建立在Hadoop系统之上，因此Hive底层工作依赖于Hadoop服务，Hive底层工作原理如下所示。

接下来，针对图中的 Hive 和 Hadoop之间的工作进程进行简单说明。

（1）UI 将执行的查询操作发送给Driver执行。

（2）Driver 借助查询编译器解析查询，检查语法和查询计划或查询需求。

（3）编译器将元数据请求发送到 Metastore。

（4）编译器将元数据作为对编译器的响应发送出去。

（5）编译器检查需求并将计划重新发送给Driver。至此，查询的解析和编译已经完成。

（6）Driver将执行计划发送给引擎执行 Job任务。

（7）执行引擎从DataNode上获取结果集，并将结果发送给 UI 和 Driver。

7. Hive数据模型

Hive中所有的数据都存储在HDFS中，它包含数据库（Database）、表（Table）、分区表（Partition）和桶表（Bucket）四种数据类型。

下面针对Hive数据模型中的数据类型进行介绍。

7.1 数据库

相当于关系数据库中的命名空间(namespace)，它的作用是将用户和数据库的应用，隔离到不同的数据库或者模式中。

7.2 表

Hive的表在逻辑上由存储的数据和描述表格数据形式的相关元数据组成。表存储的数据存放在分布式文件系统里，如HDFS。Hive中的表分为两种类型，一种叫作内部表，这种表的数据存储在 Hive数据仓库中；一种叫作外部表，这种表的数据可以存放在Hive 数据仓库外的分布式文件系统中，也可以存储在 Hive 数据仓库中。值得一提的是，Hive 数据仓库也就是HDFS中的一个目录，这个目录是Hive数据存储的默认路径，它可以在Hive的配置文件中配置，最终也会存放到元数据库中。

7.3 分区

分区的概念是根据“分区列”的值对表的数据进行粗略划分的机制，在Hive存储上的体现就是在表的主目录（Hive的表实际显示就是一个文件夹）下的一个子目录，这个子目录的名字就是定义的分区列的名字。

分区是为了加快数据查询速度设计的，例如，现在有个目志文件，文件中的每条记录都带有时间戳。如果根据时间来分区，那么同一天的数据将会被分到同一个分区中。这样的话，如果查询每一天或某几天的数据就会变得很高效，因为只需要扫描对应分区中的文件即可。

注意：分区列不是表里的某个字段，而是独立的列，根据这个列查询存储表中的数据文件。

7.4 桶表

简单来说，桶表就是把“大表”分成了“小表”。把表或者分区组织成桶表的目的主要是为了获得更高的查询效率，尤其是抽样查询更加便捷。桶表是 Hive数据模型的最小单元，数据加载到桶表时，会对字段的值进行哈希取值，然后除以桶个数得到余数进行分桶，保证每个桶中都有数据，在物理上，每个桶表就是表或分区的一个文件。

8. Hive与数据库的⽐较

Hive虽然采⽤了类似SQL的查询语⾔HQL（Hive Query Language）,但除了查询语⾔相似之外，不要把Hive理解成是⼀种数据库。

MySQL与Hive对比如下所示：

数据库主要应⽤于在线事务处理（OLTP）和在线分析处理（OLAP），强调的是事务的时效性与可靠性。⽽Ｈive是⼀种数据仓库技术，主要⽤应于对时效性要求不⾼的批量数据统计分析，它强调的是数据处理的吞吐率。

下⾯介绍两者之间的主要差别：

8.1 数据规模⽅⾯

​ Hive集群采⽤的是分布式计算技术，天然⽀持并⾏计算，具有很好的申缩性、可扩展性、安全性。因此可以⽀持很⼤规模的数据。
​ 数据库集群⼀般采⽤的是分库分表的技术，⽀持纵向扩展，但难以进⾏横向扩展，集群规模较⼩，所以数据库可以⽀持的数据规模较⼩，申缩性、可扩展性不好。

8.2 查询语⾔⽅⾯

​ SQL被⼴泛的应⽤于数据库技术中，有着⼴泛的⽤户群体，为了降低初学者的学习成本。因此，把Hive的查询语⾔HQL设计成了类 SQL 的查询语⾔。熟悉 SQL 的开发者可以很⽅便地使⽤ Hive。

8.3 数据更新⽅⾯

​ Hive数据仓库具有读多写少的特点。因此，Hive不建议对数据进⾏改写，所有的数据都是在加载的时候确定好的。原因是Hive是建⽴在Hadoop基础上的，⽽HDFS是只⽀持追加数据不⽀持修改数据。
​ 数据库中的数据要保证能够随时查询、新增、修改和删除。

8.4 执⾏延时⽅⾯

Hive执⾏延时⾼主要有两个原因：
（1）查询⼀般不使⽤索引，需要扫描整个表
（2）采⽤ MapReduce 框架。由于 MapReduce 本身具有较⾼的延迟，因此Hive也有较⾼的延迟。

数据库的执⾏延迟较低是有条件的，即数据规模较⼩，当数据规模⼤到超过数据库的处理能⼒的时候，Hive 的并⾏计算就能体现出优势。

8.5 应⽤场景⽅⾯

Hive主要应⽤于时实性要求不⾼的⼤规模数据的统计分析；数据库主要应⽤于数据规模较⼩、实时性要求较⾼的在线事务处理（OLTP）和在线分析处理（OLAP）。

8.4 执⾏延时⽅⾯

Hive执⾏延时⾼主要有两个原因：
（1）查询⼀般不使⽤索引，需要扫描整个表
（2）采⽤ MapReduce 框架。由于 MapReduce 本身具有较⾼的延迟，因此Hive也有较⾼的延迟。

数据库的执⾏延迟较低是有条件的，即数据规模较⼩，当数据规模⼤到超过数据库的处理能⼒的时候，Hive 的并⾏计算就能体现出优势。

8.5 应⽤场景⽅⾯

Hive主要应⽤于时实性要求不⾼的⼤规模数据的统计分析；数据库主要应⽤于数据规模较⼩、实时性要求较⾼的在线事务处理（OLTP）和在线分析处理（OLAP）。