本文介绍DataWorks的工作空间体系,以及适用于不同场景的工作空间划分方案。

什么是工作空间

工作空间是DataWorks管理任务、成员,分配角色和权限的基本单元。工作空间管理员可以加入成员至工作空间,并赋予工作空间管理员、开发、运维、部署、安全管理员或访客角色,以实现多角色协同工作。

一个工作空间支持绑定MaxCompute、E-MapReduce和实时计算等多种类型的计算引擎实例。绑定引擎实例后,即可在工作空间开发和调度引擎任务,并管理引擎中存储的数据。

在工作空间内部,提供“空间管理员”、“部署”、“开发”、“模型设计师”、“访客”、“项目所有者”、“运维”、“安全管理员”这几种成员角色设定,每种角色有不同的权限。

工作空间类型

DataWorks提供简单模式和标准模式两种类型的工作空间:
  • 简单模式工作空间
    简单模式工作空间包含的每一个计算引擎实例只能有一套环境,无法区分开发和生产环境,只能进行简单的数据开发,且无法对数据开发流程和表权限进行强控制。
    • 优点:简单直观、迭代快,代码提交后,无需发布即可生效。
    • 缺点:开发角色权限过大,可以随意删除本工作空间下的表,存在数据安全风险。
    在简单模式工作空间中,任务实际的执行身份可以选择为“任务负责人”或“阿里云主账号”,生成数据的所有者也因此设定而不同。
  • 标准模式工作空间

    标准模式工作空间包含的每一个计算引擎实例都包含两套环境,分别为开发环境和生产环境。同时,可以基于角色定义用户权限,开发人员仅能操作开发环境中的数据和任务脚本,而运维人员仅能操作生产环境的任务脚本,所有人均无法直接访问生产环境的数据。各种角色相互监督相互保证,确保项目符合数仓管理规范。

    同时,标准模式的工作空间可以严格控制表权限,禁止随意操作生产环境表的行为,保证生产表的数据安全。

    • 优点:权限、流程规范化管理,保障数据安全和代码安全。
    • 缺点:需额外创建用于开发的计算引擎实例环境,权限和角色模型存在理解成本。
    在标准模式工作空间中,开发、生产环境的任务执行身份有所不同:
    • 开发环境:锁定为“任务负责人”。
    • 生产环境:可以选择通过“阿里云主账号”或指定的“RAM账号”身份运行调度任务。

工作空间权限模型

DataWorks各主要模块针对工作空间的权限隔离设定有所不同:
功能模块 权限模型
工作空间管理 不同的工作空间的是完全隔离的。
不同的工作空间可以有不同的管理员、不同的内部成员,各工作空间拥有完全独立的成员角色设定以及引擎实例的各项参数开关。
说明 所有工作空间的所有者账号均为阿里云主账号。
数据开发(DataStudio) 各工作空间之间的数据开发工作是完全隔离的。
  • 工作空间之间的业务流程、任务节点独立开发,互不影响。
  • 在工作空间内部:
    • 仅“开发”、“管理员”角色的成员具备创建、编辑、删除任务节点的权限。
    • 仅“开发”、“运维”、“管理员”角色具备提交发布包的权限。
    • 仅“运维”、“部署”、“管理员”具备正式发布的权限。
说明 任务节点的调度依赖是可以跨工作空间配置的。
任务运维 各工作空间之间的任务运维是部分隔离的。
  • 实时/周期/手动任务运维:在工作空间间隔离,并且只有在对应工作空间内具备“开发”、“运维”或“管理员”角色的成员才有权限操作。
  • 运维大屏:工作空间间隔离,运维大屏显示工作空间内任务运行的汇总数据,任务运行情况一览便知。
  • 智能监控:在工作空间间打通,智能监控可以设定跨工作空间的监控基线。仅阿里云主账号、工作空间管理员具备创建智能监控基线的权限。
数据地图 各工作空间之间的数据地图是租户内共享的。
在数据地图中,搜索和展示的范围均为当前租户、当前Region下所有工作空间的元数据。
说明 仅数据地图中展示的元数据全局共享,实际的数据读、写权限并非共享。通常来说,开发环境的数据读、写权限为各工作空间的“开发”角色共享,而生产环境的数据权限为生产账号独有
数据质量 各工作空间之间的数据质量是完全隔离的。

仅对应工作空间的“开发”、“运维”或“管理员”角色具备配置数据质量规则的权限。

数据服务 各工作空间之间的数据服务是部分隔离的。

各工作空间会共享服务分组的定义,但是注册或发布的服务API仅在当前工作空间可见。

数据保护伞 各工作空间之间的数据保护伞是全局共享的。

