【数据网格】如何选择数据网格技术

目前有一个特别的问题经常出现：数据网格应该使用什么技术？人们经常问Databricks是否是一个不错的选择，或者他们是否应该使用AWS、Snowflake或开源选项。然而，正如微服务没有合适的技术一样，数据网格也没有合适的科技。这意味着，虽然这篇博客文章不会为您提供技术的购物清单，但它会为您提供一些帮助，帮助您了解现有的技术，以及您应该如何为网格实现评估它。

数据网格是一种范式，而不是一种解决方案架构

不同的组织将有不同的数据网格实现，由不同的架构支持。简而言之，数据网格是一种风格，而不是单一的架构。这意味着在AWS、Azure或谷歌上构建网格的方法不止一种。Mesh的一个很好的基本情况是“类似于微服务，但适用于分析数据”。

这意味着没有一个简单的技术列表可以让你开始做数据网格。正如我们将看到的，有一些有用的工具，但与其直接深入研究这些工具，不如考虑数据网格的特性或功能，这将帮助我们了解需要什么类型的工具以及用于什么目的。

要做到这一点，最简单的方法是从数据网格的核心原则开始，并从技术角度考虑这些原则的含义：

领域所有权

这需要根据明确的价值流而不是技术边界来划分数据产品。同样重要的是，每个单独的数据产品团队都要能够管理自己的管道和策略，以及数据存储和输出端口（如API）。

数据作为产品

数据的消费者希望数据的形式适合他们。团队需要能够以取悦数据消费者的方式转换和分发数据。正是出于这个原因，数据作为产品的原则需要一个灵活适应数据产品需求的多语言生态系统。这需要灵活性，并可能限制您的技术选择——尽管固执己见的现成解决方案可能看起来很棒，但可能会受到限制。

自助数据平台

在基础设施方面，团队不应该不断地重新发明轮子——这会浪费他们的时间和精力，使他们无法专注于构建出色的数据产品。自助式平台赋予开发人员权力并为其提供支持，以便处理资源调配等任务。

联合计算治理

数据网格产品应该具有一定程度的互操作性——这意味着我们需要确保分布式所有权与标准化相平衡。这有两个关键原因：第一是为了使数据产品在组织内部更容易被发现，第二是为了保证和保持一定的质量、互操作性和安全标准。

将原理映射到功能和技术

现在我们已经概述了数据网格的核心原理，我们可以开始将这些原理映射到许多特性和功能中。（为了简单起见，我将域所有权和数据作为一种产品合并为“数据产品”。）

对于每一个，我都包含了一些可能使用的工具。

平台

• 提供共享功能（API、UI、连接器代码）
  • 基础设施作为代码工具，如Terraform、Ansible或CloudFormation等；非现成数据平台API；持续集成工具，如Jenkins。
• 流功能
  • Kafka、MQ、Flink、Kinesis等工具。
• 开发人员门户网站（完全集成）
  • 内部构建或使用类似Spotify后台的东西。

治理

• 目录（文档和元数据索引；可发现的爬网程序）
  • Wiki工具，如confluence （用于基本目录）；商业目录，如collibra或开源选项-amundsen、DataHub。
• 数据和API标准
  • 数据治理工具、wiki、swagger、开放数据协议
• 访问策略
  • wiki、目录元数据、可能在数据产品中实现的单个策略、自定义http API或集成工具的OPA或类似功能、Hadoop的ranger
• 监控和自动化法规遵从性
  • 数据治理工具；数据可观察性工具和库，如Great Expecteds.io、内部仪表板
• 数据沿袭
  • 数据沿袭工具或具有集成沿袭的数据治理工具也可以在ETL（例如，pachyderm）或存储（例如，delta lake）中
• IDM集成
  • 数据存储工具中的自定义代码或连接器。

数据产品

• 数据存储
  • 数据库：SQL、NoSQL、Graph、Search。
• 输入和输出端口
  • 自定义API、ETL工具、连接器（例如流输入或BI或报告输出的插件）
• 跨产品集成
  • 数据虚拟化工具、starburst.io、云提供商或现成的数据平台工具

关于所有这些类型的工具，我在GitHub中的概述提供了更多详细信息。

数据所有权如何？

