专区不等于自治:公共数据专区从资源隔离走向权责闭环

2026-08-11

0
0

业务部门分到一个"专区",却没有自主管理权。内部小组的数据权限全靠平台手工开账号,一个字段过滤要提工单等三天。这不是"不好用"的问题——是当前通行做法在"聚数据"阶段够用,到了"用数据"阶段,权责管控能力需要跟上。

一、发展历程:集中统筹是阶段产物,架构需随阶段迭代

数据平台建设分为两个核心阶段,集中统筹模式的适配性随建设重心切换发生根本变化,当前困境并非建设失误,而是阶段迭代带来的架构升级需求。

2018-2022年是数据归集筑基阶段,核心目标是“聚数据”。此时各业务单元数据分散、标准混乱,集中统筹是最优建设模式:通过单一归口部门制定统一标准、统筹推进落地,快速完成全域数据库归集、编目与整合。若初期放开自主建设,各单元标准不一、规范各异,全域数据汇聚将无法实现。

2023年至今,全域数据归集工作基本完成,建设重心不可逆转向数据应用阶段,核心目标从“聚数据”变为“用数据”。集中统筹模式的瓶颈全面凸显:各业务单元数据需求、加工逻辑、权限诉求差异极大,少量平台运维人员需服务数十个业务单元,工单审批周期长达数周。同时运维人员缺乏业务认知,权限审批机械僵化,严重制约数据应用效率。

综上,集中统筹适配数据归集的效率需求,但在数据应用阶段,仅靠资源汇聚已无法支撑业务发展,必须在现有基础上补齐权责管控、域内自治能力,完成架构迭代升级。

二、当前通行做法:资源分区成型,权责体系严重滞后

目前各地大数据平台、集团数据中心的业务单元专区,普遍采用“独立建库+手工开账号”的落地模式,流程简单粗放。

第一步,运维人员登录数据库集群,为业务单元创建独立Schema或数据库实例;

第二步,通过手工SQL命令创建用户、逐条授予库表权限。平台前端的专区菜单仅为可视化外壳,无自主权限管理模块,所有权限开通、变更、回收均依赖运维底层操作。

部分厂商升级方案实现了计算、存储资源隔离,但权限中心仍为全局统一模式,属于半优化状态。业务单元管理员无法自主创建内部角色、配置细粒度行列权限、发起内部审批,自治能力完全缺失。当前三类落地方案核心差异如下:

能力维度

方案A:独立库+手工账号(主流)

方案B:独立计算资源+全局权限

方案C:自治多租户专区(优化方向)

底层实现

独立库表+SQL手工授权

独立计算资源池+全局权限中心

专属隔离环境+域内自治体系

权限管理

运维手工操作授权

平台统一分配角色

域内自主细粒度授权

治理能力

无独立治理规范

无独立治理规范

专属数据标准与治理规则

开发环境

开发、测试、生产混跑

无独立沙箱环境

Dev/Prod双沙箱隔离

审批时效

1-3天工单审批

半天-1天平台审批

域内即时闭环

跨域共享

不支持

不支持

受控跨租户授权共享

当前模式的核心问题是仅完成资源分区,权责体系未同步配套,直接引发两大核心问题。一是运行卡顿、资源争抢,全域集群算力共用,单业务单元大规模ETL操作会导致全局查询超时,无租户缓存机制,页面加载效率极低,混跑模式进一步加剧资源冲突;二是权责悬空、追责困难,业务单元承担数据安全主体责任,却无任何自主权限管控能力,所有操作依赖平台运维。一旦发生数据安全事件,平台与业务部门权责模糊、互相推诿,监管追责链条断裂。

三、核心概念厘清:破除认知混淆,明确升级内核

3.1 专区与授权运营域

“公共数据专区”无全国统一官方定义,相关旧政策已废止。上海最新规范以公共数据授权运营域为标准术语,核心是依托统一数据底座,搭建具备资源登记、运营管理、开发利用、安全监管的专属运营环境。

各地工程实践中的传统专区,仅实现存储、计算资源的简单隔离,缺失独立权限管控与自主运营能力,只是形式上的资源分区。从“专区”到“授权运营域”的迭代,核心是从“资源隔离”升级为“权责匹配、自主运营”,可通俗类比:传统专区是物业管控的储物间,权限全在平台;授权运营域是独立楼层,业务单元自主管理内部事务,平台仅负责全局监管与跨域统筹。

