谈谈三种类型数据网格的特点

数据网格是数据领域的热门话题。大多数担忧和困惑似乎都有一个共同点，是否只有一种数据网格形式。实际上有不同的数据网格，它们具有不同的优势，不同的技术架构，适用于不同的最终用户，团队参与的规模也大不相同。但最重要的是，它们的区别在于它们能做什么以及它们应该用来做什么。那么让我们来看看三种重要的架构类型。

三种数据网格

以下是对集中式、分散式以及“标准”数据网格架构的介绍。

1.标准数据网格

想象一下由集中的数据平台团队创建的大量数据桶。一个桶存储来自团队 A 的数据，另一个桶存储来自团队 B 的数据，依此类推。另外想象一下查看这些桶的方法。最后，想象一下所有数据的目录，以及一种由团队维护的很酷的搜索方式。

因此，A和B直接连接到他们数据的最终用户。这使两个团队都获得了真正的“所有权”或他们的数据，因为他们现在有了新客户，即数据客户。机器学习工程师、数据分析师或数据工程师等数据客户有特殊要求，团队现在可以像处理产品要求一样处理和实施这些要求。这就是称之为“标准数据网格”的形式。

2.集中式数据网格

事实证明，数据网格的核心原则并不真正依赖于技术实现。我想强调一个非常核心的实现。

想象一个大桶，以一种平滑的方式查看该桶；此外想象一下 10 个小管道让 A、B 等团队将数据倒入我们的大桶中。

还想象一下，团队将大致相同格式的数据倒入那个桶中。

现在突然间，我们的最终用户以极其快速和流畅的方式访问他们的数据；数据是标准化的，因此他们可能会获得很多标准视图，并且可以快速高效地从不同来源提取信息。数据平台团队可以快速启动这个东西，因为不需要连接很多不同的数据。而且，数据仍然可以归团队所有。他们仍然可以负责为他们的数据客户提供服务、转换数据等。这里的所有权、转换和服务实际上与技术无关，而更多地与团队是否具有这种“数据产品思维”有关。

3.分散式数据网格

想象一下十个异构的数据桶，而不仅仅是标准大小。

想象十个管道，它们现在将数据虹吸到我们的大桶中。

再次想象一些流畅的数据访问机制。然而，这一次，团队 A、B 还为他们的数据池构建了自定义访问点，以使他们更特殊的客户能够访问他们的特定数据。

听起来中央数据团队的工作量很大，但对于数据客户来说却具有很大的灵活性！

数据网格的定义

在我看来，这三种架构听起来都像是数据网格，其核心是实现数据去中心化，将所有权推向团队，将数据产品思维推向团队。因此，让我们尝试找到一个定义。

定义

数据网格的定义：

数据网格是一种去中心化技术，数据网格是“数据的所有权、转换和服务”的去中心化。

按照这个定义，数据网格就像微服务或微前端一样是一种去中心化技术。

数据网格的不同模式

从技术上讲，上面的“集中式”数据网格听起来好像数据不是由团队拥有或提供的。其实不然。即使有 10 个团队将数据推送到 Google Analytics，数据是由 Google Analytics 拥有和提供吗？当然不是。尽管它由各个团队（通过第三方工具）提供服务，并且由各个团队拥有。

从技术上讲，所选择的解决方案落在一起。即使这个完全集中的选项仍然具有数据网格的关键概念；只要各个团队对他们的数据负责，它仍然会为数据产品思维提供动力。只要团队可以自由地（在给定范围内）以自己的方式处理数据，它就具有分布式域架构；它以基础设施为平台，例如以平台方式提供常见的交互工具，如谷歌标签管理器或谷歌数据工作室。

无论我们作为一家公司选择哪种数据架构（独立于数据网格），我们最终都需要某种“胶水”，某种将分散部分粘合在一起的方法。

