数据要素可信流通与数据基础设施建设：数由空间架构及落地验收

简介：《数据要素化新阶段的数据基础设施白皮书》面向数据要素政策研究者、数据基础设施建设与运营人员及高校相关专业读者，系统梳理国家数据基础设施的理论、政策与实践，回应数据大规模高通量流通与动态安全并存的现实问题。全文围绕数据可信流通利用基础设施、国家数据基础设施总体框架及“数由空间”“数由器”架构展开，并涉及隐私计算、区块链、数据空间等技术路径。资源包共1个PDF文件，大小约3.06MB，便于直接查阅与检索。内容涵盖城市、行业、企业及跨境数据基础设施实践，结合“从车厘子自由到数据自由”的类比，呈现全流程动态安全下的数据流通思路与建设参考。目前已有44人学习下载，适合用作政策梳理、方案论证和落地实践的资料底稿。

1. 从“数据自由”倒推：这套数据基础设施方案到底为谁而写

“数据自由”这个词第一次听会觉得空。但如果你在做数据流通方向的毕设，或者要给一个城市、一个行业的数据平台出方案，很快就会撞上一个很具体的矛盾：真正有价值的私域数据占了八成以上，它们必须流动才能产生价值，可一旦流动就得过隐私计算，跑一轮密文计算，资源消耗是明文的近百倍，效率还不到明文的十分之一。评审老师或甲方第一个问题往往就是——这东西怎么规模化？这份《数据要素化新阶段的数据基础设施白皮书》给的正是一条从“五新”判断到“数由空间”架构、再到城市/行业/企业/跨境四类落地场景的完整链路。它适合两类人：要交数据要素、数据安全、可信数据空间方向毕设或课设的学生，以及需要写数据基础设施建设方案、做技术选型的从业者。下面按“需求判断—架构设计—组件实现—踩坑—验收”的顺序，把它拆成一份能照着走的方案。

2. 需求定位：五新框架下，为什么露在水面上的两成数据根本不够用

方案能不能立住，先看需求判断对不对。这份白皮书最有价值的地方不是技术清单，而是它把“为什么现在必须建数据基础设施”拆成了五个可以逐条验证的判断：新要素、新空间、新设施、新产业、新要求。做毕设时如果第一章就把这五条讲清楚，后面的架构设计就有了合法性来源，不至于变成“我选了几个热门技术拼在一起”。

2.1 空间形态的四级演进：物理、网络、计算、数据

白皮书把人类社会承载活动的空间分成四层：物理空间、网络空间、计算空间、数据空间。这个划分看起来像概念游戏，但它直接决定了基础设施该建在哪一层。物理空间靠交通、通信工程支撑，网络空间靠光纤、路由器和协议栈支撑，计算空间靠芯片、存储器、服务器支撑，到了数据空间，支撑它的就变成了数据安全流通平台、各类协议和标准。换句话说，前三层解决的是“连得上、算得动”，第四层要解决的是“数据敢不敢拿出来用”。

这个演进线索在做方案时有实际用途。你在写需求分析章节时，可以沿着“移动电话用户规模、工业关键工序数控化率、物联网设备普及”这条线说明数据量为什么从零散低价值变成汇聚高价值，再顺势推出结论：连接和算力已经不是瓶颈，瓶颈在流通环节的信任与安全。这样写出来的需求不是凭空喊口号，而是有推进逻辑的。

我一般会把这一节控制在两页以内，配一张四层空间的对照表就够了，重点是让读者接受“数据空间是新型空间形态”这个前提，后面的所有设计才有落点。

2.2 流通冰山模型与公域数据耗尽：需求侧的硬约束

这是整份材料里最能打动评审的一组数据。全球互联网上流通的数据里，可流通部分只占全部数据的约两成，而这部分里真正能在万维网上通过搜索引擎访问的又只占 4%，剩下 96% 沉在深网里；深网中九成以上是私域数据。也就是说，我们平时讨论的“数据流通”，讨论的其实只是冰山尖上那一点点。另一条约束是时间：大模型对数据的需求持续放大，按白皮书的判断，到 2028 年前后公域数据资源将面临耗尽，微软的数据交易平台此前也因隐私风险下线过多个开放数据集。

两条约束叠在一起，结论很清晰：增量数据只能来自私域，而私域数据的开采必须依赖可信流通技术。这也是为什么隐私计算、区块链、数据空间这些词这两年密集出现在政策文件和项目申报书里——不是技术时髦，是数据来源结构被逼到了这一步。

