一种Hive表权限控制方法、装置、计算机设备和存储介质

技术领域

本公开实施例涉及信息安全技术领域，尤其涉及一种Hive表权限控制方法、装置、计算机设备和存储介质。

背景技术

在开源环境下，将生产和开发权限隔离有许多方案，举例如下：1.物理环境隔离：通过搭建完全不同的计算存储集群(hadoop集群)，生产与开发任务使用完全互不干扰的计算环境，无法操作同一份数据，从而实现物理层面的权限隔离。2.用户权限隔离：利用开源权限框架(比如ApacheRanger)，实现用户级别权限控制，从而达到生产用户与开发用户拥有不同级别的权限，从而实现逻辑层面权限隔离。3.用户组权限隔离：利用开源权限框架(比如ApacheRanger)，实现用户组级别权限控制，从而达到生产组与开发组拥有不同级别的权限，从而实现逻辑层面权限隔离。

尽管存在以上多种生产和开发权限隔离方案，但是都有其兼顾不到的情况，比如：物理环境隔离的缺点是计算及存储成本高，需要开发环境与生产环境规模完全一致；同步成本高，为保障操作数据完全一致，需完备的数据同步功能。用户权限隔离的缺点是用户操作限制较大，为了权限隔离，无法实现同一用户既开发任务又要执行生产任务的需求；权限管理繁琐，用户级别权限控制意味着每个用户都要有对应的权限生命周期管理，存在高频的权限申请、审批操作。用户组权限隔离虽然在用户级别权限上有所优化，能够极大程度降低权限操作，但是开发组和生产组仍需进行重复的权限申请操作，且开发组需对每一份生产组的数据进行申请，操作仍旧高频。

发明内容

本公开实施例提供一种Hive表权限控制方法、装置、计算机设备和存储介质，能够通过识别到的生产组和开发组，自动管理生产组和开发组的权限配置，无需高频申请操作即可实现生产开发权限隔离，同时在不扩大成本的基础上，保障了数据安全。

第一方面，本公开实施例提供了一种Hive表权限控制方法，包括：

接收用户基于客户端发送的针对Hive表的操作请求并解析，确定所述操作请求对应的操作类型，所述操作类型包括查询操作或非查询操作；

基于识别到的用户类型和所述操作类型，确定所述操作请求是否符合用户操作权限配置方案，所述用户类型包括生产组或开发组；

若符合，则允许用户对相应Hive表执行所述操作请求对应的操作；

若所述操作类型为非查询操作，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置，其中，所述Hive表的权限配置包括相应Hive表的访问维度以及访问维度值，所述访问维度包括全表读写维度、全表只读维度和字段只读维度，所述访问维度值为拥有相应访问维度权限的用户Hive表权限控制。

第二方面，本公开实施例还提供了一种Hive表权限控制装置，包括：

操作请求解析模块，用于接收用户基于客户端发送的针对Hive表的操作请求并解析，确定所述操作请求对应的操作类型，所述操作类型包括查询操作或非查询操作；

操作请求鉴权模块，用于基于识别到的用户类型和所述操作类型，确定所述操作请求是否符合用户操作权限配置方案，所述用户类型包括生产组或开发组；

操作请求执行模块，用于若符合，则允许用户对相应Hive表执行所述操作请求对应的操作；

Hive表权限配置更新模块，用于若所述操作类型为非查询操作，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置，其中，所述Hive表的权限配置包括相应Hive表的访问维度以及访问维度值，所述访问维度包括全表读写维度、全表只读维度和字段只读维度，所述访问维度值为拥有相应访问维度权限的用户。

第三方面，本公开实施例还提供了一种计算机设备，包括：

一个或多个处理装置；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理装置执行，使得所述一个或多个处理装置实现如本公开任一实施例所述的Hive表权限控制方法。第四方面，本公开实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如本公开任一实施例所述的Hive表权限控制方法的步骤。

本公开实施例接收用户基于客户端发送的针对Hive表的操作请求并解析，确定所述操作请求对应的操作类型，所述操作类型包括查询操作或非查询操作；基于识别到的用户类型和所述操作类型，确定所述操作请求是否符合用户操作权限配置方案，所述用户类型包括生产组或开发组；若符合，则允许用户对相应Hive表执行所述操作请求对应的操作；若所述操作类型为非查询操作，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置，其中，所述Hive表的权限配置包括相应Hive表的访问维度以及访问维度值，所述访问维度包括全表读写维度、全表只读维度和字段只读维度，所述访问维度值为拥有相应访问维度权限的用户，上述基于用户类型和操作类型对用户的操作请求进行鉴权，保证了权限控制的全面性，通过自动识别到的用户类型，自动管理生产组和开发组的权限配置，无需高频申请操作即可实现生产开发权限隔离，同时在不扩大成本的基础上，保障了数据安全。

附图说明

结合附图并参考以下具体实施方式，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。

图1为本公开实施例提供的一种Hive表权限控制方法的流程图；

图2为本公开实施例提供的一种Hive表的访问维度的示意图；

图3为本公开实施例提供的一种Hive表的权限配置示意图；

