hive jdbc权限不够_Hive及其相关大数据组件

将介绍Hive及其相关的大数据组件。之所以引入这个章节的内容，是因为Hive是构建在Hadoop大数据平台之上，Hive数据存储依赖于HDFS, HiveSQL的执行引擎依赖于MapReduce、Spark、Tez等分布式计算引擎，Hive作业的资源调度依赖于YARN、Mesos等大数据资源调度管理组件。如果脱离Hadoop生态单聊Hive优化，那无异于隔靴搔痒，解决不了根本的性能问题。在日常工作中，开发者能够利用第三方组件去剖析系统的性能问题，即使系统不是他们实现的，也能够排查到问题的关键点。所以从优化定位问题的角度来看，我们不需要了解所有的实现细节，只需要了解每个组件运行的基本原理，以及具体应用运行时在组件内部运行的大致过程，并能够借助系统的一些监控工具和日志看懂执行过程，建立一个简单的整体数据链路和组件的全局观即可。基于上面几点考虑，本章在介绍各个组件时着眼于各个组件的基本原理介绍。与Hive相关的组件有4个部分：

Hive元数据、

资源管理和调度、

分布式文件系统

计算引擎

Hive架构

Hive依托于Hadoop大数据平台，其架构随着Hadoop版本的迭代和自身的发展也在不断地演变，但在Hadoop步入2.x版本、Hive步入1.x版本后，整体架构稳定，后续的迭代版本就没有太多重大的调整，更多的只是功能增强了。例如，Hive 2.x引入的LLAP, Hive 3.x 在2.x的基础上加大了对LLAP和Tez的支持。

下面我们就来看Hive 1.x的基本结构。

Hive 1.x版本基本结构在Hadoop 2.x版本以后，Hive所有运行的任务都是交由YARN来统一管理。

如图4.1所示

为YARN和Hive的协作关系。

图4.1 Hive作业的工作流程

从图4.1可以知道，客户端提交SQL作业到HiveServer2, HiveServer2会根据用户提交的SQL 作业及数据库中现有的元数据信息生成一份可供计算引擎执行的计划。

每个执行计划对应若干MapReduce作业，Hive会将所有的MapReduce作业都一一提交到YARN中，由YARN去负责创建MapReduce作业对应的子任务任务，并协调它们的运行。YARN创建的子任务会与HDFS进行交互，获取计算所需的数据，计算完成后将最终的结果写入HDFS或者本地。从整个Hive运行作业的过程，我们可以知道Hive自身主要包含如下3个部分：

第一部分是客户端(client)。Hive支持多种客户端的连接，包括beeline、jdbc、thrift和HCatalog。早期的Hive Command Line(CLI)由于可以直接操作HDFS存储的数据,权限控制较为困难，支持的用户数有限，已经被废弃。

第二部分是HiveServer2。替代早期的HiveServer，提供了HTTP协议的Web服务接口和RPC协议的thrift服务接口，使得Hive能够接收多种类型客户端的并发访问，并将客户端提交的SQL进行编译转化可供计算引擎执行的作业。

借助于HiveServer2, Hive可以做到更为严格的权限验证。在实际使用中需要注意HiveServre2服务Java堆大小的设置，默认情况下是50MB，在查询任务增多的情况下，容器发生内存溢出，导致服务崩溃，用户访问不了Hive。

第三部分是元数据及元数据服务。Hive的元数据记录了Hive库内对象的信息，包括表的结构信息、分区结构信息、字段信息及相关的统计信息等。

Hive元数据

Hive的元数据保存在Hive的metastore数据中，里面记录着Hive数据库、表、分区和列的一些当前状态信息，通过收集这些状态信息，可以帮助我们更好地监控Hive数据库当前的状态，提前感知可能存在的问题；可以帮助基于成本代价的SQL 查询优化，做更为正确的自动优化操作。

扩展：在Hive 3.0以后，可以在Hive的sys数据库中找到元数据表。

Hive的元数据主要分为5个大部分：

数据库相关的元数据、

表相关的元数据、

分区相关的元数据、

文件存储相关的元数据及其他。

1．数据库的元数据

数据库的元数据及这些元数据之间的关系如图4.2所示。

图4.2 数据库相关的元数据

DBS：描述Hive中所有的数据库库名、存储地址(用字段DB_LOCATION_URI表示)、拥有者和拥有者类型。DBS表的内容

如图4.3所示。