其他分享
首页 > 其他分享> > Chapter6 数据仓库Hive

Chapter6 数据仓库Hive

作者：互联网

6.1数据仓库概念

6.1.1什么是数据仓库

数据仓库：数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。

数据仓库的目的：支持企业内部的商业分析和决策，让企业可以基于数据仓库的分析结果作出相关的经营决策。

数据仓库的典型体系结构：
在这里插入图片描述
数据仓库的数据都来自数据源，数据源中的数据需要经过抽取、转换、加载（ETL过程），再进入数据仓库。接着可以通过OLAP服务器和数据挖掘引擎，对上层应用提供服务，从而提供各种类型的服务。

数据仓库是相对稳定的，仓库中的数据不会频繁变化甚至根本不会变化。大部分情况下，数据源中的数据经过ETL过程进入数据仓库后就不会再发生变更，基本保留了历史上所有时刻的状态（大量历史数据可以被用于多维数据OLAP分析，找出企业经营管理规律）。但传统数据库只能存储在某个时刻的状态，原来的历史信息不保留。

传统数据仓库面临的挑战：
1.无法满足快速增长的海量数据存储需求。
2.无法有效处理不同类型的数据。
基于传统数据库构建，只能存储结构化数据。
3.计算和处理能力不足。
没有办法横向扩展，纵向扩展的能力也是有限的。

6.2Hive简介

6.2.1概述

Hive是一个构建于Hadoop顶层的数据仓库工具，支持大规模数据存储分析。由于Hadoop是大数据处理架构、分布式处理架构，具有非常好的水平可扩展性，所以构建在其上的Hive也有很好的水平可扩展性。

虽然Hive是数据仓库工具，但是它和传统的数据仓库是有区别的。
传统的数据仓库即是数据存储产品也是数据分析处理产品，能同时支持数据的存储和处理分析。然而，Hive本身并不支持数据存储和处理，应该将它看作一个面向用户的接口，相当于给用户提供了一种编程语言。让用户可以用类似SQL的编程语言去编写分析需求。

Hive架构在底层的Hadoop核心组件之上，而Hadoop平台有支持大规模数据存储的组件HDFS、支持大规模数据处理的组件MapReduce。Hive正是借助于这两个组件完成数据的存储和处理。具体来说，Hive依赖分布式文件系统HDFS存储数据、依赖分布式并行计算模型MapReduce处理分析数据。

Hive为用户提供了一种非常简单的查询语言，和SQL非常类似（借鉴SQL语言），即新的查询语言HiveQL。
用户可以通过HiveQL这种语句，执行具体的MapReduce任务。
并且，Hive支持类似SQL的接口，很容易进行移植。可以很容易的把原来构建在关系数据库上的数据仓库应用程序移植到Hadoop平台上。
因此，Hive是一个可以提供有效合理直观组织和使用数据的分析工具。

Hive两个方面的特性
1.采用批处理方式处理海量数据
Hive本身并不负责数据的处理分析，会把用户提交的HiveQL语句转换成一系列的MapReduce任务执行。而MapReduce是典型的面相批处理的框架。
数据仓库存储的是静态数据，不会发生频繁变化甚至根本不会变化。所以对静态数据的分析适合采用批处理方式，不需要快速响应给出结果。数据仓库的这种静态特性很适合使用Hive。
2.Hive提供了一系列对数据进行提取、转换，加载（ETL）的工具
可以存储、查询和分析存储在Hadoop中的大规模数据，这些工具可以很好的满足数据仓库的各种应用场景。

6.2.2Hive和Hadoop生态系统中各组件关系

Hive建立在Hadoop平台之上，依赖HDFS存储数据，依赖MapReduce处理数据。
在这里插入图片描述
Pig是一种面向流式处理的语言，leisiyuSQL语句，可以通过编写Pig Latin脚本语言以使用数据仓库和数据分析的工作，无需编写复杂代码。在某种程度上，Pig和Hive提供的数据仓库的功能是类似的，也是让用户输入类似SQL的语句，也会把语句转换为MapReduce任务运行。但是二者也存在区别，相对于Hive来说，它是一种轻量级分析工具，Pig比较适合做实时性交互分析，不适合做大规模数据批处理。二者在发展过程中应用场景不同，Pig主要用于数据仓库的ETL环节，而Hive主要用于数据仓库海量数据的批处理分析。

