数据网格架构：企业的去中心化数据

30 年来，集中式数据仓库一直是占主导地位的企业数据架构。在这个模型中，中央数据工程团队拥有企业的数据基础设施——从源系统获取数据，清理和转换数据，并通过中央仓库或数据湖将其提供给消费者。业务团队请求新数据，等待中央团队交付数据，并接受单个中央团队针对组织的所有数据需求做出的优先级决策。

当数据量可控、数据源有限且业务变化速度较慢时，该模型效果相当好。在现代企业环境中，它会严重失败，其特点是有数千个数据源、数十个分析用例争夺中央团队带宽，以及业务团队需要以天而不是季度为单位进行数据访问。

数据网格是对这些限制的架构和组织响应。它不是将数据所有权集中在平台团队中，而是将所有权分配给最了解数据的业务领域 - 生成数据的团队。它没有将数据视为运营的副产品，而是将数据视为具有消费者、质量标准和服务水平的产品。

要点

数据网格将数据所有权分配给领域团队，而不是将其集中在中央数据团队中

四个原则：域所有权、数据即产品、自助数据基础设施和联合计算治理

数据网格解决了集中式数据架构的可扩展性、质量和敏捷性问题

实施需要技术平台投资和重大组织变革

自助数据基础设施平台是技术基础——没有它，领域团队就无法有效地拥有数据

联邦治理确保一致性和合规性，而不会重新产生中心瓶颈

数据网格并没有消除中央数据团队 - 它将他们的角色从生产者转变为平台提供商和推动者

大多数组织应该从最痛苦的领域开始逐步实施数据网格

集中式数据架构的问题

要理解为什么数据网格引起了企业如此多的兴趣，您需要了解大规模集中式架构的具体痛点。

中央团队瓶颈

在集中式模型中，数据工程团队拥有所有数据管道。每个新数据源都需要中央团队的努力来集成。每个新的分析用例都需要中央团队的开发时间。每个数据质量问题都必须由中心团队诊断和解决。

随着组织的发展和数据用例的激增，中央团队成为瓶颈。业务团队等待数据集成需要 2-6 个月的时间。数据质量问题无法解决，因为中央团队没有领域上下文来诊断根本原因。分析计划因与其他优先事项竞争的数据基础设施工作而被延迟。

队列的增长速度超过了团队的增长速度。添加更多的核心数据工程师并不能解决根本问题——它会暂时减缓瓶颈，而底层架构问题仍然存在。

领域专业知识差距

中央数据团队知道如何构建管道。他们不知道他们正在处理的数据的业务语义。在销售领域与服务领域中，“客户”意味着什么？什么构成履行域中的“已完成”订单？订阅产品销售的正确收入确认规则是什么？

领域专家（生成数据的业务团队）拥有这些知识。中央团队则不然。这种专业知识差距会产生难以诊断和修复的数据质量问题，因为修复者缺乏理解错误的上下文。

不一致和低信任度

当不同的团队构建自己的解决方法时——直接从源系统提取数据、构建本地数据存储、维护部门级电子表格——核心的“单一事实来源”断裂。 “收入”和“活跃客户”等多个版本的指标在团队中激增，在定义上存在微小但重要的差异。

企业领导者不再信任数据，转而求助于直觉，并抵制数据驱动的决策——不是因为他们拒绝这个概念，而是因为数据不可靠。

数据网格的四个原则

Zhamak Dehghani 于 2019 年在 ThoughtWorks 期间创造了“数据网格”一词，并通过四个原则对其进行了定义。

原则 1：数据的域所有权

在数据网格中，业务领域拥有自己的数据——生产、质量和发布。销售域拥有销售数据。供应链域拥有库存和履行数据。客户域拥有客户资料和参与数据。

领域所有权意味着：领域团队对他们发布的数据的质量、产生数据的管道基础设施以及他们为消费者承诺的服务水平负责。当数据错误时，领域团队会修复它——他们有责任和领域专业知识来这样做。

这并不意味着每个领域团队都成为数据工程团队。自助数据基础设施平台（原则 3）提供了使域所有权切实可行的工具，而无需在每个域中拥有深厚的数据工程专业知识。

原则 2：数据即产品

在数据网格中，数据被视为一种产品——与消费者、质量标准、文档和服务水平一样，就像任何其他产品一样。

数据产品是一种有界数据资产，它：

拥有明确的所有权（领域团队）
可发现（消费者可以通过数据目录找到它）
有记录（消费者了解它包含什么以及如何使用它）
有质量标准（测量和维护准确性、完整性、及时性）
已定义服务级别（新鲜度、可用性、访问延迟）
具有明确定义的接口（消费者通过定义的 API 或查询接口访问数据，而不是通过访问源系统）

“产品”思维改变了领域团队对他们发布的数据的看法。数据管道是一个实现细节；数据产品是为消费者服务的，必须维护。这种框架的转变推动了围绕质量和可靠性的不同行为。

原则 3：自助式数据基础设施

仅当域具有无需专门的数据工程专业知识即可进行数据管道开发、质量监控和数据产品发布的工具时，数据的域所有权才实用。