图4为本公开实施例提供的一种Hive发布表的权限配置示意图；

图5为本公开实施例提供的一种Hive表的权限整体架构示意图；

图6为本公开实施例提供的一种Hive表权限控制装置的结构示意图；

图7为本公开实施例提供的一种计算机设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。

需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

本公开实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。

图1为本公开实施例提供的一种Hive表权限控制方法的流程图。本实施例可适用于用户针对Hive表执行操作请求，需要对操作请求进行鉴权处理，且对执行相应操作后的Hive表进行权限管理的情况，该方法可以由Hive表权限控制装置来执行，Hive表权限控制装置可以集成在计算机设备中。如图1所示，该方法可以包括如下步骤：

S110、接收用户基于客户端发送的针对Hive表的操作请求并解析，确定所述操作请求对应的操作类型，所述操作类型包括查询操作或非查询操作。

本实施例的技术方案优选可以由Hive权限控制服务端执行，其中，Hive权限控制服务端可以包括引擎服务端和HiveMetaStore服务端，其中，引擎服务端用于接收用户基于客户端发送的操作请求并解析，HiveMetaStore服务端则用于执行Hive表相关权限管理操作。在执行本实施例的技术方案之前，可以预先构建Hive权限控制服务端，以利用Hive权限控制服务端执行本实施例的技术方案，优选的，可以分别构建HiveMetaStore服务端和引擎服务端。

构建HiveMetaStore服务端的具体过程如下：

1)搭建Hadoop集群，启动Hdfs(Hadoop Distribute File System，Hadoop分布式文件系统)存储服务及Yarn集群资源调度服务，以构建HiveMetaStore服务端所需的基础服务框架。

2)在上述构建的基础服务框架中安装MySQL(关系型数据库管理系统)数据库。

3)下载Hive源码，修改HiveMetaStore模块，创建不同的调用接口(方便引擎服务端根据需要调用，不同的调用接口例如可以包括字段鉴权接口、创建Hive表接口、修改Hive表接口、删除Hive表接口等)，以使HiveMetaStore服务端可以接收客户端发送的针对Hive表的操作信息，校验该操作信息是否合法，并触发相应的Hook逻辑。

4)开发两个Hook逻辑：事件监听器MetaStoreEventListener和事件前监听器MetaStorePreEventListener。其中，事件前监听器可以用于执行事件的鉴权操作，例如本实施例技术方案中的S120，事件监听器可以用于触发关于Hive表的权限配置操作，例如本实施例技术方案中的S140。优选的，可以将事件监听器MetaStoreEventListener和事件前监听器MetaStorePreEventListener编译成jar包,并将jar包放置在Hive安装路径lib下。

5)将编译后的Hive源码、元数据库、事件监听器MetaStoreEventListener和事件前监听器MetaStorePreEventListener部署到Hadoop集群内，完成HiveMetaStore服务端的构建。

6)启动HiveMetaStore服务端。

创建引擎服务端的具体过程如下：

1)构造HiveMetaStoreClient客户端，用于根据用户不同操作请求调用HiveMetaStore服务端中不同的调用接口；

2)新增外部模块，用于获取用户的查询操作请求，解析所有被查询的字段信息，利用HiveMetaStoreClient客户端调用字段鉴权接口，以进行字段鉴权。

优选的，可以利用创建好的引擎服务端执行S110中的具体操作。可以根据客户端的类型确定引擎服务端的类型，示例性的，客户端的类型可以包括Beeline、JDBC(JavaData BaseConnectivity，java数据库连接)、Spark-Sql、Spark-Shell、Spark-Jar、Presto-Cli等，相应的，Beeline和JDBC客户端对应HiveServer2引擎服务端，Spark-Sql、Spark-Shell和Spark-Jar客户端对应Spark引擎服务端，Presto-Cli客户端对应Presto引擎服务端。

本实施例中，针对Hive表的操作请求可以包括创建Hive表的请求、修改Hive表(例如可以包括修改Hive表名称、修改Hive表字段以及修改Hive表分隔符等)的请求、删除Hive表的请求、查询Hive表内容的请求以及申请Hive表权限的请求等。通过解析操作请求的具体内容，可以确定操作请求对应的操作类型包括查询操作和非查询操作。

在确定操作请求的具体操作类型后，可以根据操作类型调用HiveMetaStore服务端中的相应接口，以便后续执行相应操作。可选的，若操作类型为查询操作，则可以利用新增外部模块调用字段鉴权接口，若操作类型为非查询操作，则可以直接根据操作请求的具体内容调用相应接口，例如，操作请求的具体内容为创建Hive表，则直接调用创建Hive表接口，又例如，操作请求的具体内容为修改Hive表，则直接调用修改Hive表接口。

S120、基于识别到的用户类型和所述操作类型，确定所述操作请求是否符合用户操作权限配置方案，所述用户类型包括生产组或开发组。

