工作空间是DataWorks管理任务、成员，分配角色和权限的基本单元。
工作空间类型
简单模式工作空间
计算引擎实例仅包含一套环境，即开发和生产是同一套环境。
标准模式工作空间
计算引擎包含开发环境和生产环境两套环境。
工作空间规划实践工作空间规划可按照公司部门、公司业务或数仓层次进行规划，或综合三种维度进行混合规划：
| 细分 | 按部门划分 | 按业务划分 | 按数仓层次划分 |
|---|---|---|---|
| 划分依据 | 工作空间的划分可以与公司的组织架构相一致。例如：生产部、营销部、人力资源部、财务部等。各工作空间承载部门内部的数据开发需求，管理各自的数据表。 | 工作空间的划分也可以根据具体业务项目规划。例如：“季度销售冲刺战役”、“春季安全生产大检查”或“高管驾驶舱报表”等。各业务项目涉及多个横向部门，对接多个业务系统的数据，汇总加工，形成数据产出。 | 按照数仓的层级结构划分工作空间，每一层可以有独立的一个或多个工作空间。例如：“统一数据接入”、“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点）的调度资源组、引擎计算资源、数据集成资源组。