写方案时，这一节可以做成一张分层占比图加一段推演，明确写出“本方案面向的是占比八成、尚未被有效开发的私域数据”，把项目边界一次划清。边界划清了，后面就不会被问“你这个平台能管多少数据”这种没法回答的问题。

提示：冰山模型里的比例是白皮书给出的估算口径，引用时保留“约”“左右”这类限定词，不要写成精确统计值。

2.3 用“车厘子自由”理解“数据自由”：三阶段落地节奏

这是全篇最好用的一个类比，答辩时讲出来评委基本秒懂。车厘子早年是高端水果，因为冷链成本高，只有远距离、高价值运输才用得起冷库、冷藏车、保温盒；随着冷链技术不断突破，又从“技术突破”走向“技术基础设施化”，成本降下来，普通食品运输也用上了，车厘子才真正平民化。

数据流通走的是同一条路。白皮书给出的节奏是三步：

这张表在做课设的“进度安排”或方案的“实施路径”章节时可以直接改写复用。要注意的是，三个阶段的划分不是让你在项目里做三年规划，而是给你的方案一个时间坐标：你现在做的东西属于攻关期的原型验证，还是收敛期的标准适配，定位不同，验收标准完全不同。原型阶段看的是“技术上跑通了没有”，收敛阶段看的是“符不符合标准、能不能被别人接进来”。这一点想不清楚，答辩时很容易被追问到哑口无言。

3. 总体架构设计：四层骨架加三能力四角色，把“可信流通”拆成可分工的模块

需求讲完就要给架构。数据基础设施这类题目最容易犯的毛病是把架构画成一张大饼，什么能力都往里塞，最后没法解释模块之间怎么协作。比较稳妥的做法是采用两条正交的切分：纵向按设施层级分，横向按数据生命周期分，再用可信数据空间的三类能力和四类角色去定义“谁在什么位置做什么事”。

3.1 纵向四层与横向平台矩阵

白皮书给出的国家数据基础设施总体框架是四层：数据流通利用基础设施、算力基础设施、网络基础设施、数据安全基础设施。横向覆盖数据采、存、算、管、用全生命周期，对应数据采集平台、汇聚平台、加工平台、共享平台、开放平台、运营平台、交易平台、存储平台等一整套平台矩阵。三个维度——基础设施形态、数据全生命周期、行业和区域空间——相互融合，形成统分结合的结构。

这个框架落到毕设或方案里，我一般这样处理：纵向四层作为“总体架构图”的骨架，横向平台矩阵作为“功能模块清单”的来源。两者交叉的地方就是你要写的模块，比如“数据加工平台”落在流通利用层，“数据安全基础设施”横贯所有层，不单独归属某一层。

# 总体架构描述用的分层配置示例（可按项目实际情况增删） infrastructure_layers: - name: 数据流通利用基础设施 # 本方案的主战场 components: [可信数据空间, 数场, 数据元件, 数联网, 隐私计算平台] - name: 算力基础设施 components: [通用算力, 智能算力, 算力调度] - name: 网络基础设施 components: [骨干网, 接入网, 标识解析] - name: 数据安全基础设施 # 横贯各层，不单独归属 components: [身份认证, 密钥管理, 审计存证, 分类分级] lifecycle_platforms: - [数据采集平台, 数据汇聚平台, 数据加工平台] - [数据共享平台, 数据开放平台, 数据运营平台] - [数据交易平台, 数据存储平台]

这段配置没有任何运行逻辑，它的作用是强制你把“说了要建什么”写具体。infrastructure_layers里每一项都必须能对应到一个真实存在的产品或开源组件，lifecycle_platforms里每一项都必须能说清楚它服务哪个环节、输入输出是什么。答辩前对着这份清单自检一遍，凡是写不出对应组件的条目，要么删掉，要么老实标注为“规划中”。架构图上画了却说不清楚的东西，是评审最爱戳的地方。

3.2 可信数据空间的三大核心能力

白皮书把可信数据空间定义为基于共识规则、联接多方主体、实现数据资源共享共用的数据流通利用基础设施，并明确它必须具备三类核心能力：可信管控、资源交互、价值创造。这三条不是并列的功能点，而是有先后依赖的。

