上篇文章我们详细的描述了有关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 Store
- Hadoop NameNode plugin（NN Plugin）
权限控制逻辑
从宏观上来看，你可以在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实体之外的，关联不到，也就没有意义了。
