回顾：上节课讲了hive的参数设置，hive的运行方式，hive的动态分区，分桶，lateral view这五个知识点。遗留了两个问题：
1.看一下hive的源码，现在面试中，hive的源码还从来没有被问到过。在hive这个环节不会浪费太多时间，把源码讲清楚，没有必要。
但是虽然不讲源码的详细知识点，但是会告诉你，如果拿到一个陌生框架之后，应该怎么去找源码，或者怎么去看源码。有同学把源码下载回来了一脸懵逼，连入口都找不到。今天讲一下入口该怎么找：
大部分 不管是hadoop、hive、hbase、spark，大概都是这样一个寻找流程：
如果想看源码的话，给一个建议：在看源码过程中，千万不要每一个方法都点进去！源码是别人写的，写的层次可能非常非常深，如果一层一层往里面点的话，点到最后可能看明白了，回头一想，我刚刚是从哪个地方点进来的，一脸懵逼。如果那一行里面有注释、或者看到方法名称，一些类的名称能大概猜到它是什么意思，没必要往下看了，先遗留下来，之后有时间了可以再慢慢看。
2.在hive2.x的时候已经没有hwi这个web页面了。但在1.x的时候还是有的，现在看一下。
hive --service hwi
hwi就是webUI的接口，打开浏览器：node01:9999/hwi
change user info 改变用户信息，这里写用户和组，但在hive里面没有用户这个概念，所有随便写，写什么都行。点提交authorization is complete 认证授权已经完成。
怎么写sql语句和执行过程？
create session->随便取个名称，submit
任何结果都没有，必须要把start query选择成yes，这时候在result bucket里面可以看到对应的结果。
再回来，点击list session->点manager
这时候又回到这个页面了，重新再次提交SQL语句，这时候再去查看，会发现是两遍对应的结果？
为什么？
上面是第一次查询的结果，而下面是第二次查询的结果。每次查询的时候，并不会把上一次查询的结果消失掉。而是会保留每一次执行的过程。非常不好用。
稍微看一下就完事了，无论用什么版本，这个功能基本上都不会用的，这也是为什么2.x的时候hwi被淘汰掉的原因。
虽然被淘汰掉了，但他提供了一种平台化和可视化的思路。以后所做的项目都应该叫平台
如何查看hive源码？入口在什么地方？
每次在黑窗口里执行的都是hive的脚本，所以找入口，一定要从脚本里面进行查找。
cd /opt/bigdata/hive-2.3.4/bin
ls
beeline ext hive hive-config.sh hiveserver2 hplsql metatool schematool
vi hive
366行，大部分同学都没有耐心看下去，所有从里面开始找东西，找自己想要的，第一次输入hive的时候，相当于输入了hive --service cli默认运行的是命令行的命令，有一堆参数的判断 ，如果什么都不写会默认判断为cli
只要去对应的目录里面，找cli.sh文件
cat cli.sh
hive也是用Java写的，所有只要找主类就可以了，一个main函数程序入口
执行这个run()方法，里面会有一些参数判断，告诉我应该怎么解析，哪些初始化操作，然后慢慢完成相应操作，这地方就是整个程序的入口操作，当把它启动好之后，意味着命令行已经准备好了。提交sql语句的时候，会有服务进行接收，接收完之后进行解析，转化，执行的过程。
hive视图
只要接触关系型数据库，一定会用对应视图的。用的非常非常多。
视图主要用在什么场合？有什么样的用途？在公司里怎么用的？
如果写的sql语句非常简单，只是几张表的关联，这个东西完全没必要，如果语句非常非常复杂，比如说要写一个好几十行的sql语句，这里面包含了N多个子查询，并且有很多子查询都是重复的sql语句，这时候，就必须把它定义成一个视图。这个时候直接写视图就可以了，可以减少整个sql语句的复杂度。
第二种情况，定义一个视图，把它定义成多张表join之后结果表。视图非常简单，就是一个sql语句，每次在使用视图的时候，都会把sql语句提前进行执行。把结果暂存成视图，比如有三张表，每张表里面取一个字段，把这三个字段当成一个视图，视图完成之后可以成一张中间表。用的时候直接拿视图进行运行就可以了。而不需要每次都进行一个join的代码编写。但执行的时候，一定会执行的。
hive里面也支持了对应的视图操作。
hive View视图
– 和关系型数据库中的普通视图一样，hive也支持视图
– 特点：
▪ 不支持物化视图：视图是虚拟表，虚拟表表示不是实实在在存在数据的表，物理表表示实实在在存在数据文件的，比如在数据库里看到的那些表都是物理表。视图每次在做的时候，都需要优先先执行sql语句，然后把结果当成虚拟视图。素有视图也可以被当成表。物化视图的概念：MySQL里面是不支持物化视图的，只有在Oracle里面是支持的，物化视图是什么意思？比如现在有个t1 t2 t3每次从里面取c1 c2 c3三个字段，这时候，这三个字段也要被当成一张物理表，进行一个实实在在的存储。这叫物化视图。如果把这三个表进行join操作，把这个结果也缓存了一下，这时候如果t1 t2 t3改变了，物化视图会刷新，这其实分了两种策略，一种叫uncommit，一种叫undemand，一种是只要t1 t2 t3发生改变，物化视图也跟着变，第二种是每次查询的时候才会把数据进行更新。不查询就不更新了。有这么两种方式，现在在公司企业里面，Oracle已经不像以前那么流行了。以前在阿里有一个去IOE的概念，o就表示Oracle
▪ 只能查询，不能做加载数据操作：MySQL里面定义的视图，可以往里面插入数据么？如果只是操作一张表是可以往视图里面更新数据的，但多表的时候是有问题的。但hive里面是都不可以的。
▪ 视图的创建，只是保存一份元数据，查询视图时才执行对应的子查询：视图就是一个sql语句，每次在执行的视图的时候，会优先把视图的sql语句先执行，再执行自己定义的SQL语句
▪ view定义中若包含了ORDER BY/LIMIT语句，当查询视图时也进行ORDER BY/LIMIT语句操作，view当中定义的优先级更高：每次定义的时候，视图里面的东西会优先执行，视图执行完成之后，外面的才会执行
▪ view支持迭代视图：视图里面可以嵌套视图
可以在MySQL里面查看
mysql -uroot -pok
mysql> use hive_remote
select * from TBLS;
里面的字段不是managered_table就是external_table。不是内部表就是外部表，没有视图概念，创建一个新的视图
Create/Drop/Alter View
CREATE VIEW [IF NOT EXISTS] [db_name.]view_name [(column_name [COMMENT column_comment], ...) ]
[COMMENT view_comment]
[TBLPROPERTIES (property_name = property_value, ...)]
AS SELECT ...;
hive> create view v_psn as select * from psn where id > 5
show tables;
show views; // 在2.x中是有这样的操作的，但是在1.x的时候没有，所有不要这样查
视图也是一张虚拟表，所有去MySQL里面进行查看
mysql> select * from TBLS;
可以看到最后一行多了一个VIRTUAL_VIEW，
hive> select * from psn;
可以查询对应的视图，有对应的结果了。查询的是视图里的数据，而不是对应表里的数据。
注意：现在只有单表，所有看不出来有什么效果，如果有多表的话，可以把中间的结果进行缓存，这是视图最基本的应用。
hive的索引
经常会听到一级索引、二级索引。索引是做什么用的？
是为了帮助我们提高检索的效率用的。
MySQL里面的索引是自动创建的么？
主键可以拆开了说，唯一且非空。建索引是唯一键，而不是对应的主键。
对应hive而言，和MySQL就不太一样了。它并不会自动帮助我们来创建索引。索引的目的，优化查询以及对应的检索性能。
创建索引的语句：
Create/Drop/Alter Index
CREATE INDEX index_name
ON TABLE base_table_name (col_name, ...)
AS index_type
[WITH DEFERRED REBUILD]
[IDXPROPERTIES (property_name=property_value, ...)]
[IN TABLE index_table_name]
[
[ ROW FORMAT ...] STORED AS ...
| STORED BY ...
]
[LOCATION hdfs_path]
[TBLPROPERTIES (...)]
[COMMENT "index comment"];
选择哪张表base_table_name ，对表里的哪个列col_name 建立索引
[IN TABLE index_table_name]
如果是你来设计数据库的话，你觉得索引应该保存什么信息？
现在有一个非常大的文件，想从里面获取到单词该怎么获取？
有一个非常重要的点：偏移量
想建立索引，保存的是那个列对应的偏移量的信息。而对应到hdfs里面，也是某个文件的偏移量。同时，因为一张表可能对应的是多个文件，所以要保存文件所在的存储目录，以及对应的偏移量。
offset也好，文件也好，都是数据。意味着这个数据也要进行存储，要使用表来存，所以在建的时候，要保存索引信息到某一张固定的表里面，index_table_name是表的的名称，索引信息的这张表。而不是元数据表。
create index t1_index on table psn2(name)
as 'org.apache.hadoop.hive.ql.index.compact.CompactIndexHandler' with deferred rebuild
in table t1_index_table;
一旦是单引号引起来的，一定是表示的我们jar包的对应的某一个类，也就是有对应的索引处理列，来帮助我们记录对应的offset信息，以及对应的数据文件的信息。由对应的类来完成对应的工作。
as：指定索引器，可以自己写jar包替换；
in table：指定索引表，若不指定默认生成在default__psn2_t1_index__表中
如果公司技术实力比较强，不可能直接免费用这些开源的东西，一定是在开源的基础之上做二次开发。如果需要做二次开发，一定要对源码足够了解，同时要知道什么时候能去修改。理论上什么都可以修改，实际一些核心的组件没必要修改。
create index t1_index on table psn2(name)
as 'org.apache.hadoop.hive.ql.index.compact.CompactIndexHandler' with deferred rebuild;
这个语句和刚才的语句差不多，只不过少了in table 保存的是索引信息所存在的那张表，没写意味着有个默认表，会默认帮我们创建`default__psn2_t1_index__``
show tables;
这两张表都创建好了，这两张表里有没有数据？
没有。我现在就9行数据，如果想给他创建对应的索引，意味着必须要把整个文件先读进来，读进来之后找到对应的列，记录下那个列所在的值所在的偏移量，意味着必然对这个文件进行处理了，在文件处理的过程中，刚刚创建索引的时候用了1秒钟，这么短的时间内，有可能把所有的数据文件优先读进来么？连读取的时间都没有。
select * from t1_index_table;
会发现这里面没有任何一条记录。没有所有
hive里面有索引的知识点，但是hive并不会默认帮我们创建对应的索引。需要自己来完成。
自己需要手动来创建索引，需要MR来执行索引的构建过程
重建索引（建立索引之后必须重建索引才能生效）
ALTER INDEX t1_index ON psn REBUILD;
应该申请对应的资源来进行执行，如果MapReduce没有开始执行，说明整个资源一定是有问题的，怎么判断？
打开对应的resourcemanager的webUI
node03:8088 刷新不出来说明没有启动，启动resourcemanager， 如果还没有资源，检查nodemanager有没有启动
yarn-deman.sh start resourcemanager
start-yarn.sh
现在有资源立马开始执行了。
要把对应的数据结果放到t1_index_table这张表里。
select * from t1_index_table
现在有数据了，保存的是表的列名，来自哪个文件，偏移量，把数据对应成功了。
数据增加了，还需要重新构建索引，
load data local inpath '/root/data/data' into table psn;
意味着又要重新进行构建了，是非常麻烦的。所以在企业里面，索引这个点几乎不用，但是每次在进行查询的时候，hive是数据仓库，保存历史时刻的每一个状态，比如说今天的数据到凌晨12点的时候执行完了，当一天的数据都执行完了，我对这张表里所有的数据都来一次构建索引的过程。知乎再来的数据是另一天的数据，不属于当前数据了，这没问题了。分需求，有时候会用，有时候不会用，一般情况下比较少。
只存偏移量怎么让查询加快，查询条件不是要挨个进行过滤么？
在进行查询的时候也一样，既然设置索引了，一定当where条件里包含这个字段的时候才会加快。在遍历某一个文件里数据的时候，一定有一个类似于指针的东西，一般叫Cursor 翻译过来叫游标，游标有个seek方法，它可以直接挪动对应的位置。比如读10个字符，读完之后想跨10个再读，这时候可以移动seek指针，就是对应的偏移量的值，根据偏移量来定位读取，速度一定是快的。
在数据量比较小的时候会发现，建了索引了没有不建索引速度快。能解释为什么？
每次在进行查找的时候，如果数据量比较小的话，第一次要先遍历这张索引表的数据，第二次再找对应的数据表。这涉及到MySQL里面的东西了，MySQL里面有索引，为什么MySQL索引比较快，它是在内存里进行读取的，内存里结构叫B+树。B+树这个数据结构先不管，什么叫树，一个节点后面有N多个分支，假如我现在存的数据首字母是从a到z这样，在进行操作的时候可以挨个进行排列，当我在查找的时候，一定找的是内存。不是磁盘。而无论内存还是磁盘都有一个4k的空间。
（在装固态的时候要求4k对齐，光盘有磁道，里面是一个个对应的小格子，每个小格子都是4k这样的大小（页大小）是最小的空间，每次最小要占4k的大小）
每次在进行数据存储的时候，内存里也一样的，每次只保存4k数据，意味着在加载数据的时候，每次加载一堆4k连续块，内存读取索引文件是非常快的，在MySQL里面整体索引是非常快的。
索引如果公司里有需求就使用，如果没有需求，就不管它了。知道有这个点就行了，面试的时候如果被问到了，要知道索引时怎么被创建的。
提问：刚刚已经建过一张索引表了，psn的部分数据已经建了索引了，当我下一次加载新增的数据，再次建索引的时候，是在这部分数据的基础上往上加新增数据的索引文件，还是再进行一次全量索引。
全量和增量：
在公司基本数所有的操作都是增量的，而不是全量的，全量太浪费资源和时间了。后面在讲麒麟的时候，再讲全量和增量的区别。
hive的join操作：
hive有几种join方式？
LanguageManual Joins
join_table:
//两张表里必须有完全匹配的记录，才会把结果显示出来，如果没有就不进行显示
table_reference [INNER] JOIN table_factor [join_condition]
//left join 把左表的记录显示全了，不管右表是否有记录与它对应
//right join 把右表的记录显示全了，不管左表是否有记录与它对应，如果有正常显示，如果没有显示null
//full 把左表和右表都正常显示，如果匹配不上直接显示空，和MySQL一模一样
//left semi join用来替代MySQL里面的in和exists操作的
| table_reference {
LEFT|RIGHT|FULL} [OUTER] JOIN table_reference join_condition
| table_reference LEFT SEMI JOIN table_reference join_condition
| table_reference CROSS JOIN table_reference [join_condition] (as of Hive 0.10)
table_reference:
table_factor
| join_table
table_factor:
tbl_name [alias]
| table_subquery alias
| ( table_references )
join_condition:
ON expression
LEFT SEMI JOIN implements the uncorrelated IN/EXISTS subquery semantics in an efficient way. As of Hive 0.13 the IN/NOT IN/EXISTS/NOT EXISTS operators are supported using subqueries so most of these JOINs don’t have to be performed manually anymore. The restrictions of using LEFT SEMI JOIN are that the right-hand-side table should only be referenced in the join condition (ON-clause), but not in WHERE- or SELECT-clauses etc.
用来替代IN/EXISTS查询语义（where id in 子查询/where 语句里的exist 比in快很多。比如现在有一张A表，一张B表，A表里有一个字段Deptno，B表里也有一个字段叫Deptno，where exist 子查询，逻辑是这个子查询里面会得到一个最终结果，在查询过程中如果这个结果能显示到对应的记录，那么前面就把查询显示出来，如果没有记录就不显示。当我们在使用exist的时候，一定要用外层的结果这个表里面的数据，来规范内层表里面的数据。内层不能写一个总存在结果的SQL语句，一定要和外层关联。）
有个问题，在外层select的时候不能包含B表的字段，意味着在hive里面想完成这样的操作，不能用in不能用exist，目前还不支持这样的sql解析。有个LEFT SEMI JOIN字段。
案例：
SELECT a.key, a.value
FROM a
WHERE a.key in
(SELECT b.key
FROM B);
can be rewritten to:
SELECT a.key, a.val
FROM a LEFT SEMI JOIN b ON (a.key = b.key)
不能包含B表的字段！！
Hive converts joins over multiple tables into a single map/reduce job if for every table the same column is used in the join clauses e.g.
SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1)
is converted into a single map/reduce job as only key1 column for b is involved in the join. On the other hand
这一句会被转化成一个简单的MR任务，
SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key2)
is converted into two map/reduce jobs because key1 column from b is used in the first join condition and key2 column from b is used in the second one. The first map/reduce job joins a with b and the results are then joined with c in the second map/reduce job.
会被转化成2个MR任务。
这两个语句大体上看起来好像差不太多，但是实际发现，这两个写法在执行mapreduce效果一样么？
注意：是完全不一样的。在第一条sql语句的时候，b.key1包含在相同的连接条件里面，而第二条语句b.key1和b.key2是分别对应的连接条件。这意味着在多表连接存在相同连接键的话会被转成一个MR任务，如果是多个连接条件并且是不同的， 会被转化成多个MR任务，所以在写连接条件的时候，最终还是MR任务的执行操作，所以在执行的时候一定要注意了，能写相同连接键的，一定要写相同连接键。否则可能存在问题。
提问：如果让你用MR来完成两个文件的join怎么来实现？
hive在公司里面是用来做数据仓库的，公司里什么时候用数仓？如果公司里面有一个非常庞大的数据集，并且有各种各样数据源的数据，可以统一的按照一个ETL规则存储到数据仓库里面，然后可以进行统一的分析。在公司里面就是用来存数据的，因为如果直接放到hdfs的话，就是文件，读取文件或利用文件做分析的时候比较麻烦，需要写代码。现在把一个个文件映射成一张张表，写SQL是大部分人都会的事情，可以用sql语句来分析对应文件了。
hive和hdfs之前其实是一个解耦过程，就通过定义row format来定义格式规范，按照固定读取规则来处理就完事了。
hive是支持limit操作的，但是会有问题，limit用来做分页，这种说法是不对的，limit准确的解释是限制输出。hive一般情况下是不用来做分页的，因为它没有这样的需求，hive里面放的是GB TB级别的数据，这个时候需要把全量的数据进行查看么？用的很少，把hive进行分析，分析完可能会存在大量的结果，结果是有可能要进行分页的，结果在进行分页的时候，一般情况下是要暂存到某一个hive的结果表里，暂存之后，把大量的结果先转存到对应的MySQL关系型数据库表里面，从关系型数据库里再做分页。
面试的时候一般分两个环节的问题：第一个环节，纯技术点，一些死的东西，第二个一些开放性的问题，这些开放性的问题要靠临场反应和学过知识的一些条件反射了。一般开放性问题也没有固定答案，能想什么思路就告诉他，提供对应思路。在公司里面遇到bug是很正常的事情，可能需要很繁杂的测试才能通过，但一定要提供思路，知识点的全面性，条件反射。
hive权限管理
hive里面提供了4种权限管理方式：
官网里，找到Authorization
1 Storage Based Authorization in the Metastore Server
基于元数据的管理方式，元数据到表这个级别，不能做到更细粒度的权限控制，一般在企业里是不用的。
2 SQL Standards Based Authorization in HiveServer2
在公司里面hive有两个用途，第一个是增删改查，第二个是查询，大部分人是用来做查询的，所以在做查询的时候，不可能所有人都用cli的方式，大部分人都是hiveserver2，基于hiveserver2是需要做很多权限管理的，这儿提供了这种方式，叫SQL标准的hiveserver2权限管理，Grank/Revoke叫DCL数据库权限管理。
SQL Standards Based Authorization:his is recommended because it allows Hive to be fully SQL compliant in its authorization model without causing backward compatibility issues for current users. As users migrate to this more secure model, the current default authorization could be deprecated.
这种方式是被推荐的，因为它允许hive完全sql的支持在这种认证的模式里面。
主要讲的也是这种方式，基于hiveserver2这种方式的sql标准的授权和取消权限的模型。重点讲。
3 Authorization using Apache Ranger & Sentry
使用Apache第三方组件Ranger和Sentry，这两个东西非常简单。通过rest方式搭建一个服务，有了这个服务之后发送请求，启用管理。是一个小组件。
4 Old default Hive Authorization (Legacy Mode)
压根没人用。
SQL Standard Based Hive Authorization
注意：当一旦启用授权模型之后，意味着它是为了保护hive里面的数据更加安全，所以它一定会增加很多额外的限制：
限制：
- 1、启用当前认证方式之后，dfs, add, delete, compile, and reset等命令被禁用。
第一个dfs表示hive可以直接访问hdfs里面的文件系统，第二个add随意用户添加对应的jar包，比如自定义函数时候的add jar的方式都被禁用掉了，为了保证数据安全，所以很多命令都禁用掉了 - 2、通过set命令设置hive configuration的方式被限制某些用户使用。 – （可通过修改配置文件hive-site.xml中hive.security.authorization.sqlstd.confwhitelist进行配置）
只有管理员才可以用这样的方式，其他普通用户进行访问的时候，根本没有设置属性的权限。现在虚拟机里面用的权限都是root，但这种方式是不对的，到公司之后不可能直接给你root权限，如果直接给你root账号，直接走人别干了，万一有一天误操作 rm -rf /* 把库删掉了怎么办，root不太安全，即使公司的管理和运维人员也不会用root来操作。也是一个普通的管理员账号，当需要root权限的时候，直接把权限改成root。 - 3、添加、删除函数以及宏的操作，仅为具有admin的用户开放。
管理员可以用，除了管理员不能用。宏操作类似于关系型数据库定义的function的功能，表示小的代码逻辑。 - 4、用户自定义函数（开放支持永久的自定义函数），可通过具有admin角色的用户创建，其 他用户都可以使用。
- 5、Transform功能被禁用。
一旦启用权限管理之后，很多功能被禁用掉了，所以一般在公司里面，如果没有特殊的需求，一般来说是不配置的，如果配置了要知道，这些东西都没法用了。
配置权限控制：
到hive-site.xml文件，最下面复制粘贴
<property>
//启用授权功能
<name>hive.security.authorization.enabled</name>
<value>true</value>
</property>
<property>
//doAs里面定义了一些规则，要把这些规则禁用掉，设置成false
<name>hive.server2.enable.doAs</name>
<value>false</value>
</property>
<property>
//这个属性非常关键！！在系统里面有管理员角色和普通角色，管理员可以添加自定义函数，进行其他一些操作，要告诉他谁是管理员。如果用的其他普通用户，用逗号分隔，补充在后面
<name>hive.users.in.admin.role</name>
<value>root</value>
</property>
<property>
//表示对应核心处理的类是哪个类
<name>hive.security.authorization.manager</name>
<value>org.apache.hadoop.hive.ql.security.authorization.plugin.sqlstd.SQLStdHiveAuthorizerFactory</value>
</property>
<property>
//对应的授权用户的管理器
<name>hive.security.authenticator.manager</name>
<value>org.apache.hadoop.hive.ql.security.SessionStateUserAuthenticator</value>
直接运行hiveserver2
hiveserver2
到node04使用beelline的方式来连接了，这里会有问题：
beeline -u jdbc:hive2://node03:10000/default
进来了，show tables可以查看所有表，但是可以查询么？
select * from psn;
匿名用户没有查询的权限操作。这时候涉及到权限管理方面的事情了。刚才没写用户名默认就是匿名用户，匿名用户不具备查询这张表的权限，可以看这个信息：
desc formatted psn;
owner属于root，现在也没权限查看了
这时候其他用户没法查看了，意味着要给他授权了：
有对应的角色的概念，public表示的是普通角色，admin表示的是管理员角色
show current roles;
默认情况下都是public的，所以public不能创建角色。
create role test;
也不能创建。
用户必须属于admin这个角色，并且把它作为当前角色之后，才能触发这个操作，匿名用户不可以。
beeline
! connect jdbc:hive2://node03:10000/default root 123
这时候用户一定是root了
现在要创建角色了
create role test;
root并不允许添加角色。这是为什么？
一个用户可以具有一个或多个角色，root用户当进行平常操作的时候，它就是public这样的权限，现在要创建角色了，要切换成管理员。
set role admin;
在执行操作。root是用户，管理员是角色，用户一定是归属于某一个角色的，但可以是一个角色，也可以是N多个角色。
和-n输入的参数有关，和操作系统无关。
角色表示一组权限的集合，但现在test有权限么 ？
show role grant role test;
grant admin to role test with admin option;
with admin option什么意思？
当你加完这三个单词之后，表示的是当前角色也具备了给其他角色赋权的权利，不加这三个单词表示也有了这样的权限，但是并不能够给其他角色授权
管理员默认具备了所有表的所有访问权限
删除权限：
revoke admin from role test;
表的操作：
想使用MySQL，必须要改变MySQL的登陆权限，
grant all privileges on *.* to root@% identified by ok with grant option;
在开一个窗口：
beeline
! connect jdbc:hive2://node03:10000/default abcd abcd
这时候用管理员可以给他赋权：
grant select on psn to user abcd [with grant option];
这时候abcd再执行查询操作就可以了。
show grant user abcd on psn;
和MySQL一样做到了更细粒度的权限控制了。