DataWorks百問百答37：DataWorks-MaxCompute權限體系有哪些混淆點？

背景

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空間內移除，則會報錯用戶不存在與項目內：