可信管控是底座，包含对空间内主体身份、数据资源、产品服务的可信认证，以及全过程的动态管控、实时存证和结果可追溯。资源交互是中间层，要求不同来源的数据资源、产品和服务能在空间内统一发布、高效查询、跨主体互认，做到跨空间的身份互认、资源共享、服务共用。价值创造是结果层，支持多主体在规则约束下共同参与开发利用，推动数据资源转化为数据产品或服务，并保障各方权益。

我在写这一节时会明确画出一条依赖线：没有可信管控，资源交互就是裸奔；没有资源交互，价值创造就是空谈。很多方案把三条平铺成三个功能模块，结果做出来的东西既不能认证也不能互认，只能在自己系统里自娱自乐。

3.3 四类角色的权责边界

可信数据空间里有四类角色：数据提供方、数据使用方、数据服务方、监管方。提供方决定其他参与方对其数据的访问、共享和使用权限，并按约定分享权益；使用方依据协议按约加工使用；服务方承担数据开发、供需撮合、托管运营等职责；监管方负责指导、监督和规范，确保运营合规。

角色划分的价值在于把“权限”这件事写死。做方案时，我习惯给每个角色配一张权限矩阵，明确谁能发布、谁能申请、谁能审批、谁能审计。

这张表看着简单，实际是后面所有接口设计的依据。谁有权限调哪个接口，直接从表里查，不用每次开会重新吵一遍。

3.4 技术选型矩阵：什么场景用隐私计算，什么场景用沙箱

可信管控相关的技术白皮书列了一串：使用控制、隐私计算、数据沙箱。资源互通侧有数据标识、语义发现、元数据智能识别。共性服务侧有接入认证、可信存证、资源目录。这些技术不是让你全上，而是按场景选。

选型的核心判断是“频次 × 敏感度”。高频低敏走明文加使用控制，低频高敏才上隐私计算。把这条原则写进方案，能挡掉一大半“你为什么不用最先进技术”的质疑。

4. “数由空间”落地实现：接入点、能力平台、管理平台三层怎么搭

架构讲完必须落到具体组件，否则就是纸上谈兵。白皮书给出的实践方案叫“数由空间”，由数由器、基础能力平台、管理服务平台三层构成，再辅以动态安全防护和统一服务对接。这三层的分工非常清楚，照着搭基本不会跑偏。

4.1 数由器：把“一次交易建一条链路”变成“一次接入长期可用”

数由器是整个空间的接入点。它要解决的问题很具体：过去企业每做一次数据交易就要重新建一条流通链路，成本高、效率低，链路用完就废。数由器的思路是把接入标准化——数据源方和需求方各自部署一台数由器接入空间，之后所有的发现、撮合、交付都在这张分布式网络上完成，不用每次重建。

从功能上看，数由器以数据资产地图、数据交易、数据交付为核心，配套四类技术：以零信任、可信根、身份认证与访问控制为核心的可信接入；以数据脱敏、分类分级、API 网关为核心的数据安全；以隐私计算、差分隐私为核心的流通计算；以数据合规流通数字证书、区块链为核心的审计监管。

下面是一段接入注册的接口示意，重点看字段设计。

# 数由器接入注册的请求构造示意（伪代码，字段按项目实际调整） def build_register_payload(node): return { "node_id": node.id, # 全局唯一节点标识，由空间统一分配 "org_type": node.org_type, # provider / consumer / service / regulator "capabilities": node.capabilities, # 本节点支持的能力：privacy_computing / sandbox / api_gateway "asset_catalog_digest": node.digest(), # 数据资产目录摘要，用于后续目录同步比对 "cert_chain": node.cert_chain, # 合规流通数字证书链，供对方验签 "endpoint": node.endpoint, # 数据交付入口地址 "heartbeat_interval": 30 # 心跳间隔（秒），超时未上报则标记为不可用 }

这段代码的关键不在语法，在字段背后的设计取舍。org_type决定了这个节点在权限矩阵里的位置，注册时就要定死，不允许后期随意切换。capabilities是能力协商的基础，两个节点做隐私计算前必须先确认对方支持哪种协议，否则连上了也跑不通。asset_catalog_digest用来判断目录是否需要增量同步，避免每次全量拉取。cert_chain是合规凭证，跨境场景下这一项要求最严。heartbeat_interval关系到节点健康度判定，设太短会造成大量无效请求，设太长则故障发现滞后，30 秒是个比较常用的折中值。

失败时看哪里？注册被拒通常有三个原因：证书链验不过、节点标识重复、能力声明与目录内容不匹配。日志里把这三项分别打出来，排查效率会高很多。

4.2 基础能力平台：把重复建设的东西收上来