在Hadoop生态系统中，HBase是一款支持实时性交互的数据库产品，弥补了HSFS的缺陷（HDFS只允许追加不允许修改，不支持随机读写），这种数据读写可以利用HBase实现。HBase和Hive是一种互补的关系，Hive的时延较高，因此如果需要实时性查询，可以通过HBase实现。

6.2.3Hive和传统数据库对比

Hive在很多方面和传统数据库类似，但是Hice底层依赖的是Hadoop两大核心组件（HDFS和MapReduce），因此在很多方面又有别于传统数据库。
Hive和传统数据库在不同项目中的对比表：
在这里插入图片描述

6.2.4Hive在企业中的部署和应用

Hive在企业大数据分析平台中的应用：
在这里插入图片描述
Hive在Facebook公司的应用
Facebook是Hive数据仓库的开发者，这是由于基于Oracle的数据仓库已经无法满足激增的业务需求，所以Facebook公司开发了数据仓库工具Hive，并在企业内部进行了大量部署。
Web服务器每天会产生大量的日志流，通过订阅（Scribe）服务器进行收集整理，存储到网络文件服务器（Filers）。Filers会将海量日志保存在分布式文件系统HDFS上。同时，Facebook内部的许多关系型数据库集群，例如MYSQL，用于存储维度数据；这些数据也要被导入Hadoop平台，并存储到HDFS中。各种数据都进入到HDFS之后，Hive就会为这些数据构建起一个数据仓库，用户即可进行各种操作，得到的分析结果可以导入MYSQL，也可以导入Oracle RAC。
在这里插入图片描述

6.2.5Hive系统架构

在系统架构中，包含三个非常核心的模块：用户接口模块、驱动模块（Driver）、元数据存储模块（Metastore）。
在这里插入图片描述
Hive对外访问接口：

  1. CLI：一种命令行工具
  2. HWI：Hive Web Interface，是Hive的Web接口。
  3. JDBC和ODBC：开放数据库连接接口，很多应用开发都支持。
  4. Thrift Server：基于Thrift架构开发的接口，允许外界通过这个接口实现对Hive仓库的RPC调用。

驱动模块（Driver）：
包含编译器、优化器、执行器。
负责把HiveQL语句转换成一系列MapReduce作业。

元数据存储模块（Metastore）：
是一个独立的关系型数据库。
存储数据仓库的各种元数据，比如表、表中的列、列的名称、分区信息。
通过MySQL数据库存储Hive元数据。

Karmasphere、Hue、Qubole也可以访问Hive数据仓库。
其中，Qubole直接作为一种服务提供给用户，不需要在本地部署数据仓库，直接提供亚马逊的AWS云平台即可远程使用数据仓库。整个数据仓库集群管理都是亚马逊完成。

6.2.6Hive HA基本原理

Hive HA：全称为Hive High Availability，高可用性Hive解决方案。
在实际应用中，Hive会表现出很多不稳定性，比如端口调用没有响应、进程丢失等。Hive HA就是对这种不稳定性的解决方案。
在这里插入图片描述
外部访问先访问HA Proxy，然后HA Proxy依次对底层的各个示例进行询问示例是否可用，执行逻辑可用性测试，如果通过测试就将用户请求转发给这个可用的示例，否则将示例加入黑名单。每隔一定周期，HA Proxy会对列入黑名单的示例进行统一处理（进行重启，重启成功的重新放回资源池）。

6.3SQL语句转为MapReduce作业

Hive本身不做具体的数据处理和存储，而是把SQL语句转换成相关的MapReduce作业。

6.3.1SQL语句转为MapReduce作业的基本原理

连接：怎么能用MapReduce来实现数据库的连接操作？
实例1. join的实现原理
user表和order表具有公共字段uid，因此两表具有连接条件。
首先，需要用户编写一个Map处理逻辑，将关系数据库的表输入到Map处理逻辑中，对于输入的每一行记录通过Map进行转换，生成一系列键值对。比如User表的第一行记录经过Map处理后会输出键值对，key为uid的值，value是一个二元组<1,Lily>，这个二元组中的1表示键值对所属的表，是表User的标记位。同理，2是表Score的标记位。
通过Map函数，可以将输入的User表和Order表都转换成键值对，通过Shuffle的过程把这些键值对进行分区、排序，分别发送给不同的Reduce。在图中假设，把所有key为1的键值对都分配给第一个Reduce任务，把所有key为2的键值对都分配给第二个Reduce任务。
键值对进行Reduce操作的前提是他们的key相等且来自不同表。
在这里插入图片描述
实例2. group by的实现原理
假设下图中是来自Score表的两个不同片段，现在想要进行group by操作，把表Score的不同片段按照rank和level的组合值进行合并，计算不同rank和level的组合值分别有几条记录，比如rank为A且level为1的记录条数。该操作对应的SQL语句为：

