中台退潮,数据供给的缺口反而更大

过去几年,数据中台一度是数字化转型的标准动作。但不少企业发现,平台建起来了,数据依然散落在几十个系统里,业务提一个跨域指标要等上数周。中台被质疑,并非理念错误,而是许多项目把重心放在集中存储上,忽略了元数据、口径与权责的治理。当企业开始把大模型和智能体接入生产流程,这个缺口被进一步放大:模型需要的是实时、语义一致、可追溯的数据,而不是又一个数据湖。

数据编织换了一条路径

数据编织的核心思路,是不再把数据搬到同一个地方,而是通过元数据驱动的方式,把分散的数据源连接成一张可查询、可治理的网络。它通常包含三层能力:

  • 主动元数据:自动采集表结构、血缘、使用日志和质量规则,让数据资产自己说话;
  • 知识图谱:把业务术语、指标口径与物理表建立映射,缓解同名不同义、同义不同名的问题;
  • 虚拟化集成:通过查询下推等方式按需取数,减少全量复制带来的成本与合规风险。

与强调域自治的数据网格相比,数据编织更偏向集中编排,两者在实践中常被组合使用:各业务域负责本地数据产品,编织层负责统一语义与访问控制。

为什么在这个时间点走热

直接推手是智能体落地。智能体需要频繁调用工具、查询数据、执行多步任务,任何一处口径不一致都可能导致答案漂移。以传统数仓的批处理节奏支撑这类调用,延迟和治理成本都难以接受。数据编织提供的统一语义层,恰好可以充当模型与底层系统之间的翻译层。

另一重推力来自合规与成本。数据安全法、个人信息保护法实施后,企业越来越不愿把数据大规模复制到新平台,原地治理、按需访问因此更受青睐;云上存算支出居高不下,减少冗余副本也顺势成为优化目标。

落地时容易踩的坑

需要提醒的是,数据编织并非一键式产品。它高度依赖元数据的完整性,如果源头系统连基础的表注释和血缘都缺失,编织层就会空转。较务实的做法是先选一两个高频跨域场景,例如客户统一视图或供应链风险预警,用真实需求倒逼元数据治理。同时要明确指标口径的归口部门,避免把技术问题拖成组织问题。评估指标也应落在取数周期缩短多少、口径争议下降多少这类结果上,而不是再统计接入了多少个系统。

结语

数字化转型走到今天,难点早已从有没有数据,变成能不能随时用对数据。数据编织未必是唯一答案,但它代表了一种更务实的取向:尊重数据的分布现实,用语义和治理把分散的资产连起来。对多数企业而言,这或许比再建一个平台更接近问题的本质。