本实施例中的用户对应的用户类型可以是生产组也可以是开发组，同一项目下既有生产组也有开发组，不同的生产组对应的项目不同，不同的开发组对应的项目也不同。可选的，将团队事务根据业务、部门以及职责等不同分为不同的项目，将团队内的全量用户根据不同项目分为不同项目组，每个项目组拥有两个小组，即生产组和开发组，其中，生产组包括至少一个客户端用户，开发组也包括至少一个客户端用户。示例性的，全量用户对应两个项目组，分别是项目组1和项目组2，每个项目组下均包括生产组和开发组，即项目组1的生产组、项目组1的开发组、项目组2的生产组和项目组2的开发组。

为了便于服务端方便快捷得识别客户端的用户类型，优选可以通过设置客户端名称来区分各项目组对应的生产组和开发组，示例性的，项目组1的生产组对应的客户端名称可以包括GROUP1_PRO，项目组1的开发组对应的客户端名称可以包括GROUP1_DEV，项目组2的生产组对应的客户端名称可以包括GROUP2_PRO，项目组2的开发组对应的客户端名称可以包括GROUP2_DEV。

用户操作权限配置方案为基于用户类型和操作类型，为用户配置的与Hive表相关的用户权限。基于识别到的用户类型和操作类型，可以确定用户发送的操作请求是否符合用户操作权限配置方案。示例性的，若操作类型为针对Hive表的查询操作，用户类型为GROUP1_PRO，则可以通过确定GROUP1_PRO是否具有查询相应Hive表的权限，来确定操作请求是否符合用户操作权限配置方案。又示例性的，若操作类型为创建Hive表，用户类型为GROUP2_PRO，则可以通过确定GROUP2_PRO是否具有创建Hive表的权限，来确定操作请求是否符合用户操作权限配置方案等。

优选的，可以利用创建好的HiveMetaStore服务端中的事件前监听器MetaStorePreEventListener来执行S120中的具体操作。具体的，事件前监听器可以根据客户端名称来确定客户端的用户类型，示例性的，客户端名称包括GROUP1_PRO，则可以确定客户端的用户类型为GROUP1_PRO。又示例性的，操作请求对应的操作类型为针对Hive表1的查询操作，则可以通过查询Hive表1的权限配置来确定用户类型为GROUP1_PRO的客户端是否具有查询Hive表1的权限，若是，则可以确定操作请求符合用户操作权限配置方案，若否，则可以确定操作请求不符合用户操作权限配置方案。

S130、若符合，则允许用户对相应Hive表执行所述操作请求对应的操作。

可选的，若操作请求为创建Hive表的请求，则允许用户对相应Hive表执行所述操作请求对应的操作包括服务端允许用户在目标路径创建相应Hive表。若操作请求为修改Hive表的请求，则允许用户对相应Hive表执行所述操作请求对应的操作包括服务端允许用户修改相应Hive表。若操作请求为删除Hive表的请求，则允许用户对相应Hive表执行所述操作请求对应的操作包括服务端允许用户删除相应Hive表。若操作请求为查询Hive表内容的请求，则允许用户对相应Hive表执行所述操作请求对应的操作包括服务端允许用户查询相应Hive表字段内容。若操作请求为申请Hive表权限的请求，则允许用户对相应Hive表执行所述操作请求对应的操作包括服务端允许用户进入申请相应Hive表权限的审批流程。

S140、若所述操作类型为非查询操作，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置，其中，所述Hive表的权限配置包括相应Hive表的访问维度以及访问维度值，所述访问维度包括全表读写维度、全表只读维度和字段只读维度，所述访问维度值为拥有相应访问维度权限的用户。

可以理解的，若操作类型为针对Hive表的非查询操作，则相应操作可能会使Hive表发生改变，相应的，Hive表的权限配置也会因此有所不同，基于此，可以在完成操作请求对应的操作之后，基于用户类型和操作类型，更新相应Hive表的权限配置。

本实施例中，访问维度为表和字段组合的唯一值。一个访问维度可以拥有多个访问维度值。全表读写维度，代表全表读写权限，组成公式为“库名.表名.-.rw”，其中，rw表示读写。全表只读维度，代表全表只读权限，组成公式为“库名.表名.-.ro”，其中，ro表示只读。字段只读维度，代表表中相应字段的只读权限，组成公式为“库名.表名.列名.ro”。一个访问维度值(即一个用户或一个用户类型)可以申请多个访问维度的权限。全表的写访问维度只有一个访问维度值，就是创建表的用户或用户类型。示例性的，如果创建表的用户类型为GROUP1_PRO，则该表的写访问维度为GROUP1_PRO且唯一。图2为本公开实施例提供的一种Hive表的访问维度的示意图，如图2所示，以图中的“db1.table1.col1.ro”为例，对图中的相应字段含义进行说明，字段db1表示数据库1，字段table1表示Hive表1，字段col1表示列1。

优选的，可以利用创建好的HiveMetaStore服务端中的事件监听器MetaStoreEventListener来执行S140中的具体操作。在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置的部分操作逻辑如下表1所示。

表1

