Image Courtesy of Ronan Furuta on Unsplash.
询问数据行业的任何人这些天最热门的是什么，“数据网格”很有可能会上升到列表的顶部。但是什么是数据网格，为什么要构建一个？求知者想知道。
在自助式商业智能时代，几乎每家公司都认为自己是一家数据优先的公司，但并不是每家公司都以应有的民主化和可扩展性水平来对待他们的数据架构。 例如，贵公司将数据视为创新的驱动力。你的老板是业内最早看到 Snowflake 和 Looker 潜力的人之一。或者，您的 CDO 带头开展了一项跨职能计划，对团队进行数据管理最佳实践教育，而您的 CTO 投资了一个数据工程团队。然而，最重要的是，您的整个数据团队希望有一种更简单的方法来管理组织不断增长的需求，从处理永无止境的临时查询流到通过中央 ETL 管道处理不同的数据源。 支持这种民主化和可扩展性的愿望是意识到您当前的数据架构（在许多情况下，孤立的数据仓库或具有一些有限实时流功能的数据湖）可能无法满足您的需求。 幸运的是，寻求新的数据租约的团队只需要查看数据网格，这是一种席卷整个行业的架构范式。
什么是数据网格？
就像软件工程团队从单体应用程序过渡到微服务架构一样，数据网格在很多方面都是微服务的数据平台版本。 正如 ThoughtWorks 顾问和该术语的原始架构师 Zhamak Dehghani 首次定义的那样，数据网格是一种数据平台架构，它通过利用面向领域的自助式设计来包含企业中无处不在的数据。借用 Eric Evans 的领域驱动设计理论，一种将代码的结构和语言与其相应的业务领域相匹配的范式，数据网格被广泛认为是数据的下一个重大架构转变。
与在一个中央数据湖中处理数据消耗、存储、转换和输出的传统单片数据基础设施不同，数据网格支持分布式、特定于领域的数据消费者，并将数据视为产品，每个领域处理自己的数据管道。连接这些域及其相关数据资产的组织是一个通用互操作性层，它应用相同的语法和数据标准。
我们将把数据网格的定义归结为几个关键概念，并重点介绍它与传统数据架构的区别，而不是重新发明Zhamak经过深思熟虑构建的轮子。
（不过，如果你还没有读过她的开创性文章，我强烈建议你读一读《如何从一个单一的数据湖转移到一个分布式的数据网格》，或者看看马克斯·舒尔特（Max Schulte）关于Zalando为什么要过渡到数据网格的技术演讲。你不会后悔的）。
At a high level, a data mesh is composed of three separate components: data sources, data infrastructure, and domain-oriented data pipelines managed by functional owners. Underlying the data mesh architecture is a layer of universal interoperability, reflecting domain-agnostic standards, as well as observability and governance. (Image courtesy of Monte Carlo Data.)
面向领域的数据所有者和管道
数据网格联合了域数据所有者之间的数据所有权，域数据所有者负责将其数据作为产品提供，同时也促进了跨不同位置的分布式数据之间的通信。
虽然数据基础架构负责为每个域提供处理数据的解决方案，但域的任务是管理数据的摄取、清理和聚合，以生成可供商业智能应用程序使用的资产。每个域负责拥有自己的ETL管道，但一组应用于所有域的功能，用于存储、编目和维护对原始数据的访问控制。一旦数据被提供给给定域并由其转换，域所有者就可以利用这些数据满足其分析或运营需求。
自助服务功能
数据网格利用面向领域的设计原则来提供自助式数据平台，允许用户抽象技术复杂性并专注于各自的数据用例。
正如Zhamak所概述的，面向领域设计的一个主要问题是维护每个领域中的数据管道和基础设施所需的工作和技能的重复。为了解决这个问题，data mesh收集和提取与领域无关的数据基础设施功能，并将其整合到一个中央平台中，该平台处理数据管道引擎、存储和流式基础设施。同时，每个域负责利用这些组件来运行定制的ETL管道，为它们提供必要的支持，以方便地为其数据提供服务，并提供真正拥有流程所需的自主权。
通信的互操作性和标准化
每个域的基础都是一套通用的数据标准，在必要时帮助促进域之间的协作，而且通常是这样。不可避免的是，一些数据（包括原始数据源和经过清理、转换和服务的数据集）将对多个领域有价值。为了实现跨域协作，数据网格必须在格式、治理、可发现性和元数据字段等数据功能上实现标准化。此外，就像单个微服务一样，每个数据域都必须定义并商定SLA和质量度量，以“保证”其消费者。
为什么要使用数据网格？
直到最近，许多公司还利用连接到无数商业智能平台的单一数据仓库。这些解决方案由一小群专家维护，并经常背负着沉重的技术债务。
2020年，du jour体系结构是一个具有实时数据可用性和流处理的数据湖，其目标是从集中式数据平台获取、丰富、转换和服务数据。对于许多组织来说，这种体系结构在以下几个方面存在不足：
中央ETL管道减少了团队对不断增加的数据量的控制
随着每家公司成为一家数据公司，不同的数据用例需要不同类型的转换，这给中央平台带来了沉重的负担
这样的数据湖会导致断开连接的数据生产者、不耐烦的数据消费者，更糟糕的是，积压的数据团队难以跟上业务需求的步伐。相反，面向领域的数据架构（如数据网格）为团队提供了两全其美的优势：一个集中的数据库（或分布式数据湖），其中的域（或业务区域）负责处理自己的管道。正如Zhamak所说，数据架构可以通过分解成更小的、面向领域的组件来最容易地扩展。
数据网格通过为数据所有者提供更大的自主权和灵活性，促进更大的数据实验和创新，同时减轻数据团队通过单个管道满足每个数据消费者的需求的负担，为数据湖的缺点提供了解决方案。
同时，数据网格的自助式基础设施即平台为数据团队提供了一种通用的、与领域无关且通常自动化的方法来实现数据标准化、数据产品沿袭、数据产品监控、警报、日志记录和数据产品质量指标（换句话说，数据收集和共享）。总而言之，与传统数据架构相比，这些优势提供了竞争优势，传统数据架构通常因摄取者和消费者之间缺乏数据标准化而受阻。
网格化还是不网格化：这是个问题
处理大量数据源并需要对数据进行试验（换句话说，快速转换数据）的团队考虑利用数据网格是明智的。 我们进行了一个简单的计算，以确定您的组织投资数据网格是否有意义。请用一个数字回答下面的每个问题，然后将它们加在一起得出总分，换句话说，就是您的数据网格分数。
- 数据源的数量。贵公司有多少数据源？
- 您的数据团队的规模。您的数据团队中有多少数据分析师、数据工程师和产品经理（如果有）？
- 数据域的数量。有多少职能团队（营销、销售、运营等）依赖您的数据源来推动决策制定，您的公司有多少产品，以及正在构建多少数据驱动的功能？加总。
- 数据工程瓶颈。数据工程团队多久会成为实施新数据产品的瓶颈，从 1 到 10，1 表示“从不”，10 表示“总是”？
- 数据治理。从 1 到 10，1 表示“我可以不在乎”，10 表示“它让我彻夜难眠”，您的组织的数据治理有多少优先级？
数据网格得分
通常，您的分数越高，您公司的数据基础架构要求就越复杂和苛刻，反过来，您的组织就越有可能从数据网格中受益。如果您的得分高于 10，那么实施一些数据网格最佳实践可能对您的公司有意义。如果您的得分高于 30，那么您的组织处于数据网格的最佳位置，您将明智地加入数据革命。 以下是如何分解你的分数：
- 1-15：鉴于数据生态系统的规模和单维性，您可能不需要数据网格。
- 15-30：您的组织正在迅速成熟，甚至可能正处于真正能够依靠数据的十字路口。我们强烈建议结合一些数据网格最佳实践和概念，以便以后的迁移可能更容易。
- 30 或以上：您的数据组织是您公司的创新驱动力，数据网格将支持任何正在进行或未来的计划，以使数据大众化并在整个企业内提供自助分析。
随着数据变得越来越普遍以及数据消费者的需求不断多样化，我们预计数据网格对于拥有 300 多名员工的基于云的公司将变得越来越普遍。
Image Courtesy of Meme Generator.net.
不要忘记可观察性
对于数据行业的许多人来说，使用数据网格架构的巨大潜力既令人兴奋又令人生畏。事实上，我们的一些客户担心数据网格不可预见的自治和民主化会带来与数据发现和健康以及数据管理相关的新风险。 鉴于围绕数据网格的相对新颖性，这是一个相当值得关注的问题，但我鼓励有好奇心的人阅读细则。数据网格实际上并没有引入这些风险，而是要求您的数据具有可扩展的、自助式的可观察性。 事实上，如果没有可观察性，域就无法真正拥有自己的数据。根据 Zhamak 的说法，任何好的数据网格所固有的这种自助服务能力包括：
- 静态和动态数据加密
- 数据产品版本控制
- 数据产品架构
- 数据产品发现、目录注册和发布
- 数据治理和标准化
- 数据生产沿袭
- 数据产品监控、警报和日志记录
- 数据产品质量指标
当打包在一起时，这些功能和标准化提供了一个强大的可观察性层。数据网格范式还为各个域规定了一种标准化的、可扩展的方式来处理这些不同的可观察性租户，从而允许团队回答这些问题等等：
- 我的数据是新鲜的吗？
- 我的数据是否损坏？
- 如何跟踪架构更改？
- 我的管道的上游和下游依赖项是什么？
如果你能回答这些问题，你就可以放心，你的数据是完全可观察的——并且是可信的。