所有工作空间共享一套数据安全策略和敏感数据目录。若数据保护伞的“高级安全模式”开启,则只有各工作空间的“安全管理员”具备操作数据保护伞的权限。

通用准则

无论采用何种维度规划创建工作空间,建议遵循以下通用准则:
  • 工作空间命名方式统一,包含明确的业务含义任务节点名称包含工作空间名称缩写,便于快速识别。
  • 工作空间应由主账号或“组织管理员”创建,并委派“工作空间管理员”。原则上任何人不应同时具备“开发”、“运维”角色。

工作空间规划实践

工作空间规划可按照公司部门、公司业务或数仓层次进行规划,或综合三种维度进行混合规划:
细分 按部门划分 按业务划分 按数仓层次划分
划分依据 工作空间的划分可以与公司的组织架构相一致。

例如:生产部、营销部、人力资源部、财务部等。各工作空间承载部门内部的数据开发需求,管理各自的数据表。

工作空间的划分也可以根据具体业务项目规划。

例如:“季度销售冲刺战役”、“春季安全生产大检查”或“高管驾驶舱报表”等。各业务项目涉及多个横向部门,对接多个业务系统的数据,汇总加工,形成数据产出。

按照数仓的层级结构划分工作空间,每一层可以有独立的一个或多个工作空间。

例如:“统一数据接入”、“ODS层”、“数仓汇总层”等。

适用场景 部门业务单一,部门内部人员具备开发能力,数据共享场景较少,单一部门即可完成端到端业务开发。 业务优先的攻坚项目,多部门联合项目。 大型数仓,企业数仓公共层,数据中台。
优点 工作空间成员与组织架构一致,人员最稳定,数据安全性最高。同时计算、存储成本归属清晰。 工作空间内业务专一,人员可根据业务动态调整,数据链路清晰,易运维。 数据架构清晰,共享便利,人员开发技能要求单一,可根据各层特性分配不同资源。
缺点 容易形成数据烟囱,数据重复计算、重复存储,跨空间依赖复杂,资源易争抢。 数据架构不清晰,各业务口径不一致,工作空间内人员复杂,数据安全风险高。 开发周期长,运维链路长,标准模式下上层任务正式发布前需要修改代码。
架构稳定性 ★★★★★ ★☆☆☆☆ ★★★★★
人员灵活性 ★☆☆☆☆ ★★★★★ ★★★★☆
业务复杂度 ★★☆☆☆ ★★★★☆ ★★★☆☆
数据安全 ★★★★★ ★★☆☆☆ ★★★☆☆
可运维性 ★★☆☆☆ ★★★★★ ★★☆☆☆
数据共享 ★★★☆☆ ★☆☆☆☆ ★★★★★
以上三种划分模式可以混合使用,以综合各自优点。一种常用的混合策略是整体按数仓层次划分,但各层内部并非单一工作空间,而是进一步划分为多个工作空间。
  • 数据接入层(STG):按应用系统划分,例如“stg_营销系统”、“stg_生产管理系统”等。
    • 任务节点:只有数据集成任务。
    • 数据表:只有原始数据,生命周期短。
    • 空间成员:各应用系统的DBA。
    • 资源倾斜:数据集成资源组、存储空间。
  • 数据清洗层(ODS):按部门划分,不同部门内数据统一口径,清洗掉不宜公开的数据,例如“ods_人力资源部”、“ods_生产部”等。
    • 任务节点:只有单一输入、单一产出的SQL任务。
    • 数据表:ODS层表。
    • 空间成员:各部门委派的数据清洗人员。
    • 资源倾斜:时间靠前的(例如0点~2点)的调度资源组、引擎计算资源。
  • 数仓整合层(DW):整合为一个统一的工作空间,或按照业务域划分,例如“dw_客户域”、“dw_商品域”等。
    • 任务节点:只有多输入、单一产出的SQL任务。
    • 数据表:DW层事实表、维度表。
    • 空间成员:数据公共层专职开发人员。
    • 资源倾斜:中期(例如2点~5点)的调度资源组、引擎计算资源、存储空间(应对数据膨胀)。
  • 标签数据层(TDM):整合为一个统一的工作空间,或按照业务对象划分。
    • 任务节点:只有多输入、单一产出的SQL任务。
    • 数据表:标签表。
    • 空间成员:数据公共层专职开发人员。
    • 资源倾斜:中晚期(例如5点~7点)的调度资源组、引擎计算资源、存储空间(应对数据膨胀)
  • 应用数据层(ADS):按业务划分,针对各专项业务,建立独立工作空间。
    • 任务节点:SQL任务、数据集成任务。
    • 数据表:以满足业务场景为优先。
    • 空间成员:项目组成员。
    • 资源倾斜:晚期(例如7点~9点)的调度资源组、引擎计算资源、数据集成资源组。