在以往的分享中，给大家介绍了如何建表，写数据，查数据以及各种实操类，但是大家有没有发现，小编并没有介绍过，怎么给新用户或者子账号授权，这是为什么呢？本篇分享有点长，请耐心看完，保证你收获慢慢！

授权痛点

相信大家在使用各种大数据开发产品时，一定会遇见给子账号授权的场景，一个产品一套授权体系，如何给子账号授权，授什么权限比较好，如何简单快速的授权，成为开发人员经常面临的难题。
同样，在使用交互式分析时，初期也很难绕过权限的痛点，因为交互式分析兼容Postgres，使用与Postgres完全一致的权限系统。但典型的Postgres权限系统划分非常严格，在实际业务场景中使用时，业务人员想要给某个用户授权，需要执行大量的授权语句。
例如，新建一个DB，并给用户授予DB级别的管理员，PostgreSQL标准的授权语句如下：

CREATE DATABASE autonavi_ridesharing; CREATE ROLE autonavi_ridesharing_owner; ALTER DATABASE autonavi_ridesharing OWNER TO autonavi_ridesharing_owner; CREATE USER "xxxx" CREATEROLE; \c autonavi_ridesharing REVOKE ALL ON DATABASE autonavi_ridesharing FROM public; GRANT CREATE ON DATABASE autonavi_ridesharing to autonavi_ridesharing_owner; GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO autonavi_ridesharing_owner WITH GRANT OPTION; GRANT USAGE ON SCHEMA public TO "xxxx" WITH GRANT OPTION; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL ON TABLES TO autonavi_ridesharing_owner; GRANT CONNECT ON DATABASE autonavi_ridesharing TO autonavi_ridesharing_owner WITH GRANT OPTION; GRANT SELECT,INSERT,UPDATE ON ALL TABLES IN SCHEMA hologres TO PUBLIC; GRANT SELECT,INSERT,UPDATE ON ALL TABLES IN SCHEMA hologres TO "xxxx" WITH GRANT OPTION; GRANT USAGE ON SCHEMA hologres TO PUBLIC; GRANT USAGE ON SCHEMA hologres TO "xxxx" WITH GRANT OPTION; GRANT autonavi_ridesharing_owner TO "xxxx"; 

不同的角色有不同的权限，在操作上非常繁琐，有时也会出现某条授权语句遗漏导致某个权限缺失的情况。同时，每新增一个用户就需要执行相同的批量授权语句，浪费大量时间。尽管提供了大家常用授权语句的参考，但还是有很多朋友觉得晦涩难懂，操作极其不便。

为解决以上业务痛点，交互式分析在Postgres权限的基础上，结合多个业务的整体权限体系，设计实现了一种粗粒度的简单权限模型（Simple Privilege Model, SPM）。
简单权限模型以DB作为维度，在老版本的交互式分析中会默认不打开，可根据业务需要由superuser自行打开。
在新版本的交互式分析中，会默认打开权限模型，但也可以由superuser自行关闭，各取所需。

简单权限模型介绍

可参照以下两张图理解简单权限模型：
1.当前实例内的对象（实例、数据库、表、视图）的层级关系：

2.简单权限模型下实例内的角色层级关系以及每个角色对应的权限参照。

简单权限模型角色介绍

下面对简单模型下每个角色进行细致的说明：

以下角色的权限以及限制只有在简单权限模型开启时才生效。
db_admin可以是某个用户，也可以是某个用户组（即很多用户在同一个DB下都是db_admin）
db_schema_developer可以是某个用户，也可以是某个用户组
和db_schema_viewer可以是某个用户，也可以是某个用户组

superuser

• 申请实例的账号会被系统默认为该实例的管理员，即superuser，拥有整个实例的所有权限。
• 可对某个DB关闭或者开启简单权限模型。
• 在简单权限模型开启下，可管理db_admin，db_schema_developer和db_schema_viewer的用户及用户组，但不可对这3个用户组做任何权限修改，也不能再新增用户组。
• 在简单权限模型开启下，不可使用有封禁限制的功能（见下文简单模型功能限制）
• 除了特定的权限（见下文简单权限模型的权限概览），无其他权限。
  

_admin

• 某个数据库（DB）的管理者，但是没有删除该DB的权限。
• 可管理当前DB下db_admin、db_schema_developer和db_schema_viewer的用户及用户组，包括新增、删除某个用户至上述的3个用户组。
• 可对该DB的逻辑对象进行增删改，例如增删改schema，修改db等。
  

__developer

• 某个DB下某个schema（默认为public schema）的开发者。
• 某个DB开启了简单权限模型后，每创建一个schema，会自动创建developer用户组。
• 是当前schema下所有表的管理者。
• 对schema有读写、创建、修改和删除表/类表对象的权限。
  

__viewer

• 某个DB下某个schema （默认为public schema）的成员。
• 某个DB开启了简单权限模型后，每创建一个schema，会自动创建viewer用户组。
• 只能读取schema下所有表/类表对象的数据，即SELECT权限。
  

wilduser

• 没有加入以上任何用户组的用户，即为野用户。
• 在某个DB开启简单权限模型之后，访问该DB时，会没有连接权限。
• 如需访问某个DB，需要db_admin或superuser授权。

了解完简单权限模型，是不是觉得顿时打开新世界的大门？在下期分享中，小编将会为您介绍，如何执行一条命令语句就能完成所有授权。若您在使用过程中，有任何问题，欢迎加入钉钉群咨询。