select rank,level,count(*) as value
from score
group by rank,level

若想用MapReduce实现，首先把表输入到Map函数中做用户逻辑的处理，处理后输出键值对，键值对的key为rank和level的组合，value为计算出的这种组合的记录条数。
经过Map函数映射后，得到键值对列表。接着对这些键值对进行Shuffle操作，进行分区、排序，然后分配给不同的Reduce任务处理。
在这里插入图片描述

6.3.2Hive中SQL查询转换成MapReduce作业的过程

当用户向Hive输入一段命令或查询时，Hive需要与Hadoop交互来完成该操作：
1.驱动模块接收该命令或查询编译器
2.对该命令或查询进行解析编译
3.由优化器对该命令或查询进行优化计算
4.该命令或查询通过执行器进行执行

具体过程可以分为如下七个步骤：
1.由Hive驱动模块中的编译器对用户输入的SQL语言进行词法和语法解析，将SQL语句转化成抽象语法树的形式。
2.抽象语法树的结构仍然很复杂，不方便直接翻译为MapReduce算法程序，因此需要把抽象语法树转化为查询块。
3.把查询块转换成逻辑查询计划，里面包含了许多逻辑操作符。
4.重写逻辑操作计划，进行优化合并多余操作，减少MapReduce任务数量。
5.将逻辑操作符转换成需要执行的具体MapReduce任务。
6.对生成的MapReduce任务进行优化生成最终的MapReduce任务执行计划。
7.由Hive驱动模块中的执行器对最终的MapReduce任务进行执行输出。
示意图如下：
在这里插入图片描述
需要注意的是：
当启动MapReduce程序时，Hive本身是不会生成MapReduce程序的。
需要通过一个表示"Job执行计划"的XML文件驱动执行内置的、原生的Mapper和Reducer模块。Hive本身并不生成MapReduce算法程序。
Hive通过和JobTracker通信来初始化MapReduce任务（JobTracker是MapReduce的管家），不必直接部署在JobTracker所在的管理节点上执行。
通常在大型集群上，会有专门的网关机来部署Hive工具。（网关机会和远程节点上的JobTracker进行通信完成任务）
数据文件通常存储在HDFS上，HDFS由名称节点管理。

6.4Impala

6.4.1Impala简介

Hive建立在Hadoop平台上，它依赖底层的MapReduce和HDFS，所以延迟比较高。针对这个问题，设计了Impala，也用于做数据仓库分析，但是性能比Hive高3~30倍。
有人认为，Impala未来会称为最流行的实时性交互查询工具。

Impala是由Cloudera公司开发的新型查询系统，允许通过SQL语句查询底层数据，可以查询PB级别以上的大数据，能查询存储在Hadoop的HDFS中，或者HBase中的数据。
Impala的运行需要依赖于Hive的元数据。
Impala最初是参考Google的Dremel系统（专门做实时性交互查询的）进行设计的。
与Hive不同的是，Hive要将SQL语句转换为底层的一系列MapReduce任务执行，而Impala采用了与商用并行关系数据库类似的分布式查询引擎，可以直接与HDFS和HBase进行交互查询，查询实时性比Hive高。

如下图所示，Impala和Hive都是构建在底层的HDFS和HBase之上的，Impala和Hive都不是自身存储数据。并且，Impala和Hive采用相同的SQL语法、ODBC驱动程序和用户接口。
在这里插入图片描述

6.4.2Impala系统架构

图中虚线部分，表示属于Impala系统组件。实线部分表示Impala并不是单独部署的，和Hadoop平台的其他组件部署在同一个集群上面。
在这里插入图片描述
Impala和Hive、HDFS、HBase等工具是统一部署在一个Hadoop平台上的。

