Hive-cli与Beeline的区别

hive-cli 是hive连接hivesever的命令行工具，从hive出生就一直存在，但随着hive功能的增强、bug的修复、版本升级，hive-cli结构的局限性跟不上hive的发展，如果强行更改就不能满足向下兼容，就出现了全新的beeline命令行结构，即就是hive-cli能做的事beeline都能做，而beeline能做的事hive-cli不一定能做。

Hive-cli的特点

1、Hive-cli是通过MetaServer访问元数据的

2、CliDriver是SQL本地直接编译，然后访问MetaStore，提交作业，是重客户端。

3、运行hive会自动运行一个RunJar进程，进程是提供thrift的RPC的，就是metastore服务。

Beeline的特点

1、beeline是一个纯粹的客户端，用来连接hiverserver2。

2、BeeLine是把SQL提交给HiveServer2，由HiveServer2编译，然后访问MetaStore，提交作业，是轻客户端。

3、多用户、安全、可以实现其权限控制。

区别

beeline有权限控制而hivecli没有，因为hivecli读取元数据绕过了HiveServer2直接从metaserver访问元数据，而beeline通过HiveServer2的管控，实现其多用户的权限控制。

Hive的授权机制介绍

Hive的授权机制

当前hive支持多种授权模型以满足不同的应用场景

下面是2种常见的Hive应用场景

1.hive作为一个表存储层，作为Hive HCatalog API 的用户就是这种场景，如Apache Pig，MapReduce和一些强大的并行处理数据库(Cloudera Impala, Facebook Presto, Spark SQL等等)。这种场景中，hive为在存储中(通常是HDFS)的文件提供了一个表抽象和元数据服务。这些用户能够直接访问HDFS和metastore服务(该服务提供了一个访问元数据的API)。HDFS的访问权限控制是通过HDFS的权限管理机制实现的。而元数据的访问控制则需要由hive的配置来完成。

2.Hive作为一个SQL查询引擎。这是hive最常用的场景。这是SQL用户和BI工具的'Hive view'，这种场景又可以分为如下两类：

a.Hive 命令行用户：这类用户可以直接访问HDFS和Hive metastore服务，这类场景类似于上面第一种场景。

需要说明的是，Hive CLI这种方式已经被官方舍弃，由beeline取代。

b.ODBC/JDBC 和其他 HiveServer2 API 用户(比如beeline)，这类用户对于所有数据和元数据的访问都是通过HiveServer2来完成的。他们不会直接访问HDFS或者metastore服务。

授权模型介绍

1. Metastore server中基于存储的授权模型(Storage Based Authorization in the Metastore Server)

在上面的应用场景1和2a中，用户可以直接访问数据。Hive的配置将无法控制对数据的访问，HDFS的权限对表存储的访问就是一个事实的来源(不太懂什么意思)。通过启用Storage Based Authorization in the Metastore Server,就可以使用一个单一的来源并拥有一个一致性的数据和元数据授权策略模型。为了控制在元数据对象如数据库、表、分区上对元数据的访问，当你去访问这些对象在文件系统中对应的目录时将会检查权限。通过确保查询是由最终用户(需要将配置项hive.server2.enable.doAs设置为true，这也是其默认值)来运行，可以保护通过HiveServer2(上面的场景2b)进行的访问。

注意，通过使用HDFS ACL，在对文件系统的访问控制上我们会有很大的灵活性，相应的在Storage Based Authorization模型中也就会提供更多的灵活性了。该特性已经在Hive0.14中可用了。

2. HiveServer2中基于SQL标准的授权模型(SQL Standards Based Authorization in HiveServer2)

尽管Storage Based Authorization模型在数据库、表和分区层面可以提供访问控制，但是还无法在更精细的层面如列和视图提供权限控制，因为它的控制是通过对文件系统的目录和文件的访问控制来实现的，一个良好的授权访问控制模型的必要条件就是它能够提供用户需要访问的列和行的权限控制。而文件系统级别的访问控制只能提供对整个文件的控制，HiveServer2满足这个条件，因为它有一个理解(通过使用SQL)行和列的API，它能够提供你的SQL查询所需要的对列和行访问的最小权限。

SQL Standards Based Authorization(在Hive0.13中引入，HIVE-5837)的使用能够提供细粒度的访问控制，它是基于SQL标准来进行授权的，使用类似于 grant/revoke 的语句来控制访问。通过HiveServer2的配置可以使用这个授权模型。

注意，对于上面提到的2a场景(HIVE CLI)，SQL Standards Based Authorization是无法使用的。因为Hive CLI是直接访问HDFS的，用户可以非常容易越过SQL Standards Based Authorization的检查，甚至完全可以禁用它。禁用此功能可避免给用户带来错误的安全性。因此在生产环境中，为了提高整个环境的安全性，我们应该尽量使用HiveServer2服务，同时也不要给用户提供Hive CLI客户端工具。

3. 使用Apache Ranger & Sentry 进行授权

Apache Ranger和Apache Sentry都是Apache中的项目，他们通过使用hive提供的插件进行授权管理。

通过使用他们可以获得更多的功能，比如，使用Ranger可以通过web的方式查看和管理策略，查看审计信息，基于运行时的特性可以动态的控制行和列的访问控制(包括column masking)。

4.Hive旧的默认的授权模型(传统模型)

Hive Old Default Authorization(Hive2.0.0之前的默认模型)是hive早期版本中使用的一种授权模型。这种授权模型并不能完全的控制访问，有很多没有解决的安全漏洞。比如，没有定义授予用户权限所需的权限，任何用户都能够给他们自己授权来访问一个表或者数据库。

这个模型类似于SQL standards based authorization模型，他们都使用了grant/revoke语句进行访问控制。但是它的控制策略是不同于 SQL standards based authorization的，而且他们互相也不兼容。这种模型是支持Hive CLI的，但是对于Hive CLI这不是一种安全的授权模型