背景
DataWorks是大数据引擎上层的一个数据开发、生产、治理平台，有自己一套完善的权限体系，但由于下层对接的引擎较多（MaxCompute、EMR、Blink等），因此用户常常对DataWorks权限、引擎权限产生混淆。
常见问题集锦
- DataWorks开发角色好像可以读写所有表，这岂不是很危险？
- [工作空间管理-权限列表]中的权限和引擎权限有什么关系？里面的表权限是针对所有引擎的吗？
- [工作空间管理-成员管理]与[工作空间管理-MaxCompute高级配置-自定义角色]中的角色到底有什么区别？
- ………………
说明
权限类型区分
DataWorks自身有一套权限体系，即[工作空间管理-权限列表]中所描述的内容。
这套权限体系和引擎的权限体系有什么区别？
很简单：[工作空间管理-权限列表]描述的是DataWorks本身功能的功能，如：XX用户（角色）可以创建数据源、新建节点、提交/编辑/发布节点、运维中心冻结/暂停/重跑等功能；而引擎权限描述的权限点则是对引擎的操作，如：XX用户（角色）可以读写某表（table_1）、设置引擎支持的数据类型、是否允许全表扫描等（可参考MaxCompute用户与权限管理）。
DataWorks权限与引擎权限的联系
【常见问题一】
既然DataWorks权限、引擎权限是有区别的，那为什么我将RAM子账号加入到[工作空间管理-成员管理-开发角色]中，就能访问MaxCompute的表了？
有如下几点特性来进行说明：
（1）DataWorks、MaxCompute内的权限主体（执行任务的身份）都是阿里云主/子账号。
（2）DataWorks本身的角色与MaxCompute之间的角色存在联动关系。
当一个阿里云RAM子账号被加入至DataWorks空间时，就会自动被加入至MaxCompute项目中。
例如：将某个RAM子账号（RAM_A）加入至DataWorks开发角色，则该子账号会被同时加入至该空间所绑定得到MaxCompute项目role_project_dev、role_project_scheduler两个Role中（这两个Role有在MaxCompute项目内启动任务、读写数据的权限），因此RAM_A即能进入DataWorks创建节点，也能通过节点运行代码读写MaxCompute上的表。
【常见问题二】
在开发环境、生产环境究竟运行任务的是谁？需要如何保证权限足够且合理？
（1）标准模式（一个DataWorks空间对应两个MaxCompute项目）
①开发环境：执行任务的身份为“任务执行者”，即：谁运行任务，身份就是谁。
在DataStudio、开发环境运维中心执行的任务将会下发到MaxCompute开发环境项目，同时，能够在开发环境运行任务的账号，也被自动加入了对应的MaxCompute Role，拥有了引擎相关权限，因此不必担心任务运行失败。
②生产环境：执行任务的身份可选择为主账号或固定的子账号；要注意，生产环境的MaxCompute项目除了主账号，没有自动加入过任何RAM子账号，因此如选择了子账号，页面会进行提醒并执行授权：
（2）简单模式（一个DataWorks空间对应一个MaxCompute项目）
与标准模式不同，简单模式提交即调度（无需发布）。
目前提供了两种访问身份模式：阿里云主账号、任务责任人（谁创建任务谁就为执行者）；如选择了任务责任人，则要保证对应任务的责任人角色权限足够，并避免子账号被删除、禁用等情况。
应尽量避免：
①子账号角色变更为无权执行任务的角色，如：“访客”、“运维”、“部署”“安全管理员”（这些角色在MaxCompute内对应的Role没有执行任务、读写数据的权限）。此时执行任务将提醒权限不够：
②子账号被从DataWorks空间内移除，则会报错用户不存在与项目内：
DataWorks百问百答历史记录 请点击这里查看>>
更多DataWorks技术和产品信息，欢迎加入【DataWorks钉钉交流群】
