数据中台之后,然后呢?
过去几年,数据中台是国内企业数据建设的绝对主角。从阿里提出中台战略开始,几乎所有大中型企业都在搞中台:建数据湖、搭数据仓库、做数据服务化。
但到了 2024 年,中台的热度明显下降了。原因很简单:很多中台项目失败了。
失败的原因各不相同,但有几个共性问题:
- 中台团队成了瓶颈,业务部门想要数据得排队等
- 数据质量不高,业务部门不信任
- 中台太重,维护成本高
- 数据所有权不清晰,谁的数据谁负责?
这些问题让行业开始反思:数据中台是不是唯一的路?还有没有别的选择?
这时候,两个概念开始进入视野:Data Mesh 和 Data Fabric。它们代表了两种截然不同的去中心化数据架构路线。
Data Mesh:把数据还给业务
核心理念
Data Mesh 的核心思想很简单:数据应该由产生它的业务团队来负责,而不是由中央数据团队来管。
这个想法来自于领域驱动设计(DDD)。在微服务架构中,每个服务都由对应的业务团队负责,服务之间的交互通过 API 来完成。Data Mesh 把这个思路应用到了数据领域。
四个核心原则
1. 领域驱动的数据所有权
每个业务领域(比如订单、用户、商品)都有自己的数据团队,负责生产、维护和发布该领域的数据产品。
这解决了中台的一个核心问题:数据团队不了解业务,业务团队不了解数据。在 Data Mesh 中,数据团队就是业务团队的一部分。
2. 数据即产品
数据不再是"原材料",而是"产品"。每个数据产品都有:
- 明确的消费者(谁在用这个数据)
- 质量标准(SLA:可用性、准确性、时效性)
- 文档和接口(API、数据字典)
- 负责人(数据产品经理)
这让数据从"成本中心"变成了"价值中心"。
3. 自服务平台
虽然数据所有权分散了,但基础设施是共享的。Data Mesh 需要一个自服务平台,让各个业务团队可以:
- 快速创建数据产品
- 发布和发现数据
- 监控数据质量
- 管理数据访问
这个平台由专门的基础设施团队维护,但不参与具体的数据业务。
4. 联邦治理
数据治理不再是中央集权,而是联邦制。全局性的标准(比如数据安全、合规、元数据标准)由中央治理委员会制定,但具体的实施由各个业务团队负责。
这既保证了全局一致性,又给了业务团队足够的灵活性。
Data Mesh 的优势
- 响应快:业务团队直接负责数据,不需要等中台排期
- 质量高:最了解数据的人来维护数据
- 所有权清晰:谁的数据谁负责,责任明确
- 可扩展:新增业务领域只需要新增一个数据团队
Data Mesh 的挑战
- 组织变革大:需要调整组织结构,让业务团队承担数据责任
- 协调成本高:跨领域的数据需求需要多个团队协调
- 技术门槛高:需要业务团队具备数据工程能力
- 文化转变难:从"数据是 IT 的事"到"数据是业务的事"
Data Fabric:让数据自动流动
核心理念
Data Fabric 的思路和 Data Mesh 不同。它不改变组织结构,而是通过技术手段让数据自动流动。
Data Fabric 的核心假设是:企业的数据散落在各个系统、各个部门,手动整合成本太高。所以需要一个智能化的"数据编织层",自动发现、连接、整合数据。
三个核心能力
1. 智能元数据管理
Data Fabric 会自动扫描企业内的所有数据源,建立统一的元数据目录。这个目录不仅包含数据的位置、格式、血缘,还会用 AI 分析数据的质量、敏感性、使用模式。
比如系统可以自动发现:
- 哪些表包含个人信息(PII)
- 哪些数据有质量问题
- 哪些数据经常被使用
- 哪些数据之间有依赖关系
2. 自动化数据集成
基于元数据,Data Fabric 可以自动生成数据集成任务。比如:
- 自动识别相似的数据源,建议合并
- 自动生成 ETL 管道,把数据从源同步到目标
- 自动处理数据转换,比如格式转换、编码转换
这大幅降低了数据集成的成本。
3. 统一数据访问层
Data Fabric 提供一个统一的访问层,用户不需要知道数据在哪里、是什么格式,只需要通过 API 或 SQL 查询数据。
比如用户想查"过去 30 天的订单总额",不需要知道这个数据在哪个数据库、哪张表,只需要调用统一的 API,Data Fabric 会自动路由到正确的数据源。
Data Fabric 的优势
- 组织变革小:不需要调整组织结构,技术驱动
- 集成成本低:自动化处理大部分数据集成工作
- 用户体验好:统一访问层,不需要了解底层细节
- 见效快:可以快速上线,逐步完善
Data Fabric 的挑战
- 技术复杂度高:需要强大的元数据管理、自动化集成能力
- 数据所有权不清晰:虽然技术上整合了,但管理上还是分散的
- 性能瓶颈:统一访问层可能成为性能瓶颈
- 治理难度大:数据散落在各处,统一治理困难
两种架构的全面对比
现在来做一个系统的对比,看看 Data Mesh 和 Data Fabric 在各个维度上的差异:
| 维度 | Data Mesh | Data Fabric |
|---|---|---|
| 核心理念 | 组织驱动,数据所有权分散 | 技术驱动,数据自动流动 |
| 数据所有权 | 业务团队拥有 | 保持现状,技术上整合 |
| 组织结构 | 需要调整,建立数据产品团队 | 不需要调整 |
| 技术栈 | 数据产品平台、数据市场 | 元数据管理、自动化集成、统一访问层 |
| 治理模式 | 联邦治理,全局标准+本地实施 | 中央治理,统一管控 |
| 实施难度 | 高(组织+技术) | 中(主要是技术) |
| 见效速度 | 慢(需要组织变革) | 快(技术驱动) |
| 适用场景 | 大型组织、多业务线 | 中型组织、数据分散 |
| 典型厂商 | Snowflake、Databricks | Informatica、Denodo、IBM |
| 成本结构 | 人力成本高(数据团队) | 技术成本高(平台) |
关键差异
1. 驱动力不同
Data Mesh 是组织驱动,认为数据问题的根源是组织结构问题,所以要改组织。Data Fabric 是技术驱动,认为数据问题的根源是技术问题,所以要改技术。
2. 所有权不同
Data Mesh 强调数据所有权分散,每个业务团队拥有自己的数据。Data Fabric 不改变所有权,只是在技术上整合数据。
3. 实施路径不同
Data Mesh 需要从上到下推动,涉及组织变革、文化转变,周期长。Data Fabric 可以从下往上推进,先建平台,逐步完善,周期短。
选型决策框架
那么,企业应该选 Data Mesh 还是 Data Fabric?这取决于几个关键因素:
适合 Data Mesh 的情况
1. 组织规模大
企业有多个独立的业务线,每个业务线都有自己的数据团队。比如集团型企业、多元化企业。
2. 数据需求复杂
不同业务线的数据需求差异大,中央数据团队无法满足。比如金融集团,零售银行、投资银行、保险的数据需求完全不同。
3. 组织变革意愿强
企业愿意调整组织结构,让业务团队承担数据责任。这需要高层的强力支持。
4. 长期投入
Data Mesh 是一个长期的过程,需要 2-3 年才能见效。企业需要有耐心。
适合 Data Fabric 的情况
1. 组织规模中等
企业有几十个数据源,但没有几十个独立的业务线。比如中型制造企业、零售企业。
2. 数据分散但需求统一
数据散落在各个系统,但用户的需求相对统一。比如需要整合 ERP、CRM、WMS 的数据做分析。
3. 组织变革困难
企业不愿意或无法调整组织结构,希望通过技术手段解决问题。
4. 快速见效
Data Fabric 可以在 6-12 个月内见效,适合需要快速解决问题的企业。
决策树
|
|
实际案例:某制造企业的架构演进
让我们看一个真实的案例。某大型制造企业,年产值 500 亿,有 5 个事业部(汽车零部件、工程机械、农业机械、新能源、金融服务),每个事业部都有自己的 IT 系统。
背景
2020 年,集团决定建设数据中台,目标是整合各事业部的数据,支持集团层面的分析和决策。
中台阶段(2020-2022)
集团成立了数据中台团队,50 人规模。主要工作:
- 建设数据湖,汇聚各事业部数据
- 开发数据服务,支持集团分析需求
问题逐渐暴露:
- 中台团队不了解各事业部的业务,数据质量不高
- 事业部想要数据得排队等,响应慢
- 数据所有权不清晰,出了问题互相推诿
- 中台维护成本高,50 人团队还是不够
评估阶段(2023)
集团请外部咨询公司评估,结论是:中台模式不适合当前的组织结构。
原因:
- 5 个事业部业务差异大,中央团队无法深入了解
- 各事业部有自己的数据团队,有能力承担数据责任
- 集团规模大,中台成了瓶颈
选型阶段(2023)
咨询公司建议采用 Data Mesh 模式。理由:
- 组织规模大,有 5 个独立事业部
- 各事业部有自己的数据团队
- 集团高层支持组织变革
实施阶段(2024-)
1. 组织调整
- 每个事业部成立数据产品团队(3-5 人)
- 集团数据中台转型为数据平台团队(20 人),负责基础设施
- 成立联邦治理委员会,制定全局标准
2. 技术平台建设
- 建设数据产品平台,支持各事业部创建和发布数据产品
- 建设数据市场,支持数据发现和消费
- 建设数据质量监控,支持 SLA 管理
3. 试点推进
选择汽车零部件事业部作为试点,因为:
- 业务相对简单
- 数据团队能力强
- 领导支持
试点结果:
- 3 个月内发布了 10 个数据产品
- 数据响应时间从 2 周降到 2 天
- 数据质量评分从 65% 提升到 85%
当前状态(2024 年底)
- 5 个事业部都已建立数据产品团队
- 共发布 50+ 个数据产品
- 集团数据平台团队负责基础设施和治理
- 数据响应时间平均 3 天(原来 2 周)
- 数据质量评分平均 80%(原来 65%)
经验总结
成功的因素:
- 高层强力支持,推动组织变革
- 选择试点事业部,快速验证
- 技术平台和组织建设并行
- 联邦治理,平衡全局和本地需求
遇到的挑战:
- 组织变革阻力大,需要持续沟通
- 跨事业部数据需求协调复杂
- 数据产品团队能力建设需要时间
后中台时代的趋势判断
Data Mesh 和 Data Fabric 代表了两种不同的技术路线,但它们不是对立的。实际上,很多企业会混合使用:
- 大型集团:整体采用 Data Mesh,但某些共享数据用 Data Fabric 整合
- 中型企业:整体采用 Data Fabric,但某些核心业务用 Data Mesh
趋势一:混合架构成为主流
纯粹的 Data Mesh 或纯粹的 Data Fabric 都很难落地。未来的趋势是混合架构:
- 核心业务数据用 Data Mesh,业务团队负责
- 共享数据用 Data Fabric,技术团队整合
趋势二:AI 驱动的数据管理
无论是 Data Mesh 还是 Data Fabric,都会越来越多地使用 AI:
- 自动发现数据质量问题
- 自动生成数据集成任务
- 自动推荐数据产品
趋势三:数据产品化加速
Data Mesh 的"数据即产品"理念会被更多企业接受。即使不采用完整的 Data Mesh,也会借鉴这个理念:
- 数据有明确的消费者
- 数据有质量标准
- 数据有负责人
数据中台不是终点,而是起点。Data Mesh 和 Data Fabric 代表了后中台时代的两条技术路线,选择哪条取决于企业的组织结构、业务特点和技术能力。
没有最好的架构,只有最适合的架构。关键是理解自己的需求,选择正确的路线,然后坚定地执行。
数据建设的道路很长,中台只是其中一站。下一站去哪里,取决于你怎么走。