读懂数据网格原理与逻辑架构.docx

《读懂数据网格原理与逻辑架构.docx》由会员分享，可在线阅读，更多相关《读懂数据网格原理与逻辑架构.docx（16页珍藏版）》请在第一文库网上搜索。

1、谈谈如何跨越数据架构的漩涡目录1.编者按12 .前言13 .数据的巨大鸿沟21. 1.数据网格的核心原则和逻辑架构43. 2.原则一：领域所有权54 .逻辑架构：面向领域的数据和计算54.1. 原则二：数据即产品75 .逻辑架构：数据产品作为架构量子75. 1.代码86. 2.数据与元数据87. 3.基础设施88. 4.原则三：自服务数据平台106 .逻辑架构：一个多平面的数据平台107 .自服务平台127 .1.原则四：联合计算治理128 .逻辑架构：嵌入在网格中的计算策略139 .原则总结和高阶逻辑体系结构15关键词：数据分析；数据；大数据1 .编者按我们渴望用数据来增强和改善商业和生活的

2、方方面面，这要求我们在大规模管理数据方面进行范式转变。过去10年的技术进步已经解决了数据量和数据处理计算的规模问题，但它们未能解决其他方面的规模问题：数据格局的变化、数据来源的增加、数据用例和用户的多样性，以及对变化的响应速度。数据网格基于以下四个原则解决这些维度：面向领域的分散数据所有权和架构、数据即产品、自服务的数据基础平台和联合计算治理。每个原则都驱动着技术架构和组织结构的新逻辑视角。2 .前言为了实现数据驱动、能使用数据进行竞争、或者使用数据在规模上驱动价值，今天的架构和组织都面临挑战，之前的文章如何从单一数据湖移动到分布式数据网格对此中痛点深表同感（阅读下文前，鼓励你先读这篇文章）。

3、它提供了另一种视角，这一视角已经引起了许多组织的注意，并为不同的未来带来了希望。虽然最初的文章描述了这个方法，但它也留下了很多设计和实现的细节，让人去想象。我无意在本文中作明确的界定，从而扼杀了围绕数据网格实现的想象力和创造力。这里，将阐明数据网格的架构方面，作为推动范式向前发展的垫脚石。写这篇文章更多是作为一个续集。它总结了数据网格方法，列举了它的基础原则，以及这些原则所驱动的高级逻辑架构。在以后的文章中深入研究数据网格核心组件的详细架构之前，高级逻辑模型是必要的基础。因此，如果您正在寻找数据网格的具体工具和方法，这篇文章可能会让您失望。如果您正在寻找一种简单的、与技术无关的模型来建立一种通

4、用语言，那就来吧。3 .数据的巨大鸿沟我们所说的数据到底是什么?答案取决于你问的是谁。今天提到的数据，可以分为运营数据和分析数据。运营数据位于由微服务提供的业务功能背后的数据库中，具有事务性，保持当前状态并满足运行业务的应用程序的需求。分析数据是对业务事实随时间推移产生的临时和聚合视图，通常用于建模以提供回顾或未来视角的洞见;它也用于训练M1模型或提供分析报告。Ana1ytica1DataP1ane技术、架构和组织设计的当前状态反映了这两个数据平面的分歧一一两个层次，既集成而又分离。这种分歧导致了一个脆弱的架构。许多人试图连接这两个数据平面，将数据从运营平面流动到分析平面，然后再返回到运营平面

5、。然而不断失败的ET1（提取、转换、加载）作业和不断增长的迷宫般的数据管道的复杂性变得越发常见。Operationa1DataP1aneRunningthebusinessServingtheusersOptimizingthebusinessAugmentingtheuserexperiencewithinte11igence图1数据的巨大鸿沟分析数据平面本身分为两大主要架构和技术栈：数据湖（b1iki:Data1ake）和数据仓库;数据湖支持数据科学访问模式，数据仓库支持分析和商业智能报告访问模式。而同时，数据仓库正试图支持数据科学工作流程，数据湖也试图为数据分析和商业智能服务。本文将先把

