从Mono数据湖逐步转移到分散的21世纪数据网格。

　　

　　> Left: data lakes with central access, on the right: user accessing data from teams domain teams pr

　　21世纪的数据格局如何？ ThoughtWorks的Zhamak Deghani给了我一个美丽而令人惊讶的答案：它是去中心化的，与我们目前几乎所有公司所看到的完全不同。 答案被称为"数据网格"。

　　如果您像我一样感到公司当前数据架构的痛苦，那么您想迁移到数据网格。 但是如何？ 这就是我在本文中探讨的内容。

　　但首先，简要回顾一下数据网格。

　　Twitter数据网格摘要

　　现代软件开发需要分散的数据处理方法。 数据必须由其生成团队视为产品； 他们需要为之服务； 分析团队和软件团队需要改变！

　　较长的摘要

　　DDD，微服务和DevOps改变了我们在过去十年中开发软件的方式。 然而，分析部门的数据未能赶上这一步。 为了采用现代开发方法加速基于公司数据的决策，分析和软件团队需要进行更改。

　　（1）软件团队必须将数据视为他们为其他人服务的产品，包括分析团队

　　（2）分析团队必须在此基础上，停止data积数据，而是按需提取数据

　　（3）分析团队必须开始将其数据湖/数据仓库也视为数据产品。

　　如果简短的摘要对您有吸引力，那么让我逐步指导您如何从当前起点实际进入数据网格。 我们将通过一个示例，沿途经过遗留的独石，数据湖和数据仓库。 我们逐步从"旧"系统过渡到新系统。

　　旁白：称数据湖为"旧"对您来说似乎很奇怪，对我来说也是如此。 当时的PTO的CTO /创始人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使您可以在订单API上创建订单，在CRM系统中使用客户API线索创建客户，检查信用额度等。 它们可能是REST API，并且与某些事件流，某些Pub-Sub系统结合使用，具体的实现并不重要。

　　旁白：对我们来说，订单和客户是不同的领域。 这意味着这些域中的语言可能会有所不同。 从团队2（订单团队）看到的"客户"的含义恰恰是一个由customer_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

　　发生了什么变化？ 首先，数据科学家和营销人员可以从源域访问数据！ 但是还有更多。

　　旁白：数据网格体系结构的关键是获取数据DATSIS。 可发现，可寻址，可信赖，自我描述，可互操作且安全。

　　我将在下面提到几点。

　　让我们逐步讲解要点

　　· 客户域：客户域获得了两个新的只读"数据API"。 对于该示例而言，可能只有一个或两个API并不重要。