示例性的，若操作类型为在数据库db1中创建Hive表table1，用户类型为GROUP2_PRO，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置可以包括：在完成创建相应table1之后，授予GROUP2_PRO针对相应table1的读写权限，其对应的访问维度为“db1.table1.-.rw”，访问维度值为GROUP2_PRO，同时，为了方便同项目组下的开发组GROUP2_DEV读取生产组数据table1，还可以授予GROUP2_DEV针对相应table1的只读权限，其对应的访问维度为“db1.table1.-.ro”，访问维度值为GROUP2_DEV。又示例性的，若操作类型为修改上述示例中table1的表名，用户类型为GROUP2_PRO，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置可以包括：在完成将table1的表名修改为table11之后，将原table1的权限配置平移给table11，即table11的权限配置包括访问维度“db1.table11.-.rw”以及对应的访问维度值GROUP2_PRO，访问维度“db1.table11.-.ro”以及对应的访问维度值GROUP2_DEV。又示例性的，若操作类型为删除上述示例中的table1，用户类型为GROUP2_PRO，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置可以包括：在删除table1之后，将原table1的权限配置删除，即删除的权限配置包括访问维度“db1.table1.-.rw”以及对应的访问维度值为GROUP2_PRO，访问维度“db1.table1.-.ro”以及对应的访问维度值为GROUP2_DEV。示例性的，若操作类型为在数据库db1中创建Hive表table2，用户类型为GROUP2_DEV，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置可以包括：在完成创建相应table2之后，授予GROUP2_DEV针对相应table2的读写权限，其对应的访问维度为“db1.table2.-.rw”，访问维度值为GROUP2_DEV。又示例性的，若操作类型为修改上述示例中table2的表名，用户类型为GROUP2_DEV，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置可以包括：在完成将table2的表名修改为table22之后，将原table2的权限配置平移给table22，即table22的权限配置包括访问维度“db1.table22.-.rw”以及对应的访问维度值GROUP2_DEV。又示例性的，若操作类型为删除上述示例中的table2，用户类型为GROUP2_DEV，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置可以包括：在删除table2之后，将原table2的权限配置删除，即删除的权限配置包括访问维度“db1.table2.-.rw”以及对应的访问维度值为GROUP2_DEV。

本实施例接收用户基于客户端发送的针对Hive表的操作请求并解析，确定所述操作请求对应的操作类型，所述操作类型包括查询操作或非查询操作；基于识别到的用户类型和所述操作类型，确定所述操作请求是否符合用户操作权限配置方案，所述用户类型包括生产组或开发组；若符合，则允许用户对相应Hive表执行所述操作请求对应的操作；若所述操作类型为非查询操作，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置，其中，所述Hive表的权限配置包括相应Hive表的访问维度以及访问维度值，所述访问维度包括全表读写维度、全表只读维度和字段只读维度，所述访问维度值为拥有相应访问维度权限的用户，上述基于用户类型和操作类型对用户的操作请求进行鉴权，保证了权限控制的全面性，通过自动识别到的用户类型，自动管理生产组和开发组的权限配置，无需高频申请操作即可实现生产开发权限隔离，同时在不扩大成本的基础上，保障了数据安全。

在上述各实施例的基础上，进一步的，若所述操作类型为创建第一Hive表，则所述基于识别到的用户类型和所述操作类型，确定所述操作请求是否符合用户操作权限配置方案，包括：

基于所述用户类型确定所述用户是否拥有操作路径的操作权限，所述操作路径为所述操作请求中所包含的路径信息；

若是，则确定所述操作请求符合用户操作权限配置方案，若否，则反馈所述操作请求异常信息。

本实施例通过基于用户类型验证用户是否拥有操作路径的操作权限，可以保证系统数据安全。示例性的，用户类型为GROUP1_PRO的客户端请求在操作路径1下创建第一Hive表，则需要确定用户GROUP1_PRO是否拥有操作路径1的操作权限。若用户GROUP1_PRO拥有操作路径1的操作权限，则确定所述操作请求符合用户操作权限配置方案，此时，用户GROUP1_PRO可以执行后续在操作路径1下创建第一Hive表的操作，若用户GROUP1_PRO没有操作路径1的操作权限，则反馈所述操作请求异常信息，此时，用户GROUP1_PRO无法执行后续在操作路径1下创建第一Hive表的操作。

在上述各实施例的基础上，进一步的，若所述用户类型为当前生产组，所述操作类型为针对第二Hive表进行的权限申请，则所述基于识别到的用户类型和所述操作类型，确定所述操作请求是否符合用户操作权限配置方案，包括：

若所述第二Hive表为其他生产组发布的且所述操作类型为针对所述第二Hive表进行的读权限申请，则确定所述操作请求符合用户操作权限配置方案，其中，所述其他生产组对应的项目与所述当前生产组对应的项目不同；

若所述第二Hive表为其他生产组发布的且所述操作类型为针对所述第二Hive表进行的写权限申请，则确定所述操作请求不符合用户操作权限配置方案，并反馈所述操作请求异常信息；

若所述第二Hive表为其他开发组发布的，则确定所述操作请求不符合用户操作权限配置方案，并反馈所述操作请求异常信息，所述其他开发组对应的项目与所述当前生产组对应的项目不同。