数据所有权并不能转化为功能，更多的是组织实践和流程的问题。然而，这并不意味着在数据网格实现的背景下没有一些重要的事情需要考虑：域驱动设计、事件风暴、团队拓扑、用例和发现研讨会等方法在数据网格中都特别有用。

从轻量级解决方案到成熟的开发人员体验门户

需要注意的是，您可能需要一系列可能的功能。在最复杂和“成熟”的一端，您可能有一个数据产品开发人员体验门户，其中所有内容都是自动提供的。这将从本质上为开发人员提供一个向导，可以从中创建新的数据产品，从而非常容易地选择他们想要的数据存储技术，以及输入、输出端口和连接器等技术。这本质上就是Zhamak Dehghani所说的“体验飞机”（你可以在网络研讨会“数据网格中的沟渠教训”中看到更多体验飞机的样子。）

构建开发人员体验门户很困难。你当然不应该觉得这很重要。在更轻量级的一端，你可以只使用模板来为数据产品提供自举基础设施，并使用wiki来创建数据目录；这仍然可能非常有效。Zhamak Dehghani建议（在上述网络研讨会的52:00）尽早建立平台API，即使它们最初并没有完成你希望它们做的一切。你可以从较轻的一端开始，并根据需要逐渐向平台添加更多。

我可以使用现成的解决方案吗？

有现成的云和数据平台解决方案可用于数据网格实现。在这里，我指的不仅仅是特定的工具，而是将自己定位为端到端平台的解决方案。这些都有价值，但应该注意的是，在撰写本文时，它们通常是通用的。如果你正在寻找开发人员体验平台提供的定制级别，你必须自己开发。

如果你有兴趣使用现成的解决方案，你可以在GitHub上找到我对一些领先供应商的功能的概述。

如果你正在考虑现成的方法，你需要记住一些注意事项：

1. 现成的数据平台基于服务/功能，而不是数据产品。因此，无法说你想构建一个数据产品，它应该有一定的存储和输出端口等。因此，现成的数据平台无法提供真正的网格体验平面。
2. 现成的数据平台没有自定义数据API的概念。可能有通用数据API，但如果开发人员想编写代码来公开数据或机器学习模型的自定义API，则可能需要走出数据平台。
3. 他们的ETL理念不是多语言的——他们通常固执己见（针对平台的本地存储和元数据进行集成）。
4. 他们提供了一种通用的体验，而没有任何选择来策划开发人员从中选择什么工具。
5. 基于帐户的租赁模型可能具有非常严格的限制性。如果你试图在一个云帐户中做很多事情，那么你很可能会达到极限（如“数据网格中战壕的教训”中所述）。

尽管有这些注意事项，但现成的平台对网格实现无疑是有价值的。重要的是要记住，它们不是数据网格平台；none（在撰写本文时）是成功实现数据网格的灵丹妙药。

那么，我该如何为数据网格选择技术呢？

希望您现在能更清楚地了解技术选项是什么，以及您可能需要在网格实现中使用哪些元素。但你可能仍然有一些高水平的工具选择问题，你不确定。你知道你的用例和环境，所以你需要根据你的目标和公司的技术战略来决定如何选择工具。我能提供的是一些关于关键主题的一般性建议：

• 您应该使用现成的数据平台还是组装自己的数据平台？要决定这一点，您需要考虑成本、具体用例以及您希望平台体验的定制程度等因素。
• 你需要一个数据平台UI吗？或者你可以用一个API，甚至只是一些指导和模板吗？尽早构建平台是件好事，但您最初几个用例的初始平台可能与最终使用的平台不同。让一个平台尽早启动第一批数据产品与在平台上投入大量资金之间存在权衡。
• 您是否需要扩展到策略和监控的治理？这可能取决于您的数据的敏感性，您对其潜在质量和互操作性的关注程度，以及质量或数据安全问题对您的用例的影响。
• 最重要的建议是尽早确定关键的用例。如果你试图在不清楚用例的情况下评估工具，那么你就不知道自己要解决什么问题。您不想被吸引去寻找现有的“最佳”工具或“理想”网格实现，因为这些都是兔子洞。你想清楚自己想要实现什么，这样你才能找到最适合你的工具。