Apache Sentry，看这里就够了！（二）

上篇文章我们详细的描述了有关Apache Sentry的元数据库表设计，基本上理解了库表，也就理解了其存储逻辑，在自定义开发时，如果想要查询某些权限信息，除了传统的通过Hive进行Show Grant的命令外，也有了更灵活的方式。

本篇文章将基于上述文章中一些没能写的更细的内容进行详细阐述，读完本篇文章，你会对Sentry的执行逻辑有了一个印象，然后基于执行逻辑和数据库设计结构，就可以进行自定义开发或者模仿其设计一个自己的小项目啦！

基本组成结构

Sentry是由中央Sentry Server和一堆定制开发的plugin组成的，每一个plugin都是贴合对应的引擎专属定制的，例如控制Hive权限的HivePlugin，HDFSPlugin等。等接触了Ranger，你会发现Ranger也是这种设计。毕竟各个引擎虽然同属Hadoop体系，但是各个项目独立开发和发展，在权限控制上没有统一的设计，更别说有些非Hadoop体系的项目也想统一管控了，所以如果想要通过统一的项目做管控，那也就只有这种办法了。

本篇文章主要讲述Hive-Hadoop的权限控制逻辑。CDH的另一个查询组件Impala同理。

主要涉及的组成结构：

Sentry Hive Listener（也就是前文说的Hive Plugin，具体的表现形式是Listener）
Sentry Hive Hook（Sentry用于鉴权的实现）
Hive Metastore（HMS）：因为在Sentry源码与社区对话中会大量的看到这个缩写，所以这篇文章也用缩写吧
Sentry Server：Sentry服务主server
Sentry Store：就是Sentry的元数据存储地方
Hadoop NameNode plugin（NN Plugin）：HDFS的插件

权限控制逻辑

从宏观上来看，你可以在Hive针对某张表授权（grant xxx to role），然后在对应的就可以获得HDFS的权限，这是怎么做到的呢？接下来会通过两个场景来讲述。（对比第一篇，你会理解的更透彻）

场景一新建表（Create Table）

Hive接收到Create Table语句后进行解析，并将其实际内容（库名、表名、列名、对应HDFS Location）存储到HiveMetaStore（HMS）中，这里的存储逻辑详细的可以看下HMS的设计逻辑。除了存储的这些实际元数据，这个创建表的“事件”也会通过某种格式的整理存储到NOTIFICATION_LOG表中，用于通知其他加入Hive的插件。这样的设计也是为了方便其他项目获取对应的信息。在这一步中，Hive还会通知HDFS的NameNode进行对应Location的创建。创建成功后，整个在Hive上的建表流程算是完成了，用户也能收到信息已完成。但是对于权限，这才刚刚开始。
在HiveServer上面的Sentry Listener监听到了建表语句，经过解析后，通过表名+Location的信息的形式，通过tcp连接通知Sentry Server有新的事件到达，并进行数据保存。
除了Sentry Listener的主动触发，Sentry Server还有一个HMS Follower的线程在轮询探查，监听HMS中的NOTIFICATION_LOG表，如果该表有新的event_id（即Sentry数据库中的notification_id），说明有新的事件发生，就通过NOTIFICATION_LOG主动拉取新的数据。这也是为什么，有时候CDH中忘记配置Sentry Listener，但是Sentry依然能管控到权限的原因。
3和2的信息整合后，Sentry Server会将新建的表信息+HDFS Location信息存储入Sentry Store中。就是第一篇文章说的那些Path相关的表。这一步除了添加了元数据，同样也会产生“事件”信息，即以某种结构存储在SENTRY_PATH_CHANGE中。（有没有发现，这里的逻辑和HMS的一样，说明CDH对这些做了统一设计调整）
Sentry NN Plugin一直在监听Sentry Store的SENTRY_PATH_CHANGE表，发现有新的事件id（这次是表上的change_id）,于是进行更新操作，将新建的表实体和Location的关联信息拉到NN内存中，建立映射关系。

至此，建表的逻辑结束。

因为没有对这张表进行授权，在NN中仅有Location和表实体之间的关联，并没有权限信息，所以用户想要直接使用这个HDFS或者Hive表都是没有权限的。

场景二授权（Grant Table）

Hive接收到授权的语句进行解析，当发现是权限相关的操作时，Sentry Hook会直接进行拦截，并将相关信息通知Sentry Server进行保存。（这也是权限信息没有存储在HMS中的原因）
Sentry Server收到信息后，将权限相关的信息存储在Sentry Store中，即第一篇文章说的Perm相关的表中。同样的，这样的操作也会被当作一个事件，以固定的格式记录在SENTRY_PERM_CHANGE中。
Sentry NN Plugin同样也在监听Sentry Store的SENTRY_PERM_CHANGE表，当发现有新的事件id（即change_id）时，会获取这个事件信息进行解析，转化成这个表和相关权限的映射关系，存储在NN内存中。

至此，授权的逻辑结束。

这个时候，NN中同时存储着两个逻辑，Location-表，和表-权限，所以很容易通过关联能够拿到Location-权限的关联关系，这个时候如果直接操作HDFS（使用HDFS Cli或者Spark），你会发现已经有了权限。

因为在Sentry管控下的HDFS的权限逻辑是两个关联表之间的关联，所以官网会提到说，Sentry只能控制Hive内部实体相关路径，因为Hive实体之外的，关联不到，也就没有意义了。