正是这种胶水，我将其视为数据网格连续光谱的不同程度。一方面是“真正强力的胶水”，几乎没有变化，另一方面是“非常轻的胶水”，允许零件来回移动。

详细的示例性架构

让我们看一下三个主要讨论的数据网格的一些可能的架构实现。我选择 AWS 作为我的基础设施参考点，因为我在那里感觉最自在。但您始终可以将 AWS S3 换成 GCS，将 AWS Lambdas 换成 GCF，等等。

让我们举一个简单的例子：一家电子商务公司，有一个网站，提供各种各样的文章。他们有几个团队：

“订单团队”：拥有从“添加到购物篮”到“提交订单”（以及之后发生的一切）的完整订单结构
“详细信息团队”：拥有文章详细信息页面。
“首页团队”：拥有首页，包括搜索引擎和搜索引擎结果页面。
“帐户团队：拥有注册流程。
“X 团队”：构建数据网格的数据平台团队。

我们还有一些数据最终用户：

“推荐团队”：推荐引擎团队，主要与团队 B 合作（通过一个做得很好的微前端，所以大部分是解耦的。）
营销团队：与团队 B 一起处理文章详细信息文本，并与团队 C 一起处理首页内容。
管理团队：与所有团队合作，尤其对关键指标和推动公司和产品发展的方法感兴趣。

好吧，让我们开始吧！

1.集中式数据网格

一个只关注少数关键业务数据概念的组织单位可能会选择实施由团队提供服务的中央跟踪 API，包括建立在其之上的标准报告和分析功能。

首先，让我们看看X 团队为我们打造了什么：

中央数据跟踪 API。您唯一可以用它做的事情：可以向它发送数据。
一个标准化的JSON 模式，具有强制字段，如“data_owner”和“timestamp”以及“acting_customer”、“action”和“action_category”。可选字段是“order_value”和“value”。
一个供具有技术技能的人使用的中央访问点，一个称为Presto的分布式 SQL 接口和查询引擎。
报告和仪表板的一个中央访问点称为redash。
在 redash 内部，团队建立了一堆标准报告，例如“热门事件”、“最活跃的客户”。它们允许按日期、event_category、value 和 order_value 进行排序和聚合。对于具有“order_value”的所有内容，团队构建了一个特殊的“订单”部分，其中包含针对该数据过滤的大量额外报告。
中央跟踪数据检索 API，允许用于机器学习团队或数据工程工作流的批量和流式传输。

用流经引擎的单个数据来理解它：让我们拿一个单独的数据，即“已下订单”数据。

新客户点击“完成注册”。
帐户团队：决定共享注册数据。
X 团队：中央 API 收到标准化数据块{data_owner: “team E”; 时间戳：“”…key_data：{acting_customer：123，action：“registers”，value：“100”order_value：“0”}}
客户点击网站上的“提交订单”按钮，后台发出一个订单事件。
订单团队：某些服务获取订单事件、处理订单并将数据点发送到中央 API。
X 团队: 中央 API 接收标准化数据块{data_owner:”team A”;时间戳：“”……event_uuid：……”，additional_meta：“”……key_data：{acting_customer：123；动作：“买东西”，order_value：“103,4”}}
X 团队：中央报告解决方案生成包含订单金额、最活跃客户、操作等的报告，标准化数据集提供的所有内容。

推荐引擎团队享受标准化数据；无需破解数据库或要求中央 API。如果推荐引擎团队想要扩展到第二个产品，他们已经以标准格式获得了所需的所有数据。数据被很好地记录下来，因为它被每个人使用，并且被很好地编目。

营销团队享有良好的数据覆盖率，并且他们有大量报告可以立即查看数据。无需烦扰分析部门来生成大量不同的报告。管理层得到了他们需要的一切，因为一切都围绕着他们在公司中使用的几个关键业务概念。如果他们需要一些特定的报告，他们可以使用数据的自定义 CSV 导出并在其上运行一些 Excel。