基础能力平台提供三类能力：可信管控、资源互通、共性服务。可信管控靠隐私计算和数据沙箱；资源互通靠数据资产登记和数据资产地图；共性服务包括接入认证、可信存证、资源目录。此外区块链、智能合约、合规流通数字证书、大模型等可以作为底层技术支撑。

这一层的设计原则是“能复用就不新建”。白皮书特别提到共性服务适宜统一建设，避免重复建设。我在做方案时会把这一层拆成三个可独立部署的服务：

• 认证服务：统一对接入主体、技术工具、服务开展能力评定，按统一标准核验是否符合规范要求。
• 存证服务：保存数据流通全过程信息记录且不可篡改，为清算审计、纠纷仲裁提供电子证据。
• 目录服务：按统一接口标准提供资源和服务的发布与发现能力，同一份目录可被多个空间复用。

三者的调用关系是：认证在前，存证贯穿全程，目录对外提供服务发现。任何一次数据交付，顺序都是先认证双方身份、再查目录确认资源、再执行交付并全程存证。

4.3 管理服务平台与“三数一链”的闭环

管理服务平台的职责是解决供需问题：构建全局数据资源目录，让用数主体能检索、能交易、能按安全和价值判断选择合适的交付方式。白皮书里用“三数一链”概括这套组合，我一般理解为数据资源、数据产品、数据资产三类对象加一条区块链存证链路的贯通——资源是原料，产品是加工后的可交付物，资产是权属清晰的登记对象，链路则保证每一步都有据可查。

落到库表设计，一个最小的资源目录可以这样建：

