标签：客户 Data 网格 订单 API Mesh 团队 数据
从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并不重要。
标签：客户,Data,网格,订单,API,Mesh,团队,数据 来源： https://blog.csdn.net/woliuqiangdong/article/details/122619453
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。