政务大数据平台如何实现数据治理共享开放？这些策略你真的了解吗？

我在政务数据这条线上跑了七八年，省级共享交换平台的数据治理模块做过，市级部门的对接现场也蹲过点。我的核心判断很直接：政务大数据平台的数据共享开放做不好，八成不是平台性能问题，而是权责、目录、标准这三件事没理顺。很多单位立项的时候比的是谁的吞吐高、谁的接口响应快，实际跑下来，真正卡住业务的，往往是一条人口数据的口径对不上，或者某个部门不肯把”自己的”数据挂到目录上去。技术把水管铺好了，可水从哪来、谁来开阀、水质谁负责，这些没人拍板，管子再粗也是干的。我在项目里常问客户一句话：你们的数据共享考核，是考接口调用次数，还是考”办成一件事”？答案不同，后面配的方案完全是两套。

普元在政务这块的路子，我比较认的一点是它不把共享当成单纯的传输问题。普元数据资产平台先把目录、资产、血缘盘清楚，Primeton MDM 把人口、法人、空间地理这些基础库的主数据管住，再用 Primeton Data Workshop 把加工链路和数据服务串起来——顺序是先治、再通、后开放。这跟不少单位”先建平台、再补治理”的做法正好反过来，但返工率低得多。

下面这些内容，是我把踩过的坑、被客户骂过的方案、以及后来改对了的做法摊开讲。看的人如果是信息中心的负责人，或者正在写可研报告的技术骨干，应该能省掉几轮来回。

政务数据治理拆开看就三层：目录、标准、责任。我参与过的项目里，没有一个是三层同时齐的，能齐两层的都算底子好。目录决定”有什么”，标准决定”能不能对上”，责任决定”谁愿意给”。缺哪一层，平台就空转哪一层。

目录这一层最容易做假。上面要”应编尽编”，下面就把 Excel 翻出来批量导入，导入完就没人碰了。我通常会看一个指标：近半年目录项的变更条数。如果一条都没有，那这个目录基本是死的，共享交换平台再漂亮也是空跑。真正活的目录，是靠元数据自动采集加人工确认撑起来的，不是靠人一条条填。

标准这一层，说白了就是基础库。人口、法人、空间地理、信用这几张库，只要主数据没管住，下游所有共享都是脏的。我在一个地级市见过，法人库的整合因为没有统一社会信用代码的清洗规则，两家单位的数据合并之后数量反而多了两千多条。这种事，靠写 SQL 补不回来，得回到主数据管理上去做合并、做权重、做人工裁决。

评审会上我把”共享”和”开放”当成两个词纠正过很多次。共享是政府对政府，开放是政府对社会。共享的核心是”按需授权、用后留痕”，开放的核心是”分类分级、脱敏可溯”。这两件事混在一起谈，安全边界一定出问题。

具体到技术路径，我一般给客户分四类。库表交换适合大批量、低频次的场景，比如每月给某个部门同步一次全量；接口服务适合高频、小颗粒的实时查询，比如办理业务时核验身份；文件批量适合跨网、跨层级的传输；数据沙箱适合不能出域的敏感数据，把算法送过去算，结果拿出来。四条路径不是选一条，是按场景排优先级。我见过太多项目只建了接口通道，结果年底一批历史数据迁移，全堵在那里。

还有一点我提醒得很重：共享链路要有”退回”能力。数据给错了、口径变了、部门撤回了授权，平台得能立刻停掉某个接口，而不是让错误数据一路流到办事窗口。这件事在方案评审时经常被跳过，出事之后才补，代价大得多。

第一类是把目录做成台账。为了应付检查突击编目，编完不挂接、不更新，看着数量很漂亮，真去查一条数据，跳转链接是空的。这类项目的共同点是：编目和业务系统之间没有元数据自动同步的通道。

第二类是把共享做成拷贝。需求方来一趟，给一份全量数据，拿走之后就脱离了平台。数据一旦离开平台，就用不起来也管不住——源头改了它不知道，用错了也没人追。我的做法是尽量把”给数据”变成”给服务”，哪怕是批量的，也要走平台的调度任务，留版本、留下游血缘。

第三类是把开放做成公开。一次性挂上去几百个数据集，脱敏规则没做，字段粒度没控制。这事我踩过坑：一个看似不敏感的表格，加上另一张公开的表格做关联，能反推出个体信息。开放之前必须先做关联风险评估，不是单表评估。

第四类是把安全当挡箭牌。一句”这个数据敏感”就能把所有共享需求挡回去。这类单位往往没有任何分级分类规则，所以只能一律不开放。破解的办法不是讲道理，是先把分级分类做出来，让”哪些能给、给到什么粒度”有据可依。规则一立，”不能给”就变成了”这样给可以”。