本实施例中当前生产组通过申请才能获取其他生产组发布表的读权限，保证了其他生产组发布表的数据安全。其中，第二Hive表为其他生产组或其他开发组在权限申请平台(该权限申请平台部署在Hive权限控制服务端中，其可以是数据地图，该数据地图是一种用于展示全部Hive表且允许权限相互申请的平台媒介，该权限申请平台可以提供生产组和开发组发布自己创建的Hive表到数据集市功能；可以提供生产组对其他生产组发布的Hive表进行读权限申请。可以提供开发组对其他开发组发布的Hive表进行读权限申请。在生产组对其他生产组发布的表进行读权限申请时，后端同时添加两次权限，既授权生产组也授权开发组)上发布的表格，可以称为发布表，其可以是其他生产组或其他开发组创建的完整表格，也可以是完整表格中的部分字段。本实施例中，当前生产组只有申请其他生产组发布表读权限的资格，由于其他生产组发布表的写权限对应的操作维度值是其本身，因此，当前生产组没有申请其他生产组发布表写权限的资格。此外，当前生产组也没有申请其他开发组发布表读写权限的资格。

在上述各实施例的基础上，进一步的，若所述用户类型为当前开发组，所述当前开发组对应的项目与所述当前生产组对应的项目相同，所述操作类型为针对第三Hive表进行的权限申请，则所述基于识别到的用户类型和所述操作类型，确定所述操作请求是否符合用户操作权限配置方案，包括：

若所述第三Hive表为所述其他开发组发布的且所述操作类型为针对所述第三Hive表进行的读权限申请，则确定所述操作请求符合用户操作权限配置方案；

若所述第三Hive表为所述其他开发组发布的且所述操作类型为针对所述第三Hive表进行的写权限申请，则确定所述操作请求不符合用户操作权限配置方案，并反馈所述操作请求异常信息；

若所述第三Hive表为所述其他生产组发布的，则确定所述操作请求不符合用户操作权限配置方案，并反馈所述操作请求异常信息。

本实施例中当前开发组通过申请才能获取其他开发组发布表的读权限，保证了其他开发组发布表的数据安全。其中，第三Hive表也为其他生产组或其他开发组在权限申请平台上发布的表格，其可以是其他生产组或其他开发组创建的完整表格，也可以是完整表格中的部分字段。本实施例中，当前开发组只有申请其他开发组发布表读权限的资格，由于其他开发组发布表的写权限对应的操作维度值是其本身，因此，当前开发组没有申请其他开发组发布表写权限的资格。此外，当前开发组也没有申请其他生产组发布表读写权限的资格。

在上述各实施例的基础上，进一步的，若所述操作类型为针对第四Hive表的查询操作、修改操作和删除操作中的一种，则所述基于识别到的用户类型和所述操作类型，确定所述操作请求是否符合用户操作权限配置方案，包括：

基于所述操作类型和所述第四Hive表的权限配置，确定操作类型访问维度和操作类型访问维度值，其中，操作类型访问维度为所述操作类型对应的访问维度，所述操作类型访问维度包括全表读写维度、全表只读维度和字段只读维度中的至少一种；

确定所述操作类型访问维度值中是否包含所述用户对应的用户类型，若包含，则确定所述操作请求符合用户操作权限配置方案，若不包含，则反馈所述操作请求异常信息。

本实施例通过基于用户类型和操作类型验证用户是否拥有查询操作、修改操作和删除操作等的操作权限，可以保证系统数据安全。

示例性的，若操作类型为查询操作，则对应的操作类型访问维度包括全表读写维度、全表只读维度和字段只读维度，在确定所述操作类型访问维度值中是否包含所述用户对应的用户类型的过程中，对操作类型访问维度的鉴权顺序依次为全表读写维度、全表只读维度和字段只读维度，即先确定全表读写维度值中是否包含当前用户类型，若包含，则确定所述操作请求符合用户操作权限配置方案，若不包含，则确定全表只读维度值中是否包含当前用户类型，若包含，则确定所述操作请求符合用户操作权限配置方案，若不包含，则确定字段只读维度值中是否包含当前用户类型，若包含，则确定所述操作请求符合用户操作权限配置方案，若不包含，则反馈所述操作请求异常信息。

又示例性的，若操作类型为修改操作或删除操作，则对应的操作类型访问维度包括全表读写维度。确定所述操作类型访问维度值中是否包含所述用户对应的用户类型，包括确定全表读写维度值中是否包含当前用户类型，若包含，则确定所述操作请求符合用户操作权限配置方案，若不包含，则反馈所述操作请求异常信息。

在上述各实施例的基础上，进一步的，若所述用户类型为当前生产组，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置，包括：

在完成创建所述第一Hive表的操作之后，将所述第一Hive表的全表读写维度对应的全表读写维度值唯一设置为所述当前生产组，以授予所述当前生产组针对所述第一Hive表的全表读写权限；

将所述第一Hive表的全表只读维度对应的全表只读维度值设置为包括当前开发组，以授予所述当前开发组针对所述第一Hive表的全表只读权限。