6、这两个技术栈之间的交错放在一边，数据网格最初的文章探讨了现有分析数据平面架构所面临的挑战。DataAna1ysts图2数据仓库DatascientistsM1trainingOperationa1DataP1aneDataPipe1ines!Main1yExtract-1oadAna1ytica1DataP1aneData1akeMorepipe1ines!Main1ytransform图3数据湖数据网格认可并尊重这两个层面之间的差异：数据的性质和拓扑、不同的用例、数据消费者的角色，以及最终它们的不同访问模式。然而，它试图在不同的结构（基于领域的倒置模型和拓扑，而不是基于技术栈）下连接这两个平

7、面，并将重点放在分析数据平面上。当今管理两种数据原型的可用技术中，都不应该导致组织、团队和工作人员的分离。在我看来，运营性和事务性数据的技术和拓扑是相对成熟的，并且主要由微服务架构驱动;数据隐藏在每个微服务内部，通过微服务的api控制和访问。当然，真正实现混合云本地操作数据库的这解决方案还有创新空间，但从架构的角度来看，它已经满足了业务的需求。然而，管理和获取分析数据仍存在大量的摩擦。这，就是数据网格的重点所在。我相信，在未来的某个时刻，我们的技术将会发展，使这两各数据层面能更加紧密地联系在一起，但现在，建议先把关注点分离。3.1.数据网格的核心原则和逻辑架构网格目标是为了构建一个基础底座，便

8、于从大规模分析数据获得价值，以及适应历史事物的不同维度变化，如数据环境的不断变化、数据源和消费者的扩散、用例所需的转换和处理的多样性、变化响应速度的改变。为了实现这一目标，我建议，任何数据网格实现都应遵循以下四个基本原则：1）面向领域的分析数据所有权和架构2）数据即产品3）自服务的数据基础平台4）联合计算治理这些原则的实践、技术和实现会随着时间的推移而变化和成熟，但这些原则不会改变。这四项原则合起来应该是必要和充分的;在解决不兼容数据竖井或运营成本增加的问题时，实现形式可弹性伸缩。下面，让我们深入研究每个原则，然后设计支持它的概念性架构。3.2.原则一：领域所有权数据网格的核心是将责任分散并分

9、配给最接近数据的人，以支持持续的变化和可伸缩性。问题是，我们如何分解和分散数据生态系统的组件及其所有权。这里的组件由分析数据、元数据和为其提供服务所需的计算组成。数据网格按组织单元的边界分解。而我们现在的组织单元是基于它们的业务领域划分的。这种划分的持续变化和演化（在大多数情况下）将影响到领域的的限界上下文。因此，使业务领域的限界上下文成为数据所有权分布的良好候选对象。在本文中，我将继续使用与最初写作相同的用例，“一家数字媒体公司”。可以想象，媒体公司会根据域划分其运营，并从而划分支持运营的系统和团队。如“播客”领域，会有相应的系统和团队管理播客发布及其主机；又比如“艺人”领域，也会有相应的系

10、统和团队负责上线及付款。数据网格认为分析数据的所有权和服务应该尊重这些领域。例如，管理“播客”领域的团队，在为播客发布提供AP1的同时，还应该负责提供“已发布的播客”的历史数据和其他相关指标，比如“听众人数”。要更深入地了解这一原则，请参见面向领域的数据分解和所有权KHowtoMoveBeyondaMono1ithicData1aketoaDistributedDataMesh）o4 .逻辑架构：面向领域的数据和计算为了促进这样的划分，我们需要对分析数据的按领域建模。在这个架构模型中，领域与组织其他部分的接口不仅包括运营能力，还包括对领域服务的分析数据的访问。例如，“播客”领域提供了运营AP1

11、来“创建一个新的播客集”，但也提供了一个分析数据接口来检索“过去n个月的所有播客集数据”。这意味着架构模型必须消除任何摩擦或耦合，以让领域能服务于它们的分析数据，并独立于其他领域发布计算数据的代码。为了规模化，架构必须支持领域团队在发布和部署其运营或分析数据系统方面的自主权。下面的示例演示了面向领域的数据所有权原则。这些图只是逻辑表示和示例性的。它们并非是完整的。每个领域可以发布一个或多个运营api,以及一个或多个分析数据接口providedandownedbythedomainAnana1ytica1dataprovidedandownedbythedomaian知乎SairaQiigrn当