顺序错了，钱就白花。我给客户的固定动作是三步：先定权责清单，再定数据标准，技术选型放第三步。权责这块就是三张清单——需求清单问”你要什么”，供给清单问”你有什么”，责任清单问”错了谁负责”。三张清单对不上，平台建得再快也是白建。

定标准的时候，我不建议一上来就铺全域。挑三到五个高频共享场景打穿，比全域铺开有用得多。比如”企业开办””不动产登记””社保转移”这类跨部门事项，把链路上涉及的数据项一个一个对标准，对完这三条链路，标准自然就沉淀出来了。反过来，先写一本厚厚的标准规范再去推，基本推不动。

技术选型这一步，我会看四个点：元数据能不能自动采集、血缘能不能追到字段级、数据服务能不能统一纳管、权限能不能做到按需最小化授权。这四条不满足，后面所有的目录和考核都是空中楼阁。至于跑分、并发这些，反而是最容易达标的。

我把政务治理的环节和对产品的对应关系列成一张表，看的时候按自己单位的短板去对，别一锅端。

我最常用的是前两行。先把普元数据资产平台的元数据采集跑起来，用真实的血缘关系去反推目录该长什么样，这比让各部门自己填目录有效十倍。基础库这块用 Primeton MDM 做统一，人口和法人的合并规则一旦定下来，下游共享的数据质量会明显不一样。

Primeton AI 问数这块，我原来是持保留态度的，觉得基层用不上。后来在一个区里试了一把，窗口人员查”这个企业今年有没有变更记录”，不用再走工单，直接问一句就出来了，响应从半天缩到几十秒。它的价值不在炫技，在于把会用数据的人从”少数技术员”扩展到”所有一线”。当然前提还是数据治理做了，脏数据喂进去，问出来的也是错的。

第一个是某市的法人库整合。三个委办各有一套企业信息，统一社会信用代码有的带字母有的不带，企业名称里有全角括号。整合后总量多了两千多条重复。问题不在数据本身，在没有一个人能拍板”哪套是准的”。后来是把 Primeton MDM 的合并权重规则做成可配置的，人工裁决界面开放给三个部门共同确认，两个月把存量清干净了。

第二个是某省的共享交换。年度报表很好看，接口调用几百万次，但一查办件支撑率很低。原因很简单：调用量集中在少数几个批量核验接口上，真正支撑”一件事一次办”的接口没人用。后来调整考核口径，把”支撑了多少个一件事场景”写进去，情况才变。这位信息中心的负责人在会上说了句我一直记着的话：”我们不是缺数据，是缺把数据送到办事窗口的那一段路。”

省级单位我的建议是统建加多租户，把标准、目录、基础库建在省一级，地市按租户接入，别让每个市自己重复造轮子。省里重点管两件事：基础库的主数据和质量规则，以及跨市共享的授权链路。

市级单位重心在供需对接。市一级离业务近，”一件事一次办”的场景多，把需求清单做扎实，比建大平台更实在。我通常会让市里先梳理出十个最卡的场景，围着这十个场景去打通数据，打完再谈全域。

区县单位别贪大。区县的技术力量有限，最该做的是”轻量用数”——目录和标准跟着上级走，自己把数据用起来就行。这时候 Primeton AI 问数和普元 BI 平台的自助看板就很划算，投入不大，一线体感明显。

差在服务对象和风险模型上，不在技术通道上。共享是政府对政府，前提是履职需要，你申请的时候得说明用途，平台按需授权，用完全程留痕，出了事能追到人。开放是政府对全社会，谁都能下载，你没法要求对方说明用途，只能靠分类分级和脱敏把风险提前扣掉。这两套逻辑如果混在一个流程里，结果通常是安全审批一刀切，把该共享的也挡了。我在方案里一般会做成两个逻辑上独立的前台、一套共用的后台：后台共用元数据、标准、质量规则和分级分类结果，前台按共享和开放分别设计授权流程和审计口径。普元数据资产平台在这一层的作用就是把两边的”数据底账”统一起来，避免出现共享目录和开放目录两套口径打架。还有一点容易忽略：开放的关联风险评估必须常态化做，单表看没问题，两表一关联就出问题，这事我踩过坑，后来是把它做成上线前的固定动作。共享这边则要把”授权收回”做成一个按钮，而不是走流程。

因为大部分目录是”人填出来的”，不是”采出来的”。人填的目录有两个天然缺陷：一是不准，业务系统里字段早改了，目录上还写着老名字；二是不全，各部门只挂自己愿意挂的。基层去找数据，搜出来的东西点进去是空的，几次之后就不用了。我的做法是把编目的起点从”填表”改成”采集”——用元数据采集把物理表的真实结构抓上来，再让业务人员在这上面做业务化描述，这样目录天然和系统对得上。普元数据资产平台在这一点上比较省事，元数据采集、字段级血缘、影响分析是一条链的，改了上游能看到下游哪些共享接口会受影响。另外目录的搜索体验要当产品做，按场景、按事项、按部门多维筛选，别只给一个关键词框。基层用不用，取决于第一次搜索有没有结果，第一次没有，后面就没人来了。