自助数据基础设施平台提供：

数据管道工具：领域工程师无需深厚的数据工程专业知识即可使用低代码或配置驱动的管道开发
数据质量框架：域可以配置和监控的自动化质量测试、异常检测和质量评分仪表板
数据目录集成：通过元数据提取在企业数据目录中自动注册新数据产品
访问控制：基于策略的访问管理，域无需 IT 参与即可配置
消费接口：消费者可以使用标准化的查询接口（SQL、API），无论哪个域产生数据
监控和可观察性：管道运行状况监控、数据新鲜度仪表板以及领域团队可以操作的警报

构建这个平台是数据网格的主要技术投资。如果没有它，数据网格就会分散责任而无法实现能力——这会导致混乱而不是授权。

原则 4：联邦计算治理

去中心化数据所有权并不意味着放弃治理。数据网格使用联合治理——域在本地应用的集中定义的标准。

中央治理功能定义：数据质量标准、安全和隐私策略、互操作性标准（通用数据格式、标识符标准）、监管合规性要求以及所有数据产品必须符合的数据目录架构。

域在其数据产品中实施这些标准。治理功能通过自动策略执行而不是手动审核来验证合规性。

“计算”治理意味着治理策略是通过代码自动执行的，而不是通过手动审批流程。访问控制由平台应用；数据质量标准通过自动化测试进行验证；安全策略由基础设施强制执行。这使得治理具有可扩展性——不需要中央团队手动审查每个数据产品。

数据网格架构实践

数据域设计

设计数据域是第一个实际挑战。域边界应与业务域边界保持一致——具有明确数据责任和业务上下文所有权的组织单位。

常见的领域设计模式：

运营领域：匹配现有业务部门 - 销售、营销、财务、运营、人力资源、供应链。每个域都拥有其操作系统生成的数据。

客户域：聚合的客户档案数据通常由专门的客户数据团队拥有，是一个常见的交叉域。

分析域：一些组织创建专用分析域，聚合来自多个运营域的数据以用于特定分析目的 - 财务分析域结合了来自销售、运营和财务的数据。

应绘制域边界以最大程度地减少跨域依赖性 - 如果一个域的数据的很大一部分来自另一个域，则可能需要重新绘制边界。

数据产品剖析

数据网格实现中的数据产品通常包括：

输入数据：来自操作系统的源数据，通过事件流（Kafka）、API 调用或数据库复制使用。

转换代码：将原始源数据转换为已发布数据产品的管道逻辑。通常通过 CI/CD 部署作为版本控制中的代码进行管理。

输出接口：向消费者提供数据的形式——共享查询层中的表、API 端点、事件流或物化视图。

质量合同：定义和测试的质量标准 - 无效率、新鲜度要求、引用完整性检查、业务规则验证。

元数据：模式定义、数据字典、沿袭信息和操作文档 - 自动注册在数据目录中。

可观察性：管道健康监控、新鲜度仪表板和质量评分跟踪。

技术平台选择

数据网格实现堆栈因组织、云平台和现有工具而异：

数据目录：Atlan、Collibra、Alation、DataHub（开源）、Google Dataplex、AWS Glue 数据目录。为数据产品提供可发现层。

数据质量：远大前程（开源）、蒙特卡洛、Soda、Anomalo。自动化数据质量测试和异常检测。

管道编排：dbt（数据转换）、Apache Airflow、Prefect、Dagster。数据转换和管道编排工具领域用于构建其管道。

查询层：Databricks Unity Catalog、Snowflake、BigQuery、Amazon Redshift。消费者用来查询来自多个域的数据产品的共享分析查询层。

访问管理：Apache Ranger、AWS Lake Formation、Databricks Unity Catalog。基于策略的跨域访问控制。

事件流：Apache Kafka、AWS Kinesis、Google Pub/Sub。面向流媒体消费者的实时数据产品界面。

与分析和 Power BI 集成

数据网格架构提供了分析团队使用的域拥有的数据基础。数据网格和分析工具之间的接口至关重要。

数据网格 + Power BI

在数据网格架构中，Power BI 通过共享查询层（通常是 Lakehouse（Databricks、Azure Synapse、Microsoft Fabric）或数据仓库（Snowflake、BigQuery、Redshift））连接到域数据产品。

领域数据产品在查询层以表或视图的形式发布。 Power BI 语义模型（数据集）构建在这些领域数据产品之上。数据消费者（分析师、业务用户）根据语义模型构建报告，而无需了解哪个域生成了底层数据。

Microsoft Fabric 的 OneLake 特别适合数据网格架构 - 它提供了一个统一的存储层，领域团队可以在其中发布其数据产品，并提供 Power BI 和其他分析工具使用的共享查询层。 Microsoft Fabric 中的域级工作区自然地与数据网格域边界对齐。

分析数据沿袭

成熟数据网格中最有价值的功能之一是端到端数据沿袭——通过数据产品、转换和源系统跟踪分析报告中每个数字的来源。

当 Power BI 报告显示意外的收入数字时，数据沿袭可以实现快速诊断：收入指标来自哪种数据产品？哪个域拥有它？什么样的转换逻辑产生了它？哪个源系统是最终起源？

