在企业数据架构的讨论中，有一个隐喻经常被用到：数据仓库像一个”中央厨房”，各个业务系统把原料（数据）送到中央厨房，中央厨房统一清洗、加工、烹饪，然后把成品（报表、分析结果）分发给各个”餐桌”（业务部门）。
这个隐喻在过去二十年帮助无数CIO向管理层解释数据仓库的价值。但它有一个结构性的盲区：当数据需要在不同企业之间流通时，没有人愿意把自己的”原料”送进别人的中央厨房。这就是数据空间与传统数据仓库最根本的分歧。
集中式的黄金时代
集中式数据架构统治了企业数据管理二十年，不是没有道理的。它的优势非常明确：统一的数据标准（所有数据进仓库前都要清洗）、统一的元数据管理（一个地方就能查到所有数据的描述）、统一的安全管控（数据中心是安全的边界、按权限分配访问）。
在数据只在企业内部使用的场景下，集中式是最优解——省掉了大量协调成本。我可以直接用DBA的权限去查任何一个业务系统的数据，不需要跟每个业务部门重新谈协议。
但这个模式的局限性随着数据跨组织流通需求的增长日益凸显：集中式要求数据物理移动到中心，而数据一旦移动，控制权就从数据提供方转移到了中心平台方。 数据提供方不愿意。
去中心化的驱动力
推动数据架构从集中式走向去中心化的力量，不是技术进步，而是所有权意识。当数据被公认为”企业的核心资产”甚至”生产要素”时，企业开始问一个过去没人问的问题：“我的数据凭什么要挪到别人的系统里去？”
这个问题在数据仓库时代不存在，因为数据仓库是企业自己的系统，数据在”内部”移动没有关系。但一旦数据仓库变成了”跨组织的数据空间”，问题就变得尖锐了。
数据提供方要求：数据可以用于分析，但原始数据不能离开我的边界。数据使用方要求：我需要把多个提供方的数据放在一起分析，性能不能太差。监管方要求：所有数据流动必须可追溯、可审计。
要使这三重约束同时满足，集中式架构做不到。于是去中心化的架构思路开始浮现。
联邦式：不去中心，也不集中
“去中心化”这个词容易让人误解，数据空间不是把一切都打散成孤立的节点，而是采用联邦式架构。联邦式架构的核心特征：
数据留在原地。 数据提供方的数据不需要被移动到中央仓库，而是以”虚拟接入”的方式被数据空间感知。数据目录告诉使用者”这里有这些数据可被使用”，但数据本身的物理位置不动。
身份和策略统一。 虽然数据是分布式的，但身份认证和访问控制策略是统一管理的。一个使用方在数据空间里只有一个身份，一套权限，不需要针对每个数据提供方分别做身份注册。
查询和计算分布执行。 当使用方发起一个跨多个数据源的分析请求时，查询被分解为多个子任务，分别发往数据所在的位置执行，结果汇总返回。这就是联邦查询的核心，即，计算移动到数据处，而非数据移动到计算处。
元数据集中，数据分散。 元数据（数据目录、数据描述、使用规则）集中管理，以便发现和治理；数据本身分散在各个参与者的边界内，以便提供方保留控制权。
这个跃迁意味着什么
从EDW到数据空间的范式跃迁，不是”换一个技术平台”，而是对数据控制权的重新分配。
在EDW模式下，控制权在中央数据团队。在数据空间模式下，控制权在数据提供方。
这个转变的影响远超技术架构：它改变了数据治理的组织模型、改变了数据产品的定价逻辑、改变了跨组织协作的信任基础。
数据空间的架构选择不是技术偏好问题，而是数据主权的制度选择问题。集中式架构默认”数据应该统一管”，联邦式架构默认”数据应该归各自管”。选哪一个，决定了数据空间的信任模型、治理模型和商业模型。
我是BSN联盟成员。有着十年区块链与隐私计算的产品开发和方案咨询经验，先后参与多个国家重大课题，亲手建过区块链、隐私计算、可信数据空间的落地项目。不追概念，写真的。