序

几十年来，我一直致力于为大公司开发软件，如何管理数据一直是一个主要的架构问题。在我职业生涯的早期，人们非常热衷单个企业范围的数据模型，这种模型通常存储在单个企业范围的数据库中。但是我们很快发现，让大量应用程序访问共享数据存储是临时耦合的灾难。即使没有这些，也存在着更深层次的问题。企业的核心概念，比如“客户”，需要在不同的业务单元中使用不同的数据模型。同时，企业收购进一步加剧了这种复杂性。

作为回应，更明智的企业选择将数据去中心化，将数据存储、模型和管理分散到不同的业务单元中。这样，最了解其领域中的数据的人就负责管理这些数据。它们通过定义良好的API与其他领域协作。由于这些API可以包含行为，因此对于如何共享数据，我们有了更多的灵活性，更重要的是，随着时间的推移，我们可以演进数据管理的方式。

虽然这已逐渐成为习以为常的方式，但在数据分析领域，它仍然是一项中心化的活动。数据仓库的目的是提供一个企业存储库，存储经过挑选的关键信息。但是这样一个中心化的团队的工作很难做，需要应对互相冲突的客户，特别是在他们对数据或者消费者的需求都没有一个很好的理解的情况下。数据湖有助于普及对原始数据的访问，使分析师更接近原始数据源，但太容易成为数据沼泽，其中的数据令人难以理解，也没有可靠的出处。

Data Mesh试图将我们从操作型数据中学到的经验教训应用到分析型数据中。业务部门负责通过API发布分析型数据，这种方式与操作型数据相同。它们将数据作为最重要的产品来处理，可以传达数据的意义和来源，并且与它们的消费者协作。为了使这项工作变得可行，企业需要提供一个平台来构建和发布这些数据产品，同时还需要一个联邦治理结构来保持它们的一致性。所有这些都是以卓越的技术作为支撑的，以便平台和产品能够随着业务需求的变化而迅速发展。

因此，Data Mesh本质上是一个相当简单的、应用于分析型数据的数据管理原则。然而，在实践中，要做到这一点还有很多工作要做，特别是很多供应商的投资都聚焦在中心化的模型上，而不去支持业务系统开发人员所知道的一些实践（如测试、抽象构建和重构），这些实践对于健康的软件至关重要。

Zhamak一直工作在该领域的前沿，为客户提供前进道路上的建议，从他们的挫折和成功中学习，并推动供应商生产工具，使构建这些平台变得更加容易。本书收集了她和她的同事在早期但重要的阶段在世界各地应用Data Mesh的知识。在审校本书的时候，我就已经学到了很多关于解决这些实际困难的知识。我相信，如果你希望你的组织能最大化利用数据资源，你会发现本书恰好指明了前进道路上的最佳方向。

——Martin Fowler

Thoughtworks 首席科学家