12、然，每个领域都可以依赖于其他领域的运营和分析数据接口。在下面的例子中，“播客”领域作为消费者，从“用户”领域获取“用户更新”的分析数据，从而能通过“播客听众人数统计”数据集提供一个播客听众人数的视图。注意：在示例中，我使用了命令式语言（动宾）来访问运营数据或功能，如“支付艺人”。这只是为了强调访问运营数据和分析数据的意图之间的区别。我认识到，在实践中，运营性AP1是通过声明性更强的接口实现的，比如RESTfu1资源访问或GraphQ1查询。4.1. 原则二：数据即产品现有分析数据架构的挑战之一是对于发现、理解、信任和最终使用高质量数据的高摩擦和成本。如果不加以解决，随着提供数据领域的系统和团队

13、数量的增加，这个问题只会随着数据网格划分而加剧。这将是去中心化第一原则的结果。数据即产品原则旨在解决数据质量和古老的数据竖井问题;或如Gartner所称的“黑暗数据”问题一一“组织在常规业务活动中收集、处理和存储的信息资产，但通常不会用于其他目的”。领域提供的分析数据应该被视为产品，数据的消费者应该被视为客户一一需要被满足的客户。原文中列举了一系列能力，包括可发现性、安全性、可探索性、可理解性、可信赖性等，这是数据网格在支撑数据即产品时应该提供的能力。它还详细描述了角色，比如组织必须引入的领域数据PO,负责确保数据作为产品交付的客观度量。度量包括数据质量，减少数据消耗的前置时间，以及一般通过净

14、推广者评分获得的数据用户满意度。领域数据Po必须深入了解数据用户是谁，他们如何使用数据，以及他们习惯使用什么方式获取数据。这种对数据用户的深入了解能促使数据产品接口的设计满足用户需求。实际上，对于网格上的大多数数据产品，都有一些传统的用户画像，他们拥有独特的工具和期望，比如数据分析师和数据科学家。所有数据产品都可以通过开发标准化接口实现。数据用户与Po之间的对话是建立数据产品接口的必要环节。每个领域将包括数据产品开发者，她们负责构建、运维和提供领域的数据产品，数据产品开发者将与该领域的其他开发人员一起工作。每个领域团队可以提供一个或多个数据产品。也可以组建新的团队来提供那些不适合现有运营领域的

15、数据产品。注：与过去的模式相比，这是一种反向的责任模式。数据质量的责任向上游转移，尽可能接近数据的来源。5 .逻辑架构：数据产品作为架构量子在体系结构上，为了支持数据作为一种产品，领域可以自主地服务或消费，数据网格引入了数据产品的概念作为其架构量子。架构量子，在演进式架构中定义为最小的架构单元，它可以独立部署，具有高度的功能内聚性，并包含其功能所需的所有结构元素。数据产品是网格上的节点，它封装了其功能所需的三个结构组件，作为产品提供对领域分析数据的访问。5.1代码数据管道代码，以消费、转换和服务那些从领域的运营系统或上游数据产品接收的数据api代码，以提供对数据、语义和语法模式、可观察性指标和其他元数据的访问强制特征的代码，例如访问控制策略、合规性、来源等5.2.数据与元数据这就是这里的目的所在，以多种语言的形式来获取潜在的分析和历史数据。根据领域数据的性质及其消费模型，数据可以展现为事件、批处理文件、关系表、图形等多种形式，同时维护相同的语义。为了数据的可用性，需要一组相关的元数据，包括数据计算文档、语义和语法声明、质量指标等；数据固有的元数据，例如它的语义定义；以及传递计算治理用于实现预期行为特性（如访问控制策略）的元数据。5.3.基础设施基础架构组件支持构建、部署和运行数据产品的代码，以及存储和访问大数据和元数据。