3.2 主题库与专题库

二者是数据应用的两级核心载体,维度与权责完全不同。主题库为平台主租户统筹建设的公共基准数据库,由全域数据归集治理而成,口径统一、标准通用,面向所有业务单元提供只读服务,是全域共享的“原料库”。专题库是业务专区租户基于主题库公共数据,融合自有业务数据、外部数据自主加工生成的专项成果数据,由业务单元自主管控,支撑专属业务分析与应用,是各单元的“成品库”。

主题库

专题库

建设位置

主租户中

本质

公共基准数据集(DWD 层标准化明细数据)

数据来源

全域归集 + 统一治理的公共数据

管控主体

平台(主租户)统一治理

读写权限

所有租户仅可查询读取,不可修改

3.3 两类多租户架构

多租户是专区的底层核心架构,分为传统多租户与自治多租户,能力差距显著。传统多租户仅实现登录与数据基础隔离,无独立账号体系、审批流程、沙箱环境,所有规则由平台统一管控,无域内自治能力。自治多租户则在基础隔离之上,搭建闭环的域内运营体系,拥有独立权限、治理规则、双沙箱环境与审批链路,平台仅保留全局底座管控、跨域审计权限,可实现安全与效率平衡。

四、政策标准依据:租户自治是合规落地的必然要求

租户隔离与域内自治并非冗余优化,而是落实数据安全法规、政策制度的必要工程前提,具备完善的顶层依据与技术标准。

4.1 落实数据安全权责一致要求

国办发〔2022〕32号文、《数据安全法》均明确“谁主管、谁负责,谁使用、谁负责”的安全责任制。传统模式下,业务单元承担数据安全责任,却无权限管控能力;运维掌握操作权限,却不承担业务安全风险,权责主体完全割裂。唯有搭建域内自主授权体系,才能让业务主体真正掌控数据权限,实现权责匹配、责任可溯。

4.2 满足分级授权合规规范

《数据安全法》《网络安全法》要求数据处理者落实分级授权、全程留痕、安全防护等制度。集团统一制定合规基线与数据分级标准,各业务授权域搭建独立的资产管控、权限授权、审批链路,实现“标准统一、分区自治、审批隔离”,完全契合分级授权的合规要求。

4.3 契合授权运营域建设导向

上海沪府办发〔2025〕15号文明确的授权运营域模式,与企业数据平台自治多租户架构高度契合,确立了“统一底座+域内自主运营”的建设范式,为业务专区自治升级提供了直接政策参照。

4.4 符合国标技术架构标准

GB/T 36326-2018《政务云多租户架构设计》明确了多租户在计算、存储、网络、安全的基础隔离要求。本文提出的自治多租户,是在国标基础隔离能力之上的工程升级,在满足安全底线的同时,解决了传统架构运营效率低、权责不匹配的核心痛点。

五、传统“伪专区”的核心成因

当前行业普遍存在的传统数据专区,仅为逻辑分区,无真实隔离与自治能力,属于典型的“伪专区”,根源分为制度与技术两大层面。

5.1 制度层面:集中代管模式适配性失效

平台建设初期,业务部门数据治理能力薄弱,平台集中代管模式有效降低了业务操作门槛,保障了数据治理整体质量。但随着智能化治理技术普及,业务部门已具备自主开展数据编目、加工、授权、审批的能力。传统集中代管模式过度集权,压制了业务自主治理积极性,导致优质业务数据归集意愿低,严重束缚数据价值释放。同时,权限下放并非放任管理,所有操作全程留痕、可审计、可监管,兼顾灵活赋能与全局安全。

5.2 技术层面:缺失原生多租户架构支撑

多数传统大数据平台无成熟原生多租户底座,无法搭建权责清晰、完全隔离的专属运行环境,只能通过简单账号、分类规则模拟专区形态。这类伪专区仅有隔离形式,无独立资产目录、权限体系、审批链路与加工环境,从技术根源上无法实现域内自治。

六、核心改进方向:从资源分区到权责闭环

架构升级无需推翻现有体系,核心是在资源隔离基础上,补齐独立权限体系与自主加工环境两大核心能力,构建“平台统筹监管+域内自主运营”的全新模式。

6.1 域内独立细粒度权限体系

