规划工作空间

本文介绍DataWorks适用于不同场景的工作空间规划方案。

工作空间权限模型

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点)的调度资源组、引擎计算资源、数据集成资源组。