构建企业级DataMesh架构：跨域通用数据摄入存储及落地案例需求

核心前提锚定 #

首先明确：Data Mesh中的「通用数据」（如用户主数据、组织架构、基础编码）不能走回集中式数据湖的"大一统"老路，必须在领域自治和跨域复用间找平衡——通用数据的所有权归属于某一核心领域，而非集中管理团队。

一、通用数据摄入方案：分布式采集+契约先行 #

1. 领域主动推送模式（优先推荐） #

• 明确通用数据的所属领域：比如用户主数据归用户域，商品基础编码归商品域，由所属领域团队负责数据的生成、校验与变更。
• 跨域治理小组联合各依赖领域制定统一事件契约（如Avro格式、JSON Schema），所属领域在数据发生变更时，通过事件总线（如Kafka、Pulsar）推送标准化领域事件。
• 依赖领域根据自身业务需求订阅对应事件，将数据摄入到自身的领域数据存储中，全程由依赖领域团队负责摄入逻辑与数据质量校验。

2. 遗留系统的联邦采集代理 #

对于无法主动推送数据的遗留系统（如老旧ERP），在系统所在领域节点部署轻量采集代理（如Flink CDC、Debezium）：

• 代理按照统一契约抽取通用数据，过滤非必要字段后推送到事件总线。
• 代理的维护由遗留系统所属领域团队负责，避免集中式ETL的瓶颈与权责模糊问题。

3. 禁止集中式拉取 #

绝对不要用传统集中ETL从各领域拉取所有通用数据，这会直接破坏Data Mesh的领域自治原则，导致数据所有权模糊、维护责任不清。

二、通用数据存储策略：分布式副本+全局索引 #

1. 领域本地存储优先 #

每个依赖通用数据的领域，必须将摄入的通用数据存储在自身的领域数据存储中（如S3桶、PostgreSQL、ClickHouse）：

• 让通用数据与领域自身业务数据无缝联动，避免跨域远程调用带来的延迟与依赖风险。
• 比如电商域可将用户主数据与订单数据存储在同一个Iceberg表的分区中，方便做关联分析。

2. 可选：只读通用数据契约层 #

如果存在大量跨域高频访问的通用数据，可以搭建一个只读的全局契约存储层：

• 该层仅存储经过标准化后的通用数据副本，数据修改必须由所属领域发起，通过事件总线同步到契约层。
• 用Apache Iceberg或Delta Lake做分层存储，上层是快照式的标准化通用数据，下层是各领域的原始摄入数据，方便回溯与审计。

3. 全局元数据索引 #

搭建统一的元数据服务（如Atlas、自研元数据平台），记录以下信息：

• 通用数据的所属领域、契约版本
• 各依赖领域的存储位置、更新时间
• 数据字段的含义与使用场景
• 帮助其他领域快速定位所需通用数据的副本位置，避免重复采集与存储。

三、真实落地案例：某零售集团Data Mesh实践 #

该集团涵盖零售、供应链、电商、财务四个核心领域，核心痛点是用户主数据、商品基础编码跨域不一致、访问效率低：

1. 契约制定：跨域治理小组联合用户域、商品域团队，定义了用户主数据的Avro契约（包含用户ID、手机号、会员等级等12个核心字段）和商品编码规范，明确用户域负责用户主数据全生命周期管理，商品域负责商品编码维护。
2. 摄入流程：用户域的CRM系统通过Debezium捕获用户变更事件推送到Kafka；供应链域、电商域的Flink作业订阅该事件，将用户数据同步到自身的ClickHouse集群。对于老旧ERP中的商品编码，部署在ERP节点的Flink CDC代理定时抽取符合契约的编码数据，推送到事件总线供其他领域订阅。
3. 存储布局：每个领域在自身的S3桶中存储通用数据副本，电商域将用户主数据与订单数据关联存储，方便用户行为分析；同时搭建基于Elasticsearch的全局元数据索引，记录每个通用数据字段的所属领域与存储路径，财务域查询用户数据时，直接通过索引找到电商域的存储位置按需拉取。
4. 落地效果：通用数据一致性提升至96%，跨域数据访问延迟降低62%，各领域团队自主维护自身通用数据副本，集中式数据团队工作量减少70%。

内容的提问来源于stack exchange，提问作者Nava