各专区搭载独立权限子系统,依托全局统一身份源同步人员信息。域内管理员可自主搭建内部组织角色,实现库、表、行、列四级细粒度授权,支持权限有效期自定义、到期自动回收。平台保留跨域流转审批、全局安全审计、资源配额管控核心权限,实现权责闭环。

6.2 全链路自主数据加工环境

专区内置ODS归集、DWD治理、ADS聚合全层级加工链路,可复用平台公共主题数据,也可导入自有数据自主清洗、融合、建模。产出的专题资产可内部复用,也可同步至公共资产门户,经审批后对外共享,项目结束可精准销毁对应数据,实现全生命周期管控。

6.3 沙箱环境分离,规避资源风险

采用“统一归集沙箱+Dev/Prod业务双沙箱”模式,开发环境使用样本数据测试建模,发布生产时自动切换真实数据,彻底隔离开发、测试、生产环境,杜绝资源混跑冲突,保障平台运行稳定。

能力维度

当前通行做法

自治多租户专区

权限管理

运维SQL手工授权,全局单例

域内独立RBAC,四级细粒度(库/表/行/列)

治理规范

无独立治理能力

独立数据标准、质量规则、分类分级

数据加工

仅数据查询,无独立加工链路

ODS→DWD→ADS完整分层,自主融合建模

开发环境

Dev/Prod混跑,资源争抢

独立双沙盒分离,Dev用样本/Prod用真实

数据生命周期

项目结束数据残留

项目回收对应库直接销毁

审批时效

1~3天(跨部门工单)

即时生效(域内闭环)

跨域共享

不支持

受控跨租户数据授权共享

责任归属

平台与部门互相推诿

业务单元数据负责人为第一责任人

平台管控

集中在运维层,审批瓶颈

上升至监管层:跨域审计、流转审批、资源配额

6.4 主租户与专区租户协同架构

全新架构形成清晰分工体系:主租户聚焦“聚、统、管”,持续完成全域数据归集治理、主题库建设、全局合规管控与跨域流转审批;专区租户聚焦“用、产、治”,自主加工专题数据、开展业务赋能、落实域内安全治理;公共资产门户作为统一收口层,实现编目自动汇集、资产全域可见、API统一注册审批,保障全局数据资源不遗漏、不分散、不混乱。

七、落地破局建议:化解阻力,稳步推进升级

架构升级的核心阻力并非技术问题,而是平台方的管控焦虑、问责顾虑和体验无感问题,可通过三大策略突破。

一是依托制度合规推进,摒弃无效争论,聚焦数据安全责任制、分级授权、授权运营域等法定要求,明确升级是运维权限上移为监管权限,而非削弱平台统筹职能,夯实合规依据。

二是开展试点落地验证,选取数据需求旺盛、业务场景成熟的单元搭建自治专区,跑通自主加工、授权应用全链路,用“审批时效大幅提升、专题资产增量增长”的实际成果凝聚共识。

三是优化表述降低阻力,替换“分权”“割据”等敏感表述,统一使用“授权运营域”“数据自主运营空间”,聚焦权责匹配、合规落地、效率提升,降低推广阻力。

八、总结

数据平台建设已全面从归集阶段迈入应用阶段,传统集中统筹、简单资源分区的模式,已无法适配数据安全合规要求与业务赋能需求。当前架构升级无需颠覆现有体系,核心是基于现有资源隔离能力,补齐域内独立权限管控与全链路数据加工能力。

制度层面,数据安全权责一致、分级授权、授权运营域的政策要求,构成了升级的顶层依据;技术层面,多租户国标规范与成熟工程实践提供了落地路径。升级后可实现“平台全局统筹监管、业务域内自主运营”的平衡,彻底解决审批卡顿、权责悬空、追责困难等行业痛点,真正释放数据要素价值,是数据平台高质量发展的必然选择。

参考依据:《全国一体化政务大数据体系建设指南》(国办发〔2022〕32号)、《数据安全法》第二十七条、《网络安全法》第二十一条、《北京市公共数据专区授权运营管理办法(试行)》(京经信发〔2023〕98号,已于2026年7月废止)、《上海市公共数据资源授权运营管理办法》(沪府办发〔2025〕15号)、政务云多租户架构设计国家标准(GB/T 36326-2018)

标签:#数字政府 #政务大数据 #数据安全 #授权运营 #一体化大数据平台

上海奥腾计算机科技有限公司,让数据同频,与城市共进。