为了方便开发组用户直接读取线上数据进行测试，在当前生产组完成创建第一Hive表的操作之后，在授予当前生产组针对第一Hive表的全表读写权限的同时，也授予当前开发组该表的全表只读权限。为了保障数据安全，当前开发组无权对当前生产组创建的第一Hive表进行修改，即当前开发组不能被授予全表读写权限。

示例性的，操作类型为在数据库db1中创建Hive表table1，用户类型为当前生产组GROUP2_PRO，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置可以包括：在完成创建相应table1之后，授予GROUP2_PRO针对相应table1的读写权限，其对应的访问维度为“db1.table1.-.rw”，访问维度值为GROUP2_PRO，同时，还可以授予GROUP2_DEV针对相应table1的只读权限，其对应的访问维度为“db1.table1.-.ro”，访问维度值为GROUP2_DEV。图3为本公开实施例提供的一种Hive表的权限配置示意图，如图3所示，Hive表db1.table1为非发布表，其有两个访问维度，分别为“db1.table1.-.rw”和“db1.table1.-.ro”，其对应的访问维度值分别为GROUP2_PRO和GROUP2_DEV。

在上述各实施例的基础上，进一步的，若所述用户类型为所述当前开发组，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置，包括：

在完成创建所述第一Hive表的操作之后，将所述第一Hive表的全表读写维度对应的全表读写维度值唯一设置为所述当前开发组，以授予所述当前开发组针对所述第一Hive表的全表读写权限；

禁止所述当前生产组针对所述第一Hive表的读写权限。

为了保障数据安全，当前生产组无法读取当前开发组下的数据，即当前生产组没有当前开发组所创建Hive表的读写权限。

示例性的，操作类型为在数据库db1中创建Hive表table1，用户类型为GROUP2_DEV，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置可以包括：在完成创建相应table1之后，授予GROUP2_DEV针对相应table1的读写权限，其对应的访问维度为“db1.table1.-.rw”，访问维度值为GROUP2_DEV，同时禁止GROUP2_PRO针对table1的读写权限。

在上述各实施例的基础上，进一步的，在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置，包括：

若所述用户类型为所述当前生产组，所述操作类型为针对所述第二Hive表进行的读权限申请，所述第二Hive表为其他生产组发布的，则在完成审批流程后，将所述第二Hive表的字段只读维度对应的字段只读维度值设置为包括所述当前生产组和所述当前开发组，以授予所述当前生产组和所述开发组针对所述第二Hive表的相同的字段只读权限；

或者，若所述用户类型为所述当前开发组，所述操作类型为针对所述第二Hive表进行的读权限申请，所述第二Hive表为其他开发组发布的，则在完成审批流程后，将所述第二Hive表的字段只读维度对应的字段只读维度值设置为包括所述当前开发组，以授予所述当前开发组针对所述第二Hive表的字段只读权限。

为了保障数据安全，在完成其他生产组发布表的审批流程的确认操作后，授予当前生产组针对发布表的字段只读权限，同时，自动授予当前开发组与当前生产组相同的权限，即针对发布表的字段只读权限。或者，为了保障数据安全，在完成其他开发组发布表的审批流程的确认操作后，授予当前开发组针对发布表的字段只读权限。

示例性的，操作类型为申请其他生产组GROUP1_PRO发布表table2中字段col1的只读权限，用户类型为当前生产组GROUP2_PRO，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置可以包括：在完成审批流程后，授予GROUP2_PRO针对相应table2中字段col1的只读权限，其对应的访问维度为“db1.table2.col1.ro”，访问维度值为GROUP2_PRO，同时，还可以授予GROUP2_DEV针对相应table2中字段col1的只读权限，其对应的访问维度为“db1.table2.col1.ro”，访问维度值为GROUP2_DEV。

或者，示例性的，操作类型为申请其他开发组GROUP1_DEV发布表table2中字段col1的只读权限，用户类型为当前开发组GROUP2_DEV，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置可以包括：在完成审批流程后，授予GROUP2_DEV针对相应table2中字段col1的只读权限，其对应的访问维度为“db1.table2.col1.ro”，访问维度值为GROUP2_DEV。

图4为本公开实施例提供的一种Hive发布表的权限配置示意图，该示意图中的Hive表为上述示例中当前生产组在数据库db1中创建的table1，并且当前生产组GROUP2_PRO将table1作为发布表发布在权限申请平台上，且其他生产组GROUP1_PRO申请了发布表table1中字段col1的只读权限，相应的，其他生产组GROUP1_PRO和其他开发组GROUP1_DEV同时获得了发布表table1中字段col1的只读权限。如图4所示，发布表db1.table1有三个访问维度，分别为“db1.table1.-.rw”、“db1.table1.-.ro”和“db1.table1.col1.ro”，其对应的访问维度值分别为GROUP2_PRO，GROUP2_DEV，以及GROUP1_PRO和GROUP1_DEV。

