逐步从单一数据湖转移到分散的 21 世纪数据网格。
（另请查看后续文章：三种数据网格）
Left: data lakes with central access, on the right: user accessing data from teams domain teams providing a great data product. (all images by the author)
21 世纪的数据格局如何？ThoughtWorks 的 Zhamak Deghani 给出了一个漂亮的、对我来说令人惊讶的答案：它是去中心化的，与我们目前在几乎所有公司中看到的都非常不同。答案被称为“数据网格”。
如果您像我一样感受到公司当前数据架构的痛苦，那么您想迁移到数据网格。但是怎么做？这就是我在本文中探索的内容。
但首先，简要回顾一下数据网格
Twitter 数据网格总结
现代软件开发需要一种分散的数据方法。数据必须被其生成团队视为产品；他们需要为它服务；分析团队和软件团队需要改变！
更长的总结
DDD、微服务和 DevOps 在过去十年改变了我们开发软件的方式。然而，分析部门的数据并没有赶上这一点。为了在采用现代开发方法的公司中加快基于数据的决策，分析和软件团队需要改变。
- (1) 软件团队必须将数据视为他们服务于其他所有人（包括分析团队）的产品
- (2) 分析团队必须以此为基础，停止囤积数据，而是按需提取数据
- (3) 分析团队必须开始将他们的数据湖/数据仓库也视为数据产品。
如果简短的摘要对您有吸引力，让我带您了解如何从您当前的起点实际进入数据网格。我们将通过一个示例，在途中经过遗留的单体、数据湖和数据仓库。我们一步一步地从我们的“旧”系统转移到这个新系统。
旁注：将数据湖称为“旧”对您来说可能看起来很奇怪，对我来说也是如此。时任 Pentaho 的首席技术官/创始人的 James Dixon 仅在 10 年前就设想了数据湖的概念。然而，围绕数据湖的核心转变，即软件、DevOps、DDD、微服务也是在过去十年才出现的。因此，我们确实需要迎头赶上，因为在这些趋势完全改变我们开发软件的方式之前，中央全能数据湖是一个老问题的答案。此外，一个全能的数据湖并不是 Dixon 最初想象的那样。
我们从一个典型的电子商务业务微服务架构示例开始。
- 我们展示了这个示例在数据湖/数据仓库架构中的样子（A 点），
- 然后与数据网格架构进行比较（C 点）
- 然后举这个例子，但是添加一个“数据湖作为数据节点”（B），因为这实际上是我们从 A 到 C 的方式。
- 我们考虑应该启动我们从 A 到 C 的转变的痛点。
- 我们从 A -> B -> C 一步一步来。
- 我们会考虑首先移动哪些部件的细节。
- 我们考虑可能的问题以及如何处理它们。
- 我们考虑另一种解决问题的方法。
具有数据网格架构的电子商务微服务架构
E-commerce business modeled with three operational microservices.
这是一个基本的微服务体系结构，有两个域，一个“客户域”和一个客户API，一个CRM系统，“订单域”和一个订单API。这些服务是运营服务，它们运营着电子商务网站。这些API允许您在order API中创建订单，在CRM系统中的customer API中创建客户，检查信用额度等等。它们可能是REST API，再加上一些事件流、一些发布子系统，具体的实现并不重要。
旁注：对我们来说，订单和客户是不同的领域。这意味着这些领域的语言可能会有所不同。从团队2，即订单团队中看到的“客户”只有一个意思，即通过客户id识别的人，他们刚刚在网站上买了东西。在团队1中，含义可能有所不同。他们可能会考虑客户从CRM系统中的实体，它可以将状态从仅仅“领先”改变为“购买”客户，只有第二个在团队2方知道。
团队1拥有客户域。他们对这个领域了如指掌。他们知道什么是潜在客户，从潜在客户到实际客户的过渡状态如何等等。另一方面，团队2知道关于订单域的一切。他们知道被取消的订单是否可以恢复，网站上的订单漏斗是什么样子，等等。团队可能对另一个领域略知一二，但不是所有的细节。它们不是自己的。
这两个域都会生成大量数据作为副产品。组织中的很多人都需要这些数据。让我们看看其中的一些：
- 数据工程师：需要订单和客户数据进行转换，以生成OLAP多维数据集基础数据、模块化数据；在开始进行转换之前，他还需要数据来测试和理解它。
- 营销人员：需要按商品类别对订单进行概述，以便每天动态地扩展他们的活动。
- 数据科学家：正在构建推荐系统，因此需要所有订单数据始终保持最新，以训练他的系统。
- 管理层：希望对整体增长进行总体概述。
针对这些需求的数据湖/数据仓库解决方案将以类似的形式出现。
一个由数据工程师组成的中央团队很可能会通过 ETL 工具或流解决方案提供所有数据。他们将拥有一个中央数据湖或数据仓库，以及一个用于营销和管理的 BI 前端。
数据科学家可能会直接从数据湖中获取数据，这可能是他们访问数据的最简单方式。
我们看到这种架构有哪些可能的问题？
- 这种架构在数据工程团队中造成了中心瓶颈
- 它可能会导致领域知识在通过其中心枢纽的途中丢失，
- 并对所有这些不同的、异构的需求进行优先排序。
到目前为止这么好。那么数据网格方法呢？
这是具有数据网格架构的同一个电子商务网站。
Green: new data-APIs. Bottom: Mgmt with straight BI tool access, marketing with data form data-API, left: data scientist with data from data-API
发生了什么变化？首先，数据科学家和营销人员可以访问源域中的数据！但还有更多。
旁注：数据网格架构的关键是获取数据 DATSIS。可发现的、可寻址的、可信赖的、自描述的、可互操作的和安全的。
我会提到以下几点。
让我们逐步了解要点
- 客户域：客户域有两个新的只读“数据 API”。对于示例而言，可能只有一个或两个 API 并不重要。在这两种情况下，客户域都将确保将 CRM 系统和客户 API 中的“客户”概念联系起来。
- 订单域：订单域获得了一个新的数据API，即订单数据API。
- 客户数据 API 数据示例：客户数据 API 可能有多个端点：
allCustomers/：每行为一个“客户”提供数据。
stats/ ：使用诸如“Num customers: 1,000, Num Lead: 4,000;客户电话：1,500，中小企业客户联系：500，中小企业客户：600”
更多端点。
- order-data-API 数据示例：order-data-API 可能有多个端点：
allOrderItems/：每行提供一个订单行项目。
allBuckets/：每行提供一个存储桶，它是订单项的集合。
stats/：提供数据，如“订单：1,000,000，2019 年订单：600,000 平均桶容量：30 美元”；stats 端点可能采用日期范围、年份等参数。
- 数据 API 是只读的。其他人不是。* Data API 将 DATA 作为他们的产品，非常完美。您可以将 SLA 固定到它们，检查它们的使用情况。API 被建模为它们自己的 API，我们不会滥用 Order API 作为数据 API。因此，我们可以分别关注不同的用户。
- *-data-APIs 可以以任何合理的形式实现，例如：
- 作为位于 AWS S3 存储桶中的 CSV/parquet 文件（端点由子文件夹分隔，API 由顶级文件夹分隔）（可寻址）
- 作为通过 JSON/JSON 行的 REST API
- 通过中央数据库和模式。（是的，我知道“中央”不是“去中心化”）
- Schemata 位于数据旁边。（自我描述）。
- CRM 系统可以同时被视为操作 API 和数据 API，但您确实希望将其包装为符合您设置的标准。否则，您将失去数据网格架构的任何好处。
- 所有数据 API 应具有相同的格式。这让消费变得非常容易！（可互操作且安全）
- 数据 API 可以通过 Confluence 页面或任何更高级的表单或数据目录发现，我们知道哪个团队拥有该数据并可以在下游使用它。（可发现）
- 有一个新域。数据工程师刚刚获得了自己的商业智能建模数据域。他知道他正在为一个利益相关者服务。该域被包装为服务，仅服务于一个利益相关者。通过这种方式，数据工程师可以将管理需求集中在建模数据上并适当地确定其优先级。
- 营销团队可以直接从源头访问他们的“按类别订购数据”，因为它是特定领域的。
- BI 系统来自数据库，我们将其包装为数据服务。为什么？因为我们只为管理提供服务，他们只想要我们无法从 API 获得的建模和连接数据，这很好。整体增长听起来像是一个与某个领域无关但跨领域的实体。
让我们来看看数据用户的需求以及发生了什么变化
- 数据工程师：数据工程师已经从数据 API 接收到大部分建模数据。这意味着，不会丢失任何领域知识。他有 SLA 可以查看并确切知道他得到了什么。他可以轻松地使用用于两种 data-* API 的一种标准 API 以任何方式组合数据并将其放入他自己的数据服务中。他确切地知道向谁索取特定数据，并且所有数据都记录在同一个地方。
- 营销人员：可以直接从订单源中提取他们需要的数据，即使数据工程师数据服务（还没有？）提供该信息。因此，如果他们想要更改该数据，他们可以直接去找具有领域知识的人。如果他们想合并“漏斗数据”，他们可以询问真正知道那是什么的团队！
- 数据科学家：可以直接使用经过测试并具有 SLA 的 order-data-API，以应对他将一直进行的大量阅读。数据在一秒钟内就在那里，不需要破解数据库，这是我见过的不止一次。它已经投入生产，可以立即纳入推荐系统。数据科学家很容易实现他们的 CD4ML 版本。
- 管理层：仍然通过他们的商业智能系统获得他们的总体观点。但是，根据领域的不同，可能的更改可以在三个地方实现，而不仅仅是一个。中央数据团队不再是瓶颈。
数据团队仍然在那里，但可能的负载被适当地分配给分散的参与者，无论如何这些参与者更适合这项工作。但是，数据团队也有自己的服务。怎么可能看起来完全一样？让我们看看数据湖如何仍然适合数据网格以及可能的痛点。如果你从一个开始，就会有一个重要的过渡状态。
我们的数据湖，只是另一个节点
在三种情况下，现在不一定是中央数据湖或仓库仍然有意义：
如果我们想结合两个数据域来建模中间的东西，这不能发生在一个域中，而应该发生在一个新的域中。
如果我们想整合市场数据等外部数据。外部数据通常不符合我们的标准，因此我们需要以某种方式包装它们。
如果我们从 A -> C 点过渡，我们不仅会丢弃我们的数据湖，还会降低它的复杂性。