数据平台团队很高兴，因为他们以极快的速度从最初的原型到对公司的决策能力产生持久影响的项目。

2.“标准”数据网格

两家德国巨头，在线服装零售商 Zalando 和 BMW 集团最近分享了他们为构建数据网格的东西所做的努力的一些见解。Zalando 的数据网格和BMW Group 的架构都具“标准”选项桶中的架构，尽管 Zalando 在去中心化方面比 BMW 稍微多一点。

让我们看看 X 团队如何为我们构建一个简化版本：

中央元数据 REST API，允许为给定数据集设置新元数据、更新、删除和检索元数据。这是必要的，因为我们这里没有标准化的模式。
中央数据目录，源自元数据存储。在这种情况下，团队决定使用Linkedin 的数据中心来获取 API 和具有UI 的数据目录。
一组AWS S3 存储桶，每个存储桶由一个团队拥有。团队必须遵守遵循“{团队标识符}/{数据标识符}/…”的命名约定，以便将他们的数据推送到这些存储桶中。
再次为具有技术技能的人提供一个中央访问点，一个名为Presto的分布式 SQL 接口和查询引擎，也来自元数据 API。
团队可以使用AWS Lambda 函数将数据从 AWS S3 存储到中央AWS Redshift 数据库中。
同样是 AWS Redshift 数据库之上的工具Redash 。这次团队 X 不能创建任何报告，相反，他们允许团队在需要时这样做。分析工程团队可以通过这种方式轻松地将一些数据汇入 AWS Redshift 数据库，从而为管理团队创建仪表板。营销团队从与营销团队一起进行实验的 B 和 C 团队获得大部分报告。

数据流：让我们获取一个单独的数据，即“已下订单”数据。

新客户查看首页，开始注册，然后单击“完成注册”。
帐户团队：决定共享此数据。因此，他们将元数据发送到中央元数据 API：{“name”：“客户选择的用户名”，“timestamp”：“注册时间”，“source”：“我们从与此注册相关的 Google Analytics 中提取的来源”}
账户团队：他们将实际数据发送到中央数据团队为所有团队设置的更大的桶湖中自己的 AWS S3 桶。
客户单击网站上的“提交订单”按钮。
订单团队：在后端的某个地方，来自团队 A 的服务获取该事件，处理订单。此外，团队 A 决定共享此数据，因此他们将元数据发送到中央元数据 API：{“customer_id”：“我们从团队 E 获得的客户 ID”，“timestamp”：“订购时间”，“items”：……“总价”，……}
订单团队：他们将实际数据发送到中央数据团队为所有团队设置的更大桶中自己的 AWS S3 桶。
X 团队: 元数据 API 得到了新的元数据，所以它被放入“数据目录”中，供所有人访问。
X 团队：在这个元数据之上，我们无法生成标准报告。然而，我们可以创建一个新的访问点，然后可以通过公司中任何人都可以使用的通用标准界面来使用它。
机器学习团队：也通过订单团队 AWS S3 桶“/team-d/recommendation-interface/”内的他们自己的小“子桶”接收新数据，但他们得到的是包含订单的批量数据包的更新整个月。
首页团队：将作为 A/B 实验一部分的首页视图中的数据推送到 API，并在其之上以 redash 形式为团队营销创建一个新报告。

推荐团队喜欢这种方法，因为他们可以要求订单团队以他们需要的速度提供他们需要的数据。有了这个，他们能够生成接近实时的建议。营销团队享有生成报告的自由，这可以通过通用界面轻松完成。他们可以为他们采用的每项新活动即时生成新报告。管理层很高兴，因为他们不必挖掘大量样板文件，而是通过专门为他们创建的仪表板获取数字。

3. 去中心化的数据网格