图5为本公开实施例提供的一种Hive表的权限整体架构示意图，如图5所示，针对生产组(可以是当前生产组，也可以是其他生产组)创建的Hive表，服务端自动授予相应开发组(若生产组为当前生产组，则相应开发组为当前开发组，若生产组为其他生产组，则相应开发组为其他开发组)全部可读权限。针对开发组创建的Hive表，服务端禁止相应生产组的读写权限。针对其他生产组创建的Hive表，当前生产组只能申请其他生产组发布表的只读权限，审批通过后，服务端授予当前生产组针对其他生产组发布表的只读权限，并自动授予当前开发组与当前生产组相同的只读权限。针对其他开发组创建的Hive表，当前开发组只能申请其他开发组发布表的只读权限，审批通过后，服务端授予当前开发组针对其他开发组发布表的只读权限。

在上述各实施例的基础上，进一步的，在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置，包括：

若操作类型为针对所述第四Hive表的修改操作，则在完成针对所述第四Hive表的修改操作之后，将所述第四Hive表的权限配置作为修改后的第四Hive表的权限配置；

或者，若操作类型为针对所述第四Hive表的删除操作，则在完成针对所述第四Hive表的删除操作之后，将所述第四Hive表的权限配置删除。

为了保障在对Hive表进行修改或删除后，生产组和开发组对应的权限不会发生错误，优选的，在完成修改操作和删除操作后，更新相应Hive表的权限配置。本实施例中，当前生产组对表进行修改时，该表的权限配置不会发生变换，因此修改后的Hive表的权限配置可以继承修改前Hive表的权限配置。在删除相应表的权限配置的过程中，对操作类型访问维度的删除顺序依次为全表读写维度、全表只读维度和字段只读维度，即先删除全表读写维度和对应的全表读写维度值，再删除全表只读维度和全表只读维度值，最后删除字段只读维度和字段只读维度值。

图6为本公开实施例提供的一种Hive表权限控制装置的结构示意图。本实施例用于执行上述任一实施例所述的Hive表权限控制方法，所述装置包括操作请求解析模块510、操作请求鉴权模块520、操作请求执行模块530和Hive表权限配置更新模块540，其中：

操作请求解析模块510，用于接收用户基于客户端发送的针对Hive表的操作请求并解析，确定所述操作请求对应的操作类型，所述操作类型包括查询操作或非查询操作；

操作请求鉴权模块520，用于基于识别到的用户类型和所述操作类型，确定所述操作请求是否符合用户操作权限配置方案，所述用户类型包括生产组或开发组；

操作请求执行模块530，用于若符合，则允许用户对相应Hive表执行所述操作请求对应的操作；

Hive表权限配置更新模块540，用于若所述操作类型为非查询操作，则在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置，其中，所述Hive表的权限配置包括相应Hive表的访问维度以及访问维度值，所述访问维度包括全表读写维度、全表只读维度和字段只读维度，所述访问维度值为拥有相应访问维度权限的用户。

本实施例利用操作请求解析模块接收用户基于客户端发送的针对Hive表的操作请求并解析，确定所述操作请求对应的操作类型，所述操作类型包括查询操作或非查询操作；利用操作请求鉴权模块基于识别到的用户类型和所述操作类型，确定所述操作请求是否符合用户操作权限配置方案，所述用户类型包括生产组或开发组；若符合，则利用操作请求执行模块允许用户对相应Hive表执行所述操作请求对应的操作；若所述操作类型为非查询操作，则利用Hive表权限配置更新模块在完成所述操作请求对应的操作之后，基于所述用户类型和所述操作类型，更新相应Hive表的权限配置，其中，所述Hive表的权限配置包括相应Hive表的访问维度以及访问维度值，所述访问维度包括全表读写维度、全表只读维度和字段只读维度，所述访问维度值为拥有相应访问维度权限的用户，上述基于用户类型和操作类型对用户的操作请求进行鉴权，保证了权限控制的全面性，通过自动识别到的用户类型，自动管理生产组和开发组的权限配置，无需高频申请操作即可实现生产开发权限隔离，同时在不扩大成本的基础上，保障了数据安全。

在上述各技术方案的基础上，进一步的，若所述操作类型为创建第一Hive表，则操作请求鉴权模块520具体可以用于：

基于所述用户类型确定所述用户是否拥有操作路径的操作权限，所述操作路径为所述操作请求中所包含的路径信息；

若是，则确定所述操作请求符合用户操作权限配置方案，若否，则反馈所述操作请求异常信息。

在上述各技术方案的基础上，进一步的，若所述用户类型为当前生产组，所述操作类型为针对第二Hive表进行的权限申请，则操作请求鉴权模块520具体还可以用于：

若所述第二Hive表为其他生产组发布的且所述操作类型为针对所述第二Hive表进行的读权限申请，则确定所述操作请求符合用户操作权限配置方案，其中，所述其他生产组对应的项目与所述当前生产组对应的项目不同；

若所述第二Hive表为其他生产组发布的且所述操作类型为针对所述第二Hive表进行的写权限申请，则确定所述操作请求不符合用户操作权限配置方案，并反馈所述操作请求异常信息；

若所述第二Hive表为其他开发组发布的，则确定所述操作请求不符合用户操作权限配置方案，并反馈所述操作请求异常信息，所述其他开发组对应的项目与所述当前生产组对应的项目不同。

