数据分析工作流程和软件工程流程之间有许多相似之处。两者都必须应对不断扩大的规模和复杂性、更大的合作者网络以及更紧迫的期限。
软件工程通过从英雄心态转向团队心态来应对这种复杂性。许多业内人士意识到，与庞大的团队创建单一应用程序会导致成本增加和质量下降。因此，公司专注于创建小团队，在面向服务的架构中构建定义明确的组件。
但同样的事情并没有发生在数据上。在很大程度上，数据分析仍然以创建由单个数据工程团队管理的整体存储为中心。这会导致团队过度劳累，从而导致运输延误和数据质量下降。
我们如何将来之不易的软件工程经验带入数据领域？在本文中，我们将研究数据网格架构如何彻底改变单一数据范式，以及它如何帮助您更快、更可靠地交付数据驱动的项目。
数据网格是一种分散的数据管理架构，包含特定于域的数据。团队没有单一的集中式数据平台，而是拥有围绕自己数据的流程。
在数据网格框架中，团队不仅拥有自己的数据，还拥有与转换数据相关的数据管道和流程。中央数据工程团队维护关键数据集和一套自助服务工具，以实现个人数据所有权。然后，特定领域的数据团队通过明确定义和版本化的合同交换数据。
数据网格为何诞生
Zhamak Dehghani在 Thoughtworks 工作期间首次孵化了数据网格背后的概念。她创建了数据网格架构来解决她认为公司处理数据方式的一系列问题。
随着云的出现，更多的开发团队已经放弃单体应用程序并采用微服务架构。然而，在数据世界中，许多公司仍然将数据存储在单一数据库、数据仓库或数据湖中。
使用数据单体的架构选择会产生许多连锁反应。整体方法将数据处理管道分解为几个阶段：摄取、处理和服务。一个团队通常会处理所有这些阶段。这种方法一开始可以发挥作用，但随着规模的扩大就会失效。最终，通过单个团队集中所有请求会减慢新功能的交付速度。
在这种方法中，数据工程团队通常无法获得该模型中底层数据背后的完整上下文。由于他们负责维护来自多个不同团队的数据集，因此他们通常无法完全理解数据背后的业务原理。
这可能会导致他们做出不知情的决定，有时甚至是有害的决定，从而影响业务决策。例如，数据工程团队可能会以销售部门不期望的方式格式化数据。这可能会导致报告损坏甚至数据丢失。
整体系统很少有明确的契约或边界。这意味着上游的数据格式更改可能会破坏无数的下游消费者。结果？由于担心破坏一切，团队最终没有做出必要的改变。这导致单体系统逐渐变得过时、脆弱且难以维护。
最后，正如 dbt 创始人 Tristan Handy 指出的那样，在单一系统中协作也变得更加困难。由于没有人熟悉整个代码库，因此需要更多的人和更多的时间来完成与数据相关的任务。这会影响新产品和功能的上市时间，从而影响公司的利润。
数据网格原理
为了更清楚地了解数据网格与整体方法的不同之处，让我们看看它的一些主要原则。
数据网格的核心理念是不仅创建数据，而且创建数据产品：定义明确、独立的数据容器，用于解决业务问题。数据产品可以是简单的（表格或报告）或复杂的（整个机器学习模型）。
数据产品的标志是它定义了带有经过验证的合同和版本控制的接口。这确保了任何依赖该数据产品的人都确切地知道如何与其集成。当数据域团队将所有更改打包并部署为新版本时，它还可以防止突然和意外的损坏。
在数据网格中，拥有数据的团队真正拥有数据。这包括所有相关过程，包括摄入、加工和服务。换句话说，每个团队都拥有自己的数据管道。
在数据网格模型中，管道充当内部实现。在面向对象的编程语言中，类的方法的调用者不需要知道该方法是如何实现的。同样，数据产品的用户不需要了解数据的处理方式。
由于数据域团队拥有自己的数据，因此增加了他们的责任感和管理意识。随着时间的推移，这会带来更准确、更高质量的数据。
对于每个拥有自己数据的团队来说，重新发明轮子是没有意义的。关键数据和基本数据功能（例如，存储数据、创建数据管道、渲染分析等所需的工具）仍应由数据工程团队拥有。
在数据网格范例中，不同之处在于这些工具是开放的，可供所有需要它们的数据域团队使用。这种开放数据架构通过为每个团队提供一致且可靠的方法来创建自己的数据产品，从而实现数据民主化。
实现数据自助服务意味着结束单一数据存储强加的“数据君主制”。但结束数据君主制并不意味着拥抱数据无政府状态。
公司仍应制定并执行安全访问、数据格式和数据质量的标准。监控所有数据源是否符合行业和政府法规（例如通用数据保护条例(GDPR)）至关重要。
作为其提供的自助服务平台的一部分，数据工程还为安全和数据治理提供了一致的框架。这包括用于索引和查找数据的数据目录等工具，以及用于对敏感数据元素（例如个人身份信息）进行分类的标记工具，以及用于标记差异和验证合规性的策略执行自动化。
数据网格团队结构
基于这三个原则，我们可以确定数据网格架构中的三个主要团队和责任领域。
数据平台团队拥有自助数据平台。这是主要的集中数据以及数据工程和/或 IT 拥有的所有架构组件。
数据平台团队通常拥有数据存储（数据库、数据仓库、非结构化大型对象存储）、BI 和分析工具、安全性、策略自动化、监控和警报等架构组件。他们还维护域数据团队将使用的工具，包括合同执行、数据转换和数据管道创建工具。
数据平台团队在数据网格架构中不拥有特定数据域的单独模型、工作流、报告和流程。这项工作现在属于数据域团队——数据的真正所有者。
领域团队使用数据平台团队提供的工具来创建自己的特定领域数据产品。这些团队拥有自己的数据管道、数据合同和版本控制以及报告和分析。
领域数据团队还负责维护数据质量、正确对更改进行版本控制，并尽可能监控和降低数据相关成本。
治理团队定义数据质量和格式标准，以及用于定义、标记和标记敏感数据的数据治理策略。
数据平台团队通过安全控制和执行自动化来实施这些决策。领域数据团队将治理团队制定的标准实施到自己的数据集中。
最后，支持团队协助领域数据团队理解和采用数据平台团队提供的自助服务工具。
采用数据网格架构的好处
数据网格架构的主要好处是可扩展性。它通过数据民主化来实现这一目标。
整体方法通过单个团队汇集所有数据项目和请求，从而造成不必要的障碍。通过将数据的所有权归还给其所有者，领域数据团队可以创建新的数据产品，而无需等待不堪重负的数据工程团队。其结果是缩短了上市时间，并提供了更准确和最新的数据作为业务决策的基础。
数据网格在不牺牲治理的情况下实现了这种民主化。合规性问题通常会导致组织采用集中化策略，以更好地进行监控和执行。数据网格架构通过将节点自治与集中治理相结合来满足安全性和合规性需求。这是一种“两全其美”的方法，将合规性转变为一种支持功能，而不是一个障碍。
需要证明吗？了解Flexport 的供应链专家如何使用Snowflake 和 dbt 构建可扩展的数据网格：“自从转向使用Snowflake 的数据网格后，整个企业定期使用数据的人数增加了 5.5 倍，”Flexport 的增长主管说道和分析，Abhi
Sivasailam。
一家财富 500 强公司 1) 将数据建模方面的协作人数增加了一倍，2) 消除了 3 周的监管报告工作，以及 3)**释放了 1000 万美元，可以重新投入到业务中。**
数据网格架构的挑战
这并不意味着采用数据网格不存在任何挑战。
数据网格需要高水平的组织成熟度。从技术上讲，它需要一个强大的数据平台层来满足不同用户群的需求。从组织上讲，它需要数据领域团队以及每个团队中能够有效使用新数据平台的人员的支持。
迁移到数据网格并不是一朝一夕的事情。它需要规划、精心设计、实施以及由强大的支持功能支持的有效培训策略。
此外，如果没有适当的治理控制，就有可能陷入“数据无政府状态”，并最终导致不良、重复的数据在整个组织中扩散。采用数据网格的公司必须制定强有力的数据治理政策，以及支持该政策的自动化工具。
为什么数据网格很重要？
多年来，软件工程已经成功地接受了由“双比萨团队”执行的小工作单元的概念。每个团队都拥有自己的更大系统的组件。团队通过明确定义的版本化接口相互集成。
遗憾的是，数据尚未赶上软件的步伐。整体数据架构仍然是常态——尽管存在明显的缺点。
数据网格将从软件工程中吸取的惨痛教训带入数据工程中。在数据网格框架中，每个团队都可以定义自己的合约，并通过该团队的合约与其他团队的数据集成。数据域团队不需要了解整体数据模型，而只需了解自己的表面区域以及合作伙伴团队公开的契约。
其结果是为我们的现代数据时代提供了一个更具可扩展性的模型。数据领域团队可以更快地开发新的数据产品，并且开销更少。合同和版本控制可以最大限度地减少下游破坏，甚至可以完全消除它们。同时，中央数据团队可以继续执行标准并跟踪整个系统的数据沿袭。
数据网格并不是解决当今所有数据工程难题的灵丹妙药。但这是我们管理数据方式的重要且必要的范式转变。
原文链接：https://www.getdbt.com/blog/what-is-data-mesh-the-definition-and-importance-of-data-mesh