Impala的三大组件：

  1. Impalad
    负责具体的相关查询任务。
    包含着三个模块：Query Planner（查询计划器）、Query Coordinator（查询协调器）、Query Exec Engine（查询执行引擎）。
    负责协调客户端提交的查询的执行。
    与HDFS的数据节点（HDFS DataNode）运行在同一节点上，以便就近处理数据。
    给其他Impalad分配任务，以及收集其他Impalad的执行结果进行汇总。（大规模数据集分布存储在不同的数据节点上，运行时要进行分布式查询，每个子查询查询不同数据节点上的数据，这些子查询由在不同数据节点上的Impalad执行，Impalad负责执行各自的子查询。）
    Impalad也会执行其他Impalad给其分配的任务（其他查询发起后，也会有另外的Impalad作为管家，把分片分成多个子查询给Impalad做），对本地HDFS和HBase里的部分数据进行操作。

  2. State Store
    负责元数据管理和状态信息维护。
    每个查询提交后，系统会为其创建一个state store进程。由于不同节点上有多个Impalad进程，分别执行各自的任务，因此需要state store跟踪执行情况、健康状态信息等。
    因此，state store要负责收集分布在集群中各个Impalad进程的资源信息用于查询调度。

  3. CLI
    用户访问接口。
    CLI是给用户提供查询使用的命令行工具，同时提供了Hue、JDBC、ODBC的使用接口。

说明：
Impala的元数据是直接存储在Hive中的，它借助Hive来存储Impala的元数据。
Impala采用与Hive相同的元数据、相同的SQL语法、相同的ODBC驱动程序和用户接口，使得在一个Hadoop平台上可以统一部署Hive和Impala等分析工具，实现在一个平台什么可以同时满足批处理和实时查询。

6.4.3Impala查询执行过程

Impala执行查询的过程如下所示：
在这里插入图片描述
具体的查询步骤为：
0.用户的一个查询提交之前，Impala先创建一个负责协调客户端提交的查询的Impalad进程。该进程会向Impala State Store提交注册订阅信息，State Store会创建一个statestored进程，statestored进程通过创建多个线程来处理Impalad的注册订阅信息。
1.用户通过CLI客户端提交一个查询到Impalad进程，Impalad的Query Planner对SQL语句进行解析，生成解析树，Planner把这个解析树变成若干PlanFragment，发送到Query Coordinator（协调不同Impalad进行子查询、收集结果等）。
2.Coordinator通过从MySQL元数据库中获取元数据，从HDFS的名称节点中获取数据地址，以得到存储这个查询相关数据的所有数据节点。
3.Coordinator初始化相应Impalad上的任务执行，即把查询任务分配给所有存储这个查询相关数据的数据节点。
4.Query Executor通过流式交换中间输出，并由Query Coordinator汇聚来自各个Impalad的结果。
5.Coordinator把汇总后的结果返回给CLI客户端。

6.4.4Impala与Hive的比较

对比示意图：
在这里插入图片描述
Impala与Hive的不同点：

  1. Hive适合于长时间的批处理查询分析，而Impala适合于实时交互式SQL查询。（Hive架构在MapReduce上，需要将SQL查询转换成MapReduce任务。而MapReduce是面向批处理的，延迟高。而Impala直接架构在底层上，性能高。）
  2. Hive依赖于MapReduce计算框架，Impala把执行计划表现为一棵完整的执行计划树，直接分发执行计划到各个Impala执行查询。
  3. Hive在执行过程中，如果内存放不下所有数据则会使用外存，以确保查询能顺利执行完毕。而Impala在遇到内存放不下数据时，不会利用外存，因此Impala目前处理查询时会受到一定的限制。

Impala与Hive的相同点：

  1. Hive与Impala使用相同的存储数据池，都支持把数据存储在HDFS和HBase中。
  2. Hive与Impala使用相同的元数据。
  3. Hive与Impala对SQL的解释处理比较相似，都是通过词法分析生成执行计划。

总结：
Impala的设计目的不在于替换现有的MapReduce工具。（为了弥补Hive实时性不高的缺陷）
把Hive与Impala配合使用效果最佳。
可以先使用Hive进行数据转换处理，之后再使用Impala在Hive处理后的结果数据集上进行快速的数据分析。

标签：数据,Chapter6,数据仓库,MapReduce,Hive,查询,Impala
来源： https://blog.csdn.net/weixin_45832571/article/details/120689791