0803-什么是Apache Ranger - 5 - Hive Plugin

作者：Eric Lin (林晨辉)， Cloudera高级售后技术支持工程师。

在阅读本文前，建议先阅读前面的文章：

《0741-什么是Apache Ranger - 1》

《0742-什么是Apache Ranger - 2》

《0745-什么是Apache Ranger - 3》

《0800-什么是Apache Ranger - 4 - Resource vs Tag Based Policies》

本文主要介绍Ranger中的Hive Plugin，当你尝试在Hive中创建或修改table时，Ranger是如何工作的。Ranger如果要使用策略对组件进行授权，必须在这些组件上安装Ranger Plugin。比如为了将授权应用于Hive实体，如DB，Table或Columns，你必须为Hive服务安装Ranger Plugin。实际情况你可能还需要为HDFS，HBase，Kafka安装插件，但本文重点介绍Hive Plugin。

那么什么是插件，它有什么作用呢？Ranger的Hive插件实际上是在HiveServer2中附上一小段代码，可以执行Ranger策略正常运行所需的额外功能。如下图所示是每个组件之间的关系：

当你在Beeline中运行CREATE TABLE语句创建新表时，它将向HiveServer2提交查询，HiveServer2在运行该查询之前，它会先检查缓存的策略文件(图中所示为1)，判断提交查询的用户有具有执行该操作的权限，才会最终提交查询并创建表。

成功创建新表后，Ranger的Hive插件将触发两件事：

将审核事件发送到Solr和/或HDFS，取决于配置，图中所示为2
将Kakfa事件发送到Topic “ATLAS_HOOK”，图中所示为3，以记录已创建新实体，因此Ranger的Hive Plugin实际上是Kafka中“ATLAS_HOOK” Topic的Producer

要使上面两个操作都能执行，需要在Ranger中设置策略以确保hive用户可以写数据到Kafka的ATLAS_HOOK Topic中，同时hive用户需要有权限在Solr中创建索引并写入数据到HDFS，假设Hive的模拟(Impersonation)已经关闭。否则上面两个操作会失败，如果失败了可以查看HiveServer2的日志，默认保存在/var/log/hive中。

一旦事件到达Kafka的“ ATLAS_HOOK”，Atlas作为该Topic的consumer，会将这些数据保存到数据库，图中所示为4，以便Atlas管理员可以在Web UI中看到此新实体，查看数据溯源信息，以及附加的Tag/Classifications等。

一旦Audit事件到达Solr并且正确的创建了索引，管理员可以在Ranger web UI的Audits页面查看到该审计信息，图中所示为5.

请注意，HDFS中的数据仅用于备份，任何服务都不会使用，默认情况下，Solr中的审计数据将在90天后过期。

参考前面的文章《什么是Apache Ranger - 4 - Resource vs Tag Based Policies》，我们知道什么是标签策略以及它是如何工作的。Atlas管理员可以create/modify/delete标签，如果做了该操作，所有跟Tags/Classifications相关的实体都将作为事件发送到Kafka的“ATLAS_ENTITIES” Topic中，如上图所示为6，同时这些实体也会被发送到Ranger TagSync服务，图中所示为7，并且会保存到Ranger的数据库中，图中所示为8。同样这些操作需要配置Ranger策略，以使atlas用户有权限写数据到Kafka的ATLAS_ENTITIES Topic中。

Ranger还具有一个UserSync服务，它可以配置同步LDAP中的user/group信息并将其保存到Ranger的数据库中。

一旦在Ranger中更新了标签信息，用户和组以及所有其他基于资源的策略都已正确同步，HiveServer2中的Hive插件会将其拉到本地缓存中，默认情况下策略会每30秒同步一次，图中所示为9，以便新的请求会采用新的策略。这样如果Ranger服务挂了，客户端如Hive的授权依旧可以正常执行。等Ranger服务恢复，Hive插件则会恢复定期去Ranger同步策略。

最终随着用户在Hive中创建或更新数据库，表或列，该循环又会往复一遍。

原文参考：

https://cloudera.ericlin.me/2020/05/introduction-to-ranger-part-v-hive-plugin/