前言
本文隶属于专栏《大数据理论体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！
本专栏目录结构和参考文献请见大数据理论体系
背景
在自助的商业智能时代，几乎每家公司都认为自己是数据优先的公司，但并非每家公司都以应有的民主化和可扩展性来对待其数据架构。
假设你的公司将数据视为创新的驱动力；你的老板是业内首批看到 Snowflake 和 Looker 潜力的老板之一；或者，你的 CDO 领导了一项跨职能倡议，对团队进行数据管理最佳实践；你的 CTO 期望于数据工程小组；然而，最重要的是，你的整个数据团队希望有更简单的方法来管理组织日益增长的需求，从而不需要处理永无止境的即席查询通过中央的 ETL 管道来竞争不同的数据源。
这种民主化和可扩展性愿望的基础是意识到你当前的数据架构（在很多情况下，是孤立的数据仓库或具有一些有限的实时计算功能的数据湖）可能无法满足您的需求。
幸运的是，数据网格（Data Mesh）可能正是你想要的，这是一个正在席卷行业的架构范式。
WHAT
就像软件设计团队从整体应用程序过渡到微服务架构一样，数据网格（Data Mesh）在很多方面来讲都是微服务的数据平台版本。
正如 ThoughtWorks 的顾问和原架构师 Zhamak Dehghani 首次定义的那样，数据网格（Data Mesh）是一种数据平台架构，通过利用面向领域的自助式设计，拥抱企业中无处不在的数据。借用 Eric Evans 的领域驱动设计理论（DDD），这是一个灵活、可扩展的软件开发范式，将代码的结构和语言与其相应的业务领域相匹配。
与在一个中央数据湖中处理数据的消耗、存储、转换和输出的传统整体数据基础设施不同，数据网格（Data Mesh）支持分布式、特定于领域的数据消费者，并视作“数据即产品”，每个领域处理自己的数据管道。连接这些领域及其相关数据资产的组织是一个通用的互操作层，应用相同的语法和数据标准。
在顶层设计上，这里有一个数据网格（Data Mesh）的示例：
数据网格（Data Mesh）架构图由三个独立的组件组成：数据源、数据基础设施和由功能所有者管理的面向领域的数据管道。
数据网格（Data Mesh）架构的基础是通用的互操作层，反映了与领域无关的标准，以及可观察性和治理性。
面向领域的数据所有者和管道
数据网格化了有责任将数据作为产品的领域数据所有者之间的联合数据所有权，同时也促进了不同位置的分布式数据之间的通信。
虽然数据基础设施负责为每个领域提供处理解决方案，但领域的任务是管理数据的摄取、清理和聚合，以生成可用于商业智能应用程序的资产。
每个领域拥有自己的 ETL 管道，但是一套功能集适用于所有领域用于存储、编目（Catalog）和维护原始数据访问控制。一旦数据被提供给给定领域并由其转换，领域所有者就可以利用这些数据来满足他们的分析或运营需求。
自助服务功能
数据网格（Data Mesh）利用面向领域的设计原则来提供自助数据平台，允许用户抽象技术复杂性并专注于其单个数据应用场景。
正如 Zhamak 所概述的，面向领域的设计的主要问题之一是维护每个领域的数据管道和基础设施所需的工作和技能重复。
为了解决这个问题，数据网格（Data Mesh）收集并提取与领域无关的数据基础设施功能，并将其提取到一个处理数据管道引擎、存储和流计算基础设施的中央平台中。
与此同时，每个领域都负责利用这些组件自定义运行 ETL 管道，为他们提供轻松服务数据所需的支持，以及真正拥有该流程所需的自主权。
通信的互操作性和标准化
每个领域的基础是一套通用的数据标准，必要时有助于促进领域之间的协作。
不可避免的是，一些数据（原始数据源和清理、转换和服务的数据集）对多个领域都有价值。
为了实现跨域协作，数据网格（Data Mesh）必须在格式、治理、可发现性和元数据字段等方面进行标准化。
此外，与单个微服务非常相似，每个数据域都必须定义并且商定他们保证给消费者的 SLA 和质量措施。
关于 SLA 请参考我的博客——SLA是什么？
为什么要使用数据网格（Data Mesh）？
直到最近，许多公司还利用了一个连接到无数商业智能平台的单一数据仓库。
这些解决方案由一小群专家维护，并经常承受巨额技术债务的负担。
对于许多组织来说，这种类型的架构在几个方面都失败了：
- 中央ETL管道使团队对越来越多的数据量控制更少
- 随着每家公司都成为数据公司，不同的数据应用场景需要不同类型的转换，给中央平台带来了沉重的负担。
这些数据湖导致数据生产者断线，数据消费者不耐烦，更糟糕的是，积压的数据团队正在努力跟上业务需求的步伐。
相反，面向领域的数据架构，如数据网格（Data Mesh），为数据团队提供了最好的一面：
一个集中式数据库（或分布式数据湖），其中领域（或业务领域）负责处理自己的管道。
正如 Zhamak 所说，通过分解为更小的、面向领域的组件，数据架构最容易扩展。
数据网格（Data Mesh）为数据湖的缺点提供了解决方案，允许数据所有者更大的自主权和灵活性，促进更大的数据实验和创新，同时减轻数据团队通过单一管道满足每个数据消费者需求的负担。
与此同时，数据网格（Data Mesh）的自助基础设施即平台（IaaS）为数据团队提供了通用的、与领域无关的、通常自动化的数据标准化、数据产品血缘、数据产品监控、警报、日志记录和数据产品质量指标（换句话说，数据收集和数据共享）。
总而言之，与传统数据架构相比，这些优势提供了竞争优势，传统数据架构往往因摄取者和消费者之间缺乏数据标准化而受到阻碍。
网格还是不网格，这是一个问题
处理大量数据源并需要尝试数据（换句话说，快速转换数据）的团队考虑利用数据网格（Data Mesh）是明智的。
我们汇总了一个简单的计算，以确定你的组织投资数据网格（Data Mesh）是否有意义。
请用一个数字回答下面的每个问题，并将它们加在一起，换句话说，你的数据网格（Data Mesh）分数总分。
- 数据源的数量。你们公司有多少个数据源？
- 数据团队的规模。你的数据团队中有多少数据分析师、数据工程师和产品经理（如果有的话）？
- 数据域数量。有多少功能团队（营销、销售、运营等）依赖你的数据源来推动决策，你的公司有多少产品，以及正在构建多少数据驱动的功能？加上总数。
- 数据工程的瓶颈。数据工程团队多久会成为实施新数据产品的瓶颈，用 1 到 10 来表示，其中 1 是“永不”，10 是“永远”？
- 数据治理。你们组织的数据治理具有多大优先级，用 1 到 10 来表示，其中 1 是“我可以不在乎”，10 是“它让我彻夜难眠”？
数据网格（Data Mesh）得分
一般来说，你的分数越高，你公司的数据基础设施要求就越复杂和苛刻，也就是说，你的组织从数据网格（Data Mesh）中受益的可能性就越大。
如果你的分数超过 10 分，那么实施一些数据网格（Data Mesh）最佳实践对你的公司来说可能是有意义的。
如果你的得分超过 30 分，那么你的组织加入数据革命是明智的。
以下是分解分数的方法：
- 1-15：鉴于数据生态系统的大小和一维性，你可能不需要数据网格（Data Mesh）。
- 15-30：你的组织正在迅速成熟，甚至可能处于真正能够依赖数据的十字路口。我们强烈建议纳入一些数据网格（Data Mesh）最佳实践和概念，以便以后的迁移可能更容易。
- 30 或以上：你的数据组织是你公司的创新驱动力，数据网格（Data Mesh）将支持任何正在进行的或未来的举措，以实现数据民主化，并在整个企业提供自助分析。
随着数据变得更加无处不在，数据消费者的需求继续多样化，我们预计，对于拥有 300 多名员工的云公司来说，数据网格（Data Mesh）将变得越来越普遍。
不要忘记数据可观察性
对于数据行业的许多人来说，使用数据网格（Data Mesh）架构的巨大潜力既令人兴奋又令人生畏。
事实上，我们的一些客户担心数据网格（Data Mesh）的不可预见的自主性和民主化带来了与数据发现和健康以及数据管理相关的新风险。
鉴于数据网格的相对新颖性，这是一个公平的问题，但我鼓励好奇的人阅读细则。
数据网格实际上没有引入这些风险，而是要求在你的数据中具有可扩展的、自我维护的可观察性。
事实上，如果领域没有可观察性，它们就无法真正拥有自己的数据。
根据 Zhamak 的说法，任何良好的数据网格固有的自助服务能力包括：
- 静态和动态数据的加密
- 数据产品版本控制
- 数据产品模式（Schema）
- 数据产品发现、目录（Catalog）注册和发布
- 数据治理和标准化
- 数据生产血缘
- 数据产品监控、警报和日志记录
- 数据产品质量指标
当打包在一起时，这些功能和标准化提供了一层强大的可观察性。
数据网格（Data Mesh）范式还规定，单个领域具有标准化、可扩展的方式来处理这些可观察性的各种租户，允许团队回答这些问题：
- 我的数据是新鲜的吗？
- 我的数据坏了吗？
- 如何跟踪模式（Schema）更改？
- 我的管道的上游和下游依赖性是什么？
如果你能回答这些问题，你可以放心，你的数据是完全可观察的，并且是可以信任的。
参考
Data Mesh Applied — Sven Balnojan
The Data Mesh: Re-Thinking Data Integration — Kevin Petrie
Should Your Application Consider Data Mesh Connectivity? — Joe Gleinser
596
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
