数据平台工作空间设计简述

1. 背景概述

为了支持更多的数据分析师参与到公司整体的数仓建设和数据开发、数据分析工作；加快公司整体的数据资产化进程和支持商家侧数据的客群分析、精准营销等产品功能。提高公司各业务部门的数据开发效率和数据可视化分析能力。

1. 逻辑架构

上图中:

1. 数据源管理系统进行数据源实例级别的隔离；
2. 数据集成开发进行数据同步到数据仓库层，保证逻辑数据空间的数据库表的权限隔离；
3. 数据开发中的离线和实时开发对数据仓库间进行受控的数据权限分享控制，支持数据表行列级权限的控制；
4. 任务提交运行后，资源组管理系统对开发组内的任务进行独立执行队列的隔离控制，同时进行计算资源的成本统一结算；
5. 数据仓库分析完成的应用层数据，对接数据服务层；在同一个工作空间内，完成数据可视化开发和数据API开发控制；

从而达成从下向上的全链路逻辑工作空间的隔离和权限管控；下文将逐个子系统进行改造或改进点的阐述。

1. 用户权限

在加入开发组的空间管理功能后，用户视角下有以下调整:

对于上文描述的数据集成任务开发、数仓开发等场景下，用户由原来的单平台层面的操作逻辑调整为在开发组内进行隔离操作的。此外，新增的流程控制包括: 开发组的加入和管理流程，数据表权限获取等审批流程，开发组内的任务操作和管理审批流程，开发组间数据分享的审批流程等。

开发组角色设置逻辑表现为: 权限管理系统后台设置3个表: 角色表、用户表、用户角色关联表；其中，用户角色关联表包含具体角色对应的用户所属开发组等层级信息，比如，用户A同时具有"开发组1的开发者"和"开发组2的管理员"两个角色。

整体权限模型, 如下图所示:

对上图，解释如下:

1. 数据表权限申请

具体任务使用数据源，任务操作具体数据库表的权限申请，维护任务和数据源的访问绑定关系。用户个人进行业务数据查看编辑操作权限的申请，主要针对即席分析，快速查数的业务场景。

1. 开发组角色权限申请

加入开发组申请，任务提交发布申请等；加入对应的业务线和项目，进行任务和调度的管理；设置任务本身的操作编辑查看运维权限。

1. 平台角色权限申请

全局级角色：为租户内设置的，对应做相应的开发组管理，用户中心，数据地图等功能模块。

开发组级角色: 为绑定各个子系统进行申请，但是整体预设的角色是固定的；各个子系统模块，对同一个预设角色的权限点设置不同；会分别保存对应菜单权限到权限后台管理系统中。

对于用户的权限检验部分，先进行功能权限的判断，然后，再进行数据权限的判断；两个为逻辑且的关系；最后，判断用户是否具有权限资源的操作许可。

1. 权限控制

从用户进行权限申请通过后，在工作空间内，从任务和资源编辑使用权限，到任务执行部分的账号和依赖管理控制，以及任务提交后的调度队列控制；底层是数据源和数据表的权限管理两个系统。

大体权限控制流程，如下：

上图描述，在开发组改造后，整体数据流转流程：

1. 用户登录数据平台门户页，需要加入获取所属开发组信息；进行数据源查看和绑定使用；
2. 开发者进入数据平台其他子系统的使用时，获取到具体所属的开发组信息；在对接数据源进行任务绑定开发的时候，查询数据源管理系统进行所属开发组权限和个人申请授权校验，以及触发使用申请审批；
3. 进行数据集成等系统使用时，也是基于数据源所属开发组，配置Sink到ODS的数据源权限绑定到对应的开发组内；从而，完成数据集成系统和ODS层数据归属的绑定。
4. 进行离线或实时开发任务创建时，基于上游层的hive数据权限获取，走开发组间申请和授权流程；从而，保证数仓任务开发的仓内权限隔离。

1. 数据开发执行

为了保证上文所述的整体执行权限账号的统一，对于数据开发系统，要由原来的单一执行账号修改为每个开发组的执行账号。首先，由开发组管理系统进行执行账号的映射管理，然后在任务资源和任务调度执行部分都受开发组的权限控制。此外，最后同步账号到底层集群的执行层。

具体的各系统间的执行流程，如下图所示:

上图主要包括: 数据任务的编辑开发和任务调度的编排，以及任务运行执行等；以及任务运行所依赖的文件管理、依赖库管理、运行的镜像管理等资源；

该部分的重点改造点为:

1. 任务开发阶段: 对各开发组的任务的查看、编辑和发布权限，约束在开发组内的工作空间内，而且空间内可以进行人员权限的分配管理；实现开发组内管理可以进行整体项目开发的管理和运营工作；
2. 任务发布阶段: 对任务依赖的执行文件、执行环节、执行资源等都在工作空间可配置，保证了整体任务资源和文件函数等资源被受控执行。
3. 任务运行和执行阶段: 运行时，每个开发组使用自身对应的计算运行账号进行运行，每个开发组对应的执行账号都只可以读写对应被授权的数据库表(以本开发组的库表为主)。

1. 资源组管理

对于任务发布之后，任务需要进入大数据集群进行任务的调度队列进行运行，基于总成本的考虑，当前，各个开发组的运行物理集群为同一个，此时，除了公共的Master节点等资源外，对于纯计算资源，我们利用Yarn原生自带的执行队列功能进行开发组间的隔离；此外，对于部分离线开发任务，进行任务模板对应的镜像管理，便于在K8S集群直接运行相应的任务等。

整体上，资源组管理系统为用户封装了底层的物理差异，统一将运行资源定义为"资源组"，该资源组也是配置在对应的开发组上进行使用的，各开发组之间可相互隔离设置；用户可以自己进行资源组的新建和扩缩容申请。

资源组系统和数据源系统和底层集群系统的整体层级架构，如下图所示:

整体数据流程为:

1. 在开发组内，用户在资源运维中，进行资源使用量的查看，在资源受限等场景下，提交新建和扩容资源组的申请；
2. 工单审批后，资源组管理系统将申请后获得的队列资源配置到对应的开发组；
3. 用户在具体的任务开发系统中，进行对应更新后资源组的查看和配置使用；
4. 具体的任务开发系统对接上资源组管理系统，将对应的任务提交时提交到对应的资源组。
5. 整体平台的各执行任务系统，都遵循该任务资源分配逻辑；同时，成本管理直接对资源组进行结算，及对接后续的资源任务治理等。

1. 迁移实施

由于进行该设计改造前，整体公司的数据开发都是基于整个平台进行的，所有数据任务包括：数据集成任务，数据开发任务，数据应用任务都是同一个空间进行管理的，或者是没有空间隔离，都是各个数据BI开发自己的任务，任务间没有强隔离；

为了达到数据表和任务级别的控制，需要进行原有任务的迁移，此外，为了解决各任务脚本的原有表的依赖，避免大量修改任务的工作量和操作风险，平台提供了整套迁移工具进行各开发组的任务迁移；目前整体迁移工作已完成。

1. 结果和规划

1. 完成了公司数据中心线上数据任务的100%任务业务方无感迁移；
2. 承接外部子公司的数据平台共建需求，达到数仓共建，资源共享，权限隔离的整体组合实时最大化；
3. 后期计划进行各个系统租户化改造，对接数据应用产品，租户化支持商家侧的数据分析和开发需求。

1. 参考

1. 管理控制台功能概览 - 大数据开发治理平台 DataWorks - 阿里云