我做过一个”快速诊断”的测试：不用看数据空间的全部技术方案，只需要问三个关于元数据的问题，就能判断出这个数据空间项目的成熟度。
第一个问题：数据接入后，怎么给每个数据集分配唯一标识？
第二个问题：数据的使用条件（谁可以用、怎么用、用多久）记录在哪里？
第三个问题：当使用方搜索数据时，搜的是什么东西——原始数据，还是元数据？
答案让我有些沮丧——超过半数的项目，第三个问题答错了。
元数据驱动：六步走通数据空间
数据空间是一个典型的”元数据驱动”系统。它的核心业务流包含六个环节，从数据源到数据使用方，每一步都依赖元数据作为”路标”。
第一步：数据源接入。 数据从提供方的系统中进入数据空间。这个环节的元数据产出是”数据集注册信息”，谁提供的数据、什么类型的数据、数据量级、更新频率。
第二步：数据标识分配。 每个数据集在数据空间中获取一个全局唯一的标识符。这是元数据体系的基础，没有唯一标识，后续所有环节都会出现”同一个数据集在三处被描述为不同的名字”的混乱。
标识符不是随便一个UUID。它需要包含足够的语义信息，让机器可以自动解析：哪个数据空间的、哪个提供方的、哪个数据集的。欧洲数据空间的实践使用了一种类似URL的层次化标识结构，虽然增加了标识符的长度，但大幅降低了元数据管理的人工干预需求。
第三步：元数据智能识别。 原始数据进入数据空间后，元数据引擎自动抽取和生成描述性元数据——数据集名称、字段定义、数据格式、数据质量评分。这一步依赖AI技术做模式识别，减少人工标注的工作量。
第四步：元数据存储库。 所有元数据集中存储在元数据存储库中。注意，集中存储的是元数据，不是原始数据。元数据存储库是数据空间的”信息中枢”，所有数据目录的查询、所有使用方的”有什么数据可以用”的搜索，最终都落到元数据存储库。
第五步：治理与控制。 这是元数据驱动最具价值的环节，数据治理、安全合规、数据交换规则，所有这些管控能力，在技术上都是通过对元数据的操作来实现的。
举个例子：访问控制策略本质上是一组关于”谁可以对什么数据做什么操作”的元数据。不是直接修改数据本身，而是在元数据层面配置规则。数据空间中的连接器在执行数据交换时，读取的是元数据（使用控制策略），然后根据元数据的指令执行实际的数据操作。
第六步：数据使用方。 最终用户通过数据目录搜索数据，搜的是元数据存储库，不是原始数据仓库。找到感兴趣的数据集后，按照元数据中描述的使用规则申请访问权限。
两大关键组件：Broker和Vocabulary
在元数据驱动的架构中，有两个组件承担了”翻译”和”连接”的功能：
Broker（代理/中介）：负责在不同数据空间之间协调元数据的交换。A数据空间的元数据格式和B数据空间的元数据格式可能不同，Broker负责做格式转换和语义映射。
Vocabulary（词汇表）：元数据的元数据。它定义了一套标准化的语义模型，确保不同数据源在描述数据时使用”同一种语言”。比如，A医院用”pat_id”字段名，B医院用”patient_id”。如果没有统一的Vocabulary，元数据管理就无法自动判断这两个字段是不是指同一件事。
语义发现引擎
元数据体系的最高层是语义发现引擎。它解决的问题是：当使用方在数据空间中搜索”糖尿病患者的五年随访数据”时，返回的结果不仅仅包括标题中带有”糖尿病”的数据集，还包括与糖尿病相关但标题不同的数据集。
语义发现引擎通过分析元数据中的语义关联来实现”理解搜索意图”，它建立的不是简单的关键词索引，而是一个知识图谱。数据空间的”可发现性”能力，最终由语义发现引擎的成熟度决定。
在数据空间中，元数据不是数据的”说明书”——它是数据的”操作系统”。数据是内容，元数据是索引、规则和指令。没有操作系统，内容就是一盘散沙。
我是BSN联盟成员。有着十年区块链与隐私计算的产品开发和方案咨询经验，先后参与多个国家重大课题，亲手建过区块链、隐私计算、可信数据空间的落地项目。不追概念，写真的。