在上述各技术方案的基础上，进一步的，若所述用户类型为当前开发组，所述当前开发组对应的项目与所述当前生产组对应的项目相同，所述操作类型为针对第三Hive表进行的权限申请，则操作请求鉴权模块520具体还可以用于：

若所述第三Hive表为所述其他开发组发布的且所述操作类型为针对所述第三Hive表进行的读权限申请，则确定所述操作请求符合用户操作权限配置方案；

若所述第三Hive表为所述其他开发组发布的且所述操作类型为针对所述第三Hive表进行的写权限申请，则确定所述操作请求不符合用户操作权限配置方案，并反馈所述操作请求异常信息；

若所述第三Hive表为所述其他生产组发布的，则确定所述操作请求不符合用户操作权限配置方案，并反馈所述操作请求异常信息。

在上述各技术方案的基础上，进一步的，若所述操作类型为针对第四Hive表的查询操作、修改操作和删除操作中的一种，则操作请求鉴权模块520具体还可以用于：

基于所述操作类型和所述第四Hive表的权限配置，确定操作类型访问维度和操作类型访问维度值，其中，操作类型访问维度为所述操作类型对应的访问维度，所述操作类型访问维度包括全表读写维度、全表只读维度和字段只读维度中的至少一种；

确定所述操作类型访问维度值中是否包含所述用户对应的用户类型，若包含，则确定所述操作请求符合用户操作权限配置方案，若不包含，则反馈所述操作请求异常信息。

在上述各技术方案的基础上，进一步的，若所述用户类型为当前生产组，则Hive表权限配置更新模块540具体可以用于：

在完成创建所述第一Hive表的操作之后，将所述第一Hive表的全表读写维度对应的全表读写维度值唯一设置为所述当前生产组，以授予所述当前生产组针对所述第一Hive表的全表读写权限；

将所述第一Hive表的全表只读维度对应的全表只读维度值设置为包括当前开发组，以授予所述当前开发组针对所述第一Hive表的全表只读权限。

在上述各技术方案的基础上，进一步的，若所述用户类型为所述当前开发组，则Hive表权限配置更新模块540具体还可以用于：

在完成创建所述第一Hive表的操作之后，将所述第一Hive表的全表读写维度对应的全表读写维度值唯一设置为所述当前开发组，以授予所述当前开发组针对所述第一Hive表的全表读写权限；

禁止所述当前生产组针对所述第一Hive表的读写权限。

在上述各技术方案的基础上，进一步的，Hive表权限配置更新模块540具体还可以用于：

若所述用户类型为所述当前生产组，所述操作类型为针对所述第二Hive表进行的读权限申请，所述第二Hive表为其他生产组发布的，则在完成审批流程后，将所述第二Hive表的字段只读维度对应的字段只读维度值设置为包括所述当前生产组和所述当前开发组，以授予所述当前生产组和所述开发组针对所述第二Hive表的相同的字段只读权限；

或者，若所述用户类型为所述当前开发组，所述操作类型为针对所述第二Hive表进行的读权限申请，所述第二Hive表为其他开发组发布的，则在完成审批流程后，将所述第二Hive表的字段只读维度对应的字段只读维度值设置为包括所述当前开发组，以授予所述当前开发组针对所述第二Hive表的字段只读权限。

在上述各技术方案的基础上，进一步的，Hive表权限配置更新模块540具体还可以用于：

若操作类型为针对所述第四Hive表的修改操作，则在完成针对所述第四Hive表的修改操作之后，将所述第四Hive表的权限配置作为修改后的第四Hive表的权限配置；

或者，若操作类型为针对所述第四Hive表的删除操作，则在完成针对所述第四Hive表的删除操作之后，将所述第四Hive表的权限配置删除。

本公开实施例所提供的Hive表权限控制装置可执行本公开实施例所提供的Hive表权限控制方法，具备执行方法相应的功能模块和有益效果。

下面参考图7，其示出了适于用来实现本公开任一实施例所述的Hive表权限控制方法的计算机设备400的结构示意图。本公开实施例中的计算机设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等。图7示出的计算机设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图7所示，计算机设备400可以包括处理装置(例如中央处理器、图形处理器等)401，其可以根据存储在只读存储器(ROM)402中的程序或者从存储装置406加载到随机访问存储器(RAM)403中的程序而执行各种适当的动作和处理。在RAM 403中，还存储有计算机设备400操作所需的各种程序和数据。处理装置401、ROM 402以及RAM 403通过总线404彼此相连。输入/输出(I/O)接口405也连接至总线404。

通常，以下装置可以连接至I/O接口405：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置406；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置407；包括例如磁带、硬盘等的存储装置408；以及通信装置409。通信装置409可以允许计算机设备400与其他设备进行无线或有线通信以交换数据。虽然图7示出了具有各种装置的计算机设备400，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上任一实施例所述的Hive表权限控制方法。

本实施例的计算机可读存储介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机可读存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

上述实施例的计算机可读存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的Hive表权限控制方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

此外，虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。