-- 数据资源目录核心表（简化版，按需扩展） CREATE TABLE data_resource ( resource_id VARCHAR(64) PRIMARY KEY, -- 全局唯一资源标识，与数据标识体系对齐 provider_node VARCHAR(64) NOT NULL, -- 提供方数由器节点 ID title VARCHAR(256) NOT NULL, category VARCHAR(64), -- 分类分级结果，决定可用技术路线 sensitivity TINYINT NOT NULL, -- 敏感等级 1-4，4 级必须走隐私计算或沙箱 update_cycle VARCHAR(32), -- 更新周期，影响撮合时的时效判断 price_rule JSON, -- 计价规则，支持按次、按期、按结果分成 cert_id VARCHAR(64), -- 合规流通数字证书编号 status TINYINT DEFAULT 0, -- 0 待审核 1 已上架 2 已下架 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- 按敏感等级和技术路线检索可用资源 SELECT resource_id, title, category, price_rule FROM data_resource WHERE status = 1 AND sensitivity <= 3 AND category = '交通' ORDER BY update_cycle DESC;

resource_id必须和空间内的数据标识体系统一，否则跨空间互认时会撞号。sensitivity是整个表里最重要的字段，它直接决定交付时走哪条技术路线：1 到 2 级走明文加使用控制，3 级上数据沙箱，4 级必须隐私计算。把这条规则写进代码而不是写进文档，能避免大量人为误判。price_rule用 JSON 而不是拆成多张表，是因为计价方式变化频繁，拆表会导致频繁改结构，用 JSON 加应用层校验更灵活。查询示例里sensitivity <= 3是有意为之——大部分撮合场景不需要把最高敏资源推到前台，先筛掉能显著降低无效点击。

4.4 四类场景的复用路径

白皮书给了四条落地线：城市、行业、企业、跨境。城市侧的例子是交通优化和金融行业支撑；行业侧有医疗领域的模型落地、监管类行业的反诈业务；企业侧是企业数据基础设施；跨境侧对合规凭证和标准互认要求最高。

这四类场景在架构上高度复用，区别只在部署边界和合规强度。

做毕设时选一条线做深就够了，四条全铺开必然每一条都浮于表面。我的建议是选城市或行业，因为这两条线的公开材料最多，评审也最容易理解价值。

5. 避坑与排查：数据可信流通方案最容易翻车的五个点

这一章是我做类似方案时踩出来的，每一条都能对应到具体的返工。

5.1 把“安全”理解成“不让流”

现象很典型：方案写了一堆加密、隔离、认证，最后一算，数据一次都没真正流出去，项目验收时拿不出一个端到端的流通案例。原因是设计阶段把安全和流通对立起来了，沿用了传统信息化时期的静态安全思路——分级保护、密码保护、隔离保护，手段全是“限制流动”。

解决思路是回到白皮书那句话：新阶段数据的类型只有一种，都是可以流通的数据，区别只在用哪种流通方式。普通数据走明文传输，涉敏涉密数据走隐私计算、区块链、数据空间。方案里必须明确写出每类数据对应的流通方式，而不是笼统写“确保安全”。我现在的习惯是：每设计一个安全措施，就同时写出它允许什么操作发生，写不出来就说明这条措施设计错了。

5.2 技术选型只看先进性，不看成本

现象：方案里全套上隐私计算，答辩时被问“跑一次要多久”，答不上来。原因是没有算过账。白皮书给的数据很直白：密文传输和计算的资源消耗是明文的 100 倍，效率不到明文的十分之一，国家层面的目标是用三年时间降到明文的 3 倍左右、效率达到五分之一。也就是说，现阶段全量上隐私计算本来就不现实。

解决办法是做分级分流。按敏感等级和数据量把任务分成三档：高频低敏走明文加使用控制，中频中敏走数据沙箱，低频高敏才上隐私计算。同时在方案里写明性能基线，比如“单次联邦建模任务在 X 万条样本下不超过 Y 分钟”，有基线才有验收依据。

5.3 链路一次性建设，用完即弃

现象：每笔数据交易都单独拉一条链路，做完就拆，下一笔重新来。原因是没有接入点这个统一入口，各系统点对点对接。白皮书的数由器就是冲这个问题来的——接入标准化之后，节点常驻在网络上，交易只是网络上的一次交互，不是一次基建。

解决办法是把“接入”和“交易”两个动作在架构上彻底分开。接入是一次性的，交易是高频的。方案里要明确写清楚：节点注册、证书签发、目录同步属于接入流程；资源检索、撮合、交付属于交易流程。两者混在一起写，实施时一定会返工。

5.4 目录建了但没人维护

现象：系统上线三个月，资源目录里的条目一半已失效，用数方检索到的资源点进去全是空。原因是把目录当成静态清单，没有更新机制。目录服务的价值在于“准确”，不在于“多”。

解决办法是把更新责任写进协议。提供方对资源状态负责，资源下架必须同步更新状态位；平台侧做定期巡检，超过一定周期未更新的资源自动降权或下架。上面那张data_resource表里的status和update_cycle字段就是为此设计的，不是摆设。

5.5 角色权限在文档里清楚，在系统里糊成一团

现象：文档写了四类角色，系统里只有一个管理员账号能操作所有功能，审计时说不清谁在什么时候做了什么。原因是权限矩阵没有落到接口层。

解决办法是把第 3 章那张权限矩阵直接翻译成接口鉴权规则，每个接口标注允许的角色，代码里做硬校验而不是靠前端隐藏按钮。存证服务记录的操作日志要和角色绑定，出问题时能追到具体主体。

6. 验收与答辩：用三张表和一条链路证明方案真的“流得动”

数据基础设施类项目的验收最怕一件事：讲了一堆架构，拿不出一个能跑通的例子。我的做法是准备三张表加一条演示链路，成本不高，但说服力很强。

第一张是能力对照表，把白皮书要求的三类核心能力逐条对应到你的实现。

第二张是性能基线表，写清楚不同技术路线下的实测数据。哪怕你的实测值比理想值差很多也没关系，如实写反而加分，因为白皮书本身就承认当前技术离大规模普惠使用还有差距。评审更在意你有没有量化意识，而不是数字好不好看。

第三张是合规凭证清单，列出方案里用到的数字证书、存证记录、审计日志的字段和留存周期。跨境场景下这张表权重最高。

演示链路建议只做一条，但要做完整：提供方接入并上架一个资源 → 使用方检索到该资源并提交申请 → 提供方审批并下发使用控制策略 → 按敏感等级选择交付方式（低敏明文、中敏沙箱、高敏隐私计算）→ 全过程存证并可查询。这条链路跑通，方案就立住了。

答辩时还有一个常被忽略的点：主动说明边界。哪些是本期做的，哪些依赖后续标准收敛，哪些需要外部机构配合。说清楚边界比夸大能力安全得多。我早期做过一个方案，把所有能想到的能力都写成“已实现”，结果被追问一个跨空间互认的细节，当场答不上来，后面所有内容都被连带质疑。从那以后我每次写方案都强制走一遍“能力—落点—验收方式”三列对照，凡是填不出第三列的，一律降级为规划项。

希望这套拆法能帮到你，不管是交一份毕设，还是出一份能落地的方案。

本文还有配套的精品资源，点击获取