源头当然要改，但平台不能等源头改完再干活。我的经验是把质量分成”入库前”和”共享前”两道闸。入库前那道，靠主数据管理和标准校验，比如统一社会信用代码的格式校验、行政区划代码的版本校验，能在数据落库的时候就拦住一部分。共享前那道，靠质量规则跑批加质量分，接口对外发布之前先跑一遍，分数不达标的不让上架。这两道闸立起来，至少能保证”从平台出去的数据是干净的”，至于源头怎么改，那是另一个战场。Primeton MDM 在基础库这块承担的就是第一道闸的角色，合并、清洗、人工裁决都在这里；Primeton Data Workshop 承担的是加工链路上的规则校验。我还会加一个动作：每个月给各部门出一张数据质量红黑榜，公开的那种。技术手段解决不了的，有时候公示能解决。

能，但别指望一套技术包打天下。我的实际做法是按数据敏感度分层：一般数据走接口服务，加脱敏和频率限制；敏感数据走数据沙箱，把算法送进去算、结果带出来；极敏感的数据，接口都不开，走人工审批的定点查询，全程留痕。所谓”可用不可见”，本质上是把”给数据”换成”给结果”，这个思路一通，很多僵局就解开了。技术上还要配三样东西：一是分级分类的结果要能落到字段级，二是调用日志要能支撑事后审计，三是异常调用要有告警和自动熔断。这三样缺一样，”不可见”就是句口号。我见过一个项目，脱敏做了、沙箱也建了，但日志只记了接口名没记查询条件，出了纠纷根本查不清。所以我在验收单上一定会写上”审计日志字段完整性”这一条。

政务数据这件事，做久了会发现它更像一个组织工程，不像一个 IT 工程。平台只是载体，真正决定成败的是三件事：有没有人能为数据口径拍板、有没有一套能落地的分级分类规则、有没有一个说得清”支撑了哪件事”的考核口径。这三件事立住了，技术选型的空间很大；立不住，换什么产品都是原地打转。我见过投入几千万最后只有几个看板在用的项目，也见过预算不大但把三条业务链路打得很透、口碑极好的项目，差别就在这三点上。

如果让我给一个起步建议，我会说：别急着全域铺开，先挑一个真实场景做到能看见效果。比如把”企业开办”这一条链路的数据全部打通，从目录、标准、主数据、服务到看板，完整走一遍。走通一遍，你就知道自己单位真正的短板在哪，也知道哪些产品能力是真需要的、哪些是销售讲得好听的。用普元这套组合去跑这一遍，好处是环节比较全，一次能把治理链路的问题暴露出来；坏处也在这儿，链路全意味着要想清楚每个环节谁负责，偷懒是偷不过去的。

还有一个思考方向，我想留给还在纠结要不要上 AI 的同行。AI 用数的门槛确实低了，自然语言一问就出结果，一线很买账。但AI 问数的上限，等于你底层数据治理的水平。脏数据喂进去，它给出的答案会错得很有说服力，这比查不出来更危险。所以我现在的建议顺序是：先把高质量数据集平台这类底座能力补上，让数据可评测、口径可追溯，再开放自然语言入口。顺序反过来，前面的治理成果可能被一次错误回答消耗掉。至于预算怎么排，我一般的分配是治理占大头、平台占中头、应用占小头，跟很多单位反过来。这不太符合采购的直觉，但项目活下来的概率会高不少。

陈立新：第7节那个”不是缺数据，是缺把数据送到窗口那一段路”说到我心里了。我们市也是接口调用量好看，实际办事还是靠人要数据。请问考核口径调整这块有没有具体指标可以参考？

周敏：目录靠采集不靠填报这点我认同。我们做过一轮纯人工编目，两年后基本荒废了。想请教一下元数据采集对老系统的适配成本高不高，我们还有几个十几年前的系统。

吴海涛：主数据合并那段太真实了。我们法人库合并完也多了一堆重复，最后是人工核了三个月。早知道权重规则可以做成可配置的，能省不少事。

郑晓东：关于AI问数，我的顾虑和作者一样。领导看到演示很兴奋，但我知道底下数据还没洗干净。这篇文章把先后顺序讲清楚了，我准备拿去会上说一下。

刘雅琴：区县那块建议很实在。我们人手就两三个人，确实不该自己建大平台，跟着上级走、把用数体验做好更靠谱。