了解数据网格，解决（几乎）所有数据问题的新趋势

翻译：https://keepler.io/2022/01/understanding-data-mesh/

数据网格概念并不像看起来那么新，它在 2019 年左右出现在Zhamak Dehghani之手，她可以被认定为数据网格创始人（正如她自己定义的那样）。

这个概念的想法是，以某种方式消除或至少最小化在数据平台架构、数据管理和数据团队中使用的单一和集中方法的约束，即数据仓库和数据湖管理由一个中央团队。Data Mesh建议采用基于分布式架构和业务领域（域）对其数据的责任（治理角色的去中心化）的去中心化模型。本质上，它是指将数据湖和数据仓库分解为更小、更分散的部分的概念。

数据网格建立在四个原则之上：

• 第一个原则基于面向领域的分散数据所有权和架构，这意味着组织/业务功能需要拥有自己的数据。这个想法的核心是领域驱动设计（DDD）。 
• 第二个原则是将数据视为一种产品，并以对其他人可用的形式公开该领域的产品。
• 第三个原则将数据基础设施定义为以自助方式提供不同功能的平台。
• 第四个侧重于联合计算治理，平衡有足够的集中控制以简化工作，但保持决策尽可能本地化。

在一个简单的愿景中，使用 Data Mesh，您可以像组织业务和人员一样组织数据，这对问责制非常有用。 

在技​​术上，数据网格能够通过促进数据所有权的更大灵活性和自主性来解决数据仓库和数据湖的缺点。这转化为数据实验和创新的更大范围，因为负担由少数专家承担。自助式基础设施作为一个平台，为更通用、更自动化的数据标准化以及数据收集和共享方法开辟了道路。因此，通过激励共享心态，您可能会为您的数据策略做出更多贡献。

让我们在这里停一下。数据网格看起来很酷，但并非适用于所有人

公司必须意识到，这并不是一个适用于所有情况的方法。数据网格不能仅仅因为它是一种趋势而被应用。必须进行评估，并且必须从这样的决定中获得业务收益。

数据网格策略可以使拥有分散模型的组织受益，这些模型具有多个域和源复杂性。它可以帮助高度分散的组织，因为数据网格结构允许不同的团队管理自己的数据，并且只将质量数据作为产品提供给组织的其他部分。

这里适用康威定律。康威定律指出：“设计系统的组织被限制生产设计，这些设计是这些组织的通信结构的副本。”

在较大的组织中，具有更复杂的通信结构，集中的方法与康威定律相矛盾。因此，我们需要像 Data Mesh 这样的去中心化数据管理架构。

此时，为了考虑数据网格方法，需要分析四个方面：

• 组织稳定性
• 公司文化准备
• 数据网格方法的可靠业务案例
• 显然，预算要投资于变革！

从一个表明组织还没有为数据网格方法做好准备的角度来看，我建议阅读Thinh Ha在 Medium 上的一篇文章：“你还没有准备好采用数据网格的 10 个原因”。这10个原因是：

1. 您没有在分散化有意义的规模上运营。
2. 您没有强有力的商业案例来说明采用 Data Mesh 将如何为各个业务部门带来业务价值。
3. 您将数据网格视为具有固定目标的技术解决方案，而不是随时间不断发展的运营模型。
4. 您的组织文化不支持自下而上的决策。
5. 您没有为分布式数据团队明确建立角色和职责以及激励结构。
6. 您没有足够数量的数据人才。
7. 您的数据团队的工程成熟度较低。
8. 您希望找到现成的软件来帮助您采用 Data Mesh。
9. 您不支持“左移”安全性、隐私和合规性。
10. 您不认为数据治理是在每个数据团队的待办事项中优先于其他活动的核心活动。

数据网格实施的主要挑战

假设我们正在讨论一个符合上述数据网格方法特征的组织。在这里，我们总结了要解决的主要挑战：

• 技术匹配是任何组织努力采用和实施基于数据网格的数据管理策略的主要考虑因素之一。为了能够成功实施数据网格架构，组织需要重组其数据平台，重新定义数据域所有者的角色，并彻底改革结构以使数据产品所有权变得可行，并过渡到将其分析数据开发为产品。
• 联合数据治理模型的实施：全球治理的通信互操作性和标准化是构建分布式系统的基础支柱之一。转向去中心化数据架构的一个关键部分是理解联邦是关于去中心化所有权的，这需要很好理解的学科。
• 领域数据跨职能团队：将数据作为产品提供的领域；需要增加新的技能：(a)数据产品所有者和 (b)数据工程师。我们需要所有领域的数据技能才能构建和操作领域的内部数据管道，团队必须包括数据工程师。
• 构建数据和自助服务平台设计融合，支持并提供领域获取、处理、存储和服务其数据产品所需的必要技术。该平台必须隐藏所有底层复杂性，并以自助服务的方式提供数据基础设施组件。
• 涉及重大级别的变更管理：为了适应数据网格分散数据操作，需要大量的变更工作。
• 跨域分析：保证所有允许跨域分析的规则是一项挑战。这种向分布式数据所有权的转变只有在我们将广泛的标准应用于我们的数据产品时才有效。如果没有任何企业标准、分布和连接规则，就会创建一个无序、无组织和不兼容的生态系统，并且跨域计划是不可能的。

等一下！我已经有了数据策略，是不是意味着你需要改变它？

我们认为没有必要改变数据策略（假设存在！）。成为数据驱动公司的主要目标是相同的。也许我们可以重写它并使用“数据产品驱动公司”。

如果数据网格是公司的一种方式，那么他们必须重新考虑组织、数据管理、数据治理和数据架构策略。为什么？

公司必须设计一个路线图，从基于集中数据团队、运行数据仓库和数据湖（单体平台）和集中数据治理到新的分散范式。 

虽然集中式模型适用于具有少量域且不同消费案例数量较少的组织，但不适用于具有丰富域、大量资源和多样化业务消费者集的企业。

例如，我负责一家电信公司（各种来源和域）的中央数据团队，该团队为数据仓库执行所有 ETL 和数据湖的摄取，以便业务可以探索数据。我们很快就成了瓶颈，“政治上”成为击落的目标！即使数据工程师的数量增加了，从业务角度了解来源并解释概念的问题总是存在……但业务没有这样做的动力。顺便说一句，他们为什么要拥有它？从他们的角度来看，中央数据团队必须处理这个问题！

因此，对于数据网格来说，所有这些变化以及源和相关管道为域数据产品提供数据的责任都是域的责任。这对组织有影响，因为域需要数据技术人员（域中的数据角色）。

今天存在的数据湖和数据仓库会发生什么（架构影响）？它们很可能成为网格上的节点并被特定域使用。

让我们明确一点，这是我们对主题的看法

在 Keepler 看来，拥有数据策略意味着定义如何使用 FAIR 原则（可查找性、可访问性、互操作性和可重用性）来利用数据，以支持必须可用、可理解、可访问和可互操作的数据产品与其他数据产品。最后，数据产品为业务提供价值，它是一种将数据货币化的方式。

利用数据意味着存在允许探索和使用数据的生态系统：数据平台。

我们认为，最好的方法是拥有一个公共云数据平台，利用云提供商提供的各种服务。灵活性、可扩展性、弹性、模块化和按使用付费都是云数据平台的优势，符合分布式数据架构的特点。在本文的上下文中，这些优势适用于域节点中的平台以及连接域的中央自助数据平台。