具有沿袭功能的数据目录工具（Atlan、Collibra、DataHub）提供了这种沿袭可见性，使分析故障排除变得更快、更有效。

组织变革

数据网格既是一种组织转型，也是一种技术转型。技术架构搭建速度较快；组织转型需要更长的时间。

角色变化

中央团队的数据工程师：角色从构建生产数据管道转变为构建和维护自助数据基础设施平台。从生产者到平台建设者。这是一次有意义的职业转变，需要精心管理。

领域团队中的数据工程师：新角色——嵌入业务部门的领域数据工程师，构建和维护领域数据产品。他们需要数据工程技能和领域业务知识。

数据分析师：角色变得更加强大——借助可发现的高质量领域数据产品，分析师花在数据采集和清理上的时间更少，而花在分析上的时间更多。这需要培养更强的分析技能和数据技能。

数据产品所有者：新角色——拥有数据产品路线图、管理消费者关系并对数据质量承诺负责的领域团队成员。类似于产品经理的角色，应用于数据。

中央数据治理团队：角色从数据质量修复转变为治理标准制定和执行。从问题解决者到政策制定者。

变更管理注意事项

域数据所有权是域团队并不总是想要的责任。 “我们生产数据；为什么我们要负责数据工程？”是一种常见的反应。答案需要证明域所有权使团队能够控制自己的数据命运——更快的迭代、更好的质量以及减少对中央队列的依赖——同时提供自助服务工具，使其实际上易于管理。

高层领导的协调至关重要。数据网格要求领域领导者接受数据质量责任以及运营责任。如果没有领导层的这种承诺，领域团队即使想要控制权，也会抵制责任。

常见问题

数据网格适合中小型企业，还是只适合大型组织？

数据网格对于中央数据架构瓶颈导致真正业务难题的组织最为有利——通常是拥有 10 多个重要数据生成域、大量分析用例以及无法跟上需求的中央数据团队的组织。对于数据源较少且分析需求较简单的小型组织来说，结构良好的集中式数据仓库可能更合适。数据网格增加了组织和架构的复杂性，只有当它解决的问题确实限制了业务成果时，这种复杂性才是合理的。

数据网格实施需要多长时间？

大型企业的现实数据网格实施时间表：自助数据基础设施平台构建需要 6-12 个月，前 3-5 个领域数据产品投入运行需要 12-18 个月，覆盖大多数主要领域的计划需要 24-36 个月。组织必须现实地评估领域团队能力建设需要多长时间——将数据工程师嵌入领域团队、培训领域产品所有者以及围绕数据所有权转变领域团队文化。向数据网格实践的全面组织转型通常需要 3 到 5 年的时间，早期域实施在第一年就交付了有意义的价值。

数据湖、数据仓库、数据湖屋和数据网格之间有什么区别？

数据湖是一个以其本机格式存储原始数据的存储库。数据仓库是一种针对分析查询而优化的结构化、集成的数据存储。数据湖屋将数据湖的存储经济性与数据仓库的查询性能和治理相结合。数据网格是一种架构和组织方法，而不是一种存储技术——它描述了数据如何拥有、生产和治理。数据网格可以在数据湖、仓库或 Lakehouse 技术基础上实现。大多数现代数据网格实现都使用数据湖库（Databricks、Microsoft Fabric、Snowflake）作为共享查询层。

数据网格与微服务架构有何关系？

数据网格将微服务架构原则应用于数据管理，特别是域所有权、有界上下文和独立可部署性的思想。正如微服务将整体应用程序分解为域拥有的服务一样，数据网格将中央数据平台分解为域拥有的数据产品。这个类比延伸到组织结构：就像微服务由包括开发人员、运营和产品管理的跨职能团队拥有一样，数据产品也应该由包括数据工程师、领域专家和数据产品所有者在内的跨职能领域团队拥有。

最常见的数据网格实施失败是什么？

最常见的失败模式：在没有足够投资的情况下构建自助服务平台（在没有工具的情况下赋予域责任，造成混乱）；在继续之前未能获得领域领导层的支持（领域团队在没有领导层的组织承诺的情况下抵制所有权）；将数据网格视为纯粹的技术举措（忽略使域所有权可持续的组织变革管理）；并尝试同时跨所有域实施数据网格（组织范围内同步变更的复杂性通常会导致实施失败——从 2-3 个高痛域开始，并在扩展之前证明模型始终更成功）。

后续步骤

数据网格代表了对企业数据架构的根本性重新思考，解决了集中式模型的扩展、质量和敏捷性限制。对于遇到数据瓶颈难题的组织来说，它提供了一条获得可扩展、适合领域的数据所有权的途径。

ECOSIRE 的 Power BI 和分析服务帮助组织设计和实施位于数据网格架构之上的分析层 - 将领域数据产品连接到商业智能工具，为决策者提供洞察力。我们的团队可以就数据架构策略和分析实施提供建议，使数据网格投资转化为业务价值。

联系我们的分析和数据架构团队，讨论数据网格是否是应对您组织的数据挑战的正确方法。