让我们在去中心化的方向上更进一步。我们的小电子商务公司很久以前就已经意识到，“有边界”的自治是一种很好的工作方式。因此，他们开始为一系列存储技术（如 Postgres、AWS S3 和Greg Young 事件存储）维护基础架构即服务框架。因此，所有团队都使用其中一种存储形式。该公司还拥有存储 resp 的最佳实践。每个技术选择中的元数据。

让我们利用它！X 团队建立：

一个REST API，团队可以在其中注册他们的数据源。一个团队可以注册一个“Postgres”数据集，并提供一些额外的公司特定信息。
一种拉取元数据的元数据服务，因此 Postgres + Postgres 列和表注释以及EventStore 元数据流再次运行在数据中心上的中央数据目录中。
自定义图形界面，通过将 SQL 请求映射到所有三种技术，允许对所有这些来源进行跨源查询。

数据流：让我们获取一个单独的数据，即“已下订单”数据。

新客户点击“完成注册”。
帐户团队：决定共享此数据。他们将 AWS RDS 实例用于共享数据，这只是一个托管的 Postgres 实例。所以他们使用标准的列和表注释来存储这个新数据块的元数据。并将数据存储在一个名为“registration_events”的表中
客户在查看新版本的“文章详细信息”页面后点击网站上的“提交订单”按钮。
订单团队：决定共享此数据。他们使用 Greg Young Event Store。因此，他们将元数据存储在公司为这些商店构建的自定义轻量级元数据 API 上。并将实际事件存储在它们的“orderDataStream”中。
X 团队：中央数据平台团队为所有三种标准技术构建了连接器。一旦新的元数据进来，两个连接器就会获取它们并再次将它们存储在“数据目录”中。
X 团队：还为数据构建了连接器，将其提取并虹吸到 AWS S3 存储桶中，就像第一种情况一样。
X 团队：在这个 AWS S3 存储桶之上，该团队主要构建了“标准选项”中提到的访问技术，例如使用 Apache Superset 和 Presto 的通用查询和仪表板界面。
细节团队：这次细节团队与营销团队一起进行了一项实验。为了共享数据，他们使用 Google Analytics 的“实验”功能，将数据推送到 Google Analytics，并与营销团队共享。

各个技术团队对这个选项非常满意，因为他们共享新数据的速度非常快。他们使用他们已经知道的技术堆栈，并且可以以他们想要的任何方式指定数据。推荐团队可以再次为他们提供一个单独的数据集，以各自的技术提供。为了构建他们的第一个原型，他们使用更大的标准工具来获得初始数据草稿，因此当他们开始与团队 A 讨论定制化的数据集时，他们已经有了可以展示的东西。营销部门刚刚推出了一个新的营销自动化工具，并且很高兴能够在团队同意快速提供他们需要的数据后，将来自团队 E 的一些注册数据直接导入该工具。

三个同样强大的解决方案

看起来这三个选项都有很多优点！但我喜欢将优势简单地视为伴随劣势的镜像。因此，上面显示的每一个优势也都有一个镜像弱点，这使得系统在其他情况或要求下真的很难。

最分散的数据网格对于各个团队以及定制来说速度都非常快。然而，在只有几个关键业务概念的数据环境中，这将证明在提高公司决策能力方面极其缓慢。此外，如果推荐团队选择处理对数据接口有不同要求的多个项目，那么推荐团队的速度可能会变慢。

一旦需要定制，集中式数据网格会给最终用户带来问题。例如，如果推荐引擎团队需要获取实时数据，标准接口可能就不再适用了。管理层和营销团队的深入报告和分析也是如此。

介于两者之间的选择可能看起来是一个很好的折衷方案，但实际上，它将两个弱点结合在一起。

数据网格是工具

我确实相信，高度去中心化是大多数技术领域的未来。但如果你没有去中心化解决的问题，那么你不应该尝试使用数据网格。为工作选择合适的工具是一项艰难而关键的决定，但在数据呈指数级增长的世界中，您将必须学会如何去做。

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。