将系统置于持续的约束下会导致脆弱性的演变。——C.S.Holling，生态学家成为数据驱动的组织是许多公司的战略目标之一，因为数据驱动的好处是显而易见的：提供基于数据和个性化的最佳客户体验；通过数据驱动的优化降低运营成本和时间；为员工提供趋势分析和商业智能。然而，尽管在建设数据平台方面的努力和投资不断增加，但结果仍然不尽如人意。当前的技术进步已经解决了数据处理计算的规模问题，但仍然存在未解决的问题：数据生成场景的变化、数据源的激增、数据用例和用户的多样性以及对变化的响应速度。DataMesh或许可以解决这些问题。1、什么是数据？数据到底是什么意思？另一个“每个人都有一个哈姆雷特”的问题。数据通常分为操作数据和分析数据。从数据库的角度，也就是我们常说的OLTP和OLAP。通常，运营数据驻留在为业务功能提供服务的数据库中，本质上是事务性的，维护当前状态并满足运行业务的应用程序的需求。分析数据是业务事实随时间变化的临时聚合视图，经过建模以提供回顾性或未来洞察力、训练机器学习模型或为分析报告提供信息。当前的技术、体系结构和组织状态导致这两个数据域之间存在差异，分为两个层，集成层和分离层。这种分歧通常会导致架构的脆弱性。它还导致ETL的复杂性和不断增长的迷宫式数据管道。对于许多试图弥合这两个世界的人来说，数据从运营数据世界流向分析数据世界，然后又流回运营数据世界。分析数据领域主要有两种架构和技术栈：数据湖和数据仓库，而数据湖支持数据科学接入方式，数据仓库支持分析和商业智能报表接入方式。在实践中，经常会出现数据仓库试图承载数据科学的工作流，而数据湖试图为数据分析师和商业智能服务的情况。2、数据领域的挑战首先，数据平台的发展经历了三个阶段：自有企业数据仓库和商业智能平台。这是一种昂贵的解决方案，会给公司留下大量的技术债务；数以千计无法维护的ETL、表格和报告中的技术债务，只有少数专业人员理解它，导致对业务的积极影响没有完全实现。以数据湖为灵丹妙药的大数据生态系统。复杂的大数据生态系统和由高度专业化的数据工程师组成的数据团队长期运行的批处理作业创造了数据湖怪物，充其量只能实现一小部分研发分析，承诺太多但交付不足。当前的数据平台与前两个阶段或多或少相似，但发生了现代转变：(a)使用Kappa等架构实现实时数据可用性的流式处理，(b)用于转换此类框架的数据的批处理和流式处理，以及(c)全面接受云存储、数据管道执行引擎和机器学习平台的托管服务。显然，第三代数据平台正在缩小前几代的一些差距，例如实时数据分析和降低管理大数据基础设施的成本，但是，许多挑战仍然存在。2.1集中式架构的挑战数据平台从企业的各个角落获取数据，包括运行业务的运营和交易系统，或者增加企业知识的外部数据提供者。例如在流媒体业务中，数据平台负责获取大量数据：“媒体播放器性能”、“用户与播放器的交互方式”、“播放过的歌曲”，以及播放器上的“标签”。业务、与艺术家的关系“交易”，以及外部市场研究数据，例如“人口统计”信息。清理、丰富源数据并将其转换为可信赖的数据，以满足不同消费者的需求。这将尝试将用户的操作流程和行为重构为聚合视图。数据平台为具有不同需求的各种消费者提供数据集。这包括从分析消费到数据探索的一切，从基于机器学习的决策制定到总结业务绩效的商业智能报告。单一数据平台托管和拥有逻辑上属于不同领域的数据，例如“播放事件”、“销售指标”、“艺术家”、“专辑”、“标签”、“音频”、“播客”、“音乐事件”等。来自大量不同领域的数据。尽管我们已经成功地将领域驱动设计和限界上下文应用于软件系统，但数据平台中的领域概念在很大程度上被忽略了，从面向领域转变为集中的领域不可知数据所有权。这种集中式架构可以适用于不同消费案例较少、领域较简单的组织，但对于领域丰富、来源众多、消费者群体不同的企业，难以满足需求，原因如下：无处不在的数据和数据激增：随着越来越多的数据变得无处不在，在一个平台的控制下消费所有数据并在一个地方协调的能力下降。组织创新和消费者增殖：组织对快速试验的需求引入了大量使用平台数据的用例。这意味着越来越多的数据聚合、预测和切片转换，以满足创新的测试和学习周期。满足用户需求的响应时间过长一直是组织摩擦的焦点，现在仍然如此。2.2管道耦合的挑战通常，数据平台会分解为数据处理阶段的管道。管道在高层次上实现数据处理技术的功能内聚，即摄取、准备、聚合、服务等。这种方法提供了一定程度的规模，但将团队分配到管道的不同阶段有一个减慢交付速度的固有限制。管道的各个阶段高度耦合以提供独立的功能。许多数据平台提供通用和基于配置的数据摄取服务，可以处理诸如轻松添加新数据源或修改现有数据源之类的事情，以最大限度地减少引入的扩展开销。但是，这并没有消除因消费者引入新数据集而导致的端到端依赖关系的管理。虽然从表面上看，管道架构看起来好像已经达到了架构规模的水平，但实际上，整个管道平台必须改变以迎合新功能的最小单元：解锁一个新的数据集并使其可用于新存在的或现有消费者。这限制了高速扩展到新消费者或新数据源的能力。2.3数据所有权的挑战数据所有权与构建和拥有数据平台的团队的组织方式有关。所谓数据团队，由专门的数据工程师和数据产品经理组成，通常是一个独立于业务组织的独立单位，虽然可能缺乏业务和领域知识，但在使用大数据工具方面具有技术专长。数据团队需要使用来自其他团队的数据，而这些团队可能没有动力提供有意义、真实和正确的数据。数据团队对数据源所在领域知识有限，可能缺乏专业领域知识，但需要为各种需求提供数据，无论是运营数据还是分析神经，没有清楚地了解数据的应用.数据平台团队位于中间，努力为所有来源和消费提供正确的数据。但实际上，资源的局限性和不平衡性往往导致研发团队和业务经理重新出发，进一步加剧了与数据团队的紧张关系。这样的组织结构缺乏可扩展性，并且无法提供创建数据驱动组织所承诺的价值。3面临挑战的数据平台鉴于此，数据平台范式转变势在必行。或许数据平台应该是分布式领域驱动架构、自助平台设计、产品思维和数据的融合。去中心化数据平台需要颠覆我们对数据的看法，即数据的位置和所有权。领域需要以易于使用的方式托管和提供其领域数据集，而不是将数据从各自的领域流式传输到集中式数据湖。3.1数据与领域驱动架构的融合领域驱动设计深刻影响了系统架构的思维方式，进而影响了组织建模。通过将系统分解为围绕业务领域的分布式服务，它是微服务架构的诱因之一。它从根本上改变了团队的形式，让团队独立拥有领域能力。奇怪的是，当谈到数据时，业务领域的概念被忽略了。DDD最接近数据平台的应用是让数据源处的系统发出其业务领域事件并让数据平台使用它们。但随后，域的概念和不同团队对域数据的所有权就丢失了。这需要我们将思维从传统的ETL和事件流转变为跨所有领域的推拉模型。在面向领域的数据平台中，一个领域而不是一个管道阶段。一些字段与数据源自然对齐。域的源数据集代表业务的事实和现实。业务事实最好以业务领域事件的形式表示，这些事件可以作为带时间戳的事件的分布式日志存储和服务，任何授权消费者都可以访问。域捕获的数据与数据的来源业务系统非常接近。域和数据源系统之间往往没有一对一的映射关系，往往有多个系统可以提供属于一个域的部分数据。因此，有许多数据源对齐的数据集最终需要聚合成一个内聚的域数据集。源域数据集是最基本的数据集，更改频率较低，因为业务事实不会经常更改。这些域数据集预计将被永久捕获并提供，以便随着组织发展其数据驱动和智能服务，他们始终可以回到业务事实并创建新的聚合或预测。一些领域与消费密切相关，消费者领域数据集可以满足一组密切相关的用例。虽然数据集所有权从集中式平台委托给各个领域，但数据仍然需要清理、准备、聚合和服务，就像管道的使用一样。3.2数据整合和产品思维随着数据所有权和管道被分配到业务领域，人们会更加关注分布式数据集的可访问性、可用性和协调性。这就是产品思维和学习方法派上用场的地方。将数据资产视为产品，将组织的其他数据科学家、机器学习和数据工程师视为客户。任何科技产品的一个重要品质就是取悦消费者，为消费者提供最好的用户体验。领域数据产品需要具备以下基本要素：可发现：一个常见的实现是拥有一个注册表，所有可用数据产品及其元数据的数据目录，例如它们的所有者、来源、沿袭、样本数据集等。可寻址：一旦一个数据产品被发现，它应该有一个唯一的地址来通过API访问它。根据底层存储和格式，不同的命名约定可能用于其数据。值得信赖：数据产品的所有者围绕数据的真实性提供可接受的SLA，以及它在多大程度上反映已发生事件的真实性，或由此产生的洞察力的高概率。提供数据来源和沿袭作为与每个数据产品关联的元数据，有助于消费者进一步相信数据产品及其对他们特定需求的适用性。自描述：优质产品可以被自主发现、理解和消费，数据模式是提供自助数据资产的起点。互操作性：跨域有效关联数据的关键是遵循特定标准和统一规则。这种标准化属于全球治理，以支持多域数据集之间的互操作性。这种标准化工作的常见问题是字段类型格式化、跨域识别多义词、数据集的寻址约定、通用元数据字段、事件格式等。安全性：访问控制以更精细的粒度应用于每个域中的数据产品。访问控制策略可以集中定义，但在访问每个单独的数据集产品时应用。SSO和RBAC是实现产品数据集访问控制的简单方法。3.3数据与自助服务的融合将与领域无关的基础设施功能收集并提取到数据基础设施平台中，解决了重复搭建数据管道引擎、存储和流式计算的需要。数据基础架构团队可以提供现场捕获、处理、存储和服务其数据产品所需的必要技术。将数据基础架构构建为平台的关键是：通过不包含任何特定于领域的概念或业务逻辑，使其与领域无关；确保平台隐藏所有潜在的复杂性并以自助服务方式提供数据基础设施组件。自助数据基础设施可以减少“创建新数据产品的准备时间”，例如，通过配置和脚本自动化完成数据摄取、数据产品创建脚本和生成框架、数据产品自动注册到目录等.云作为底层，可以减少提供对数据基础设施的按需访问的运营成本和工作量。这种新型数据平台被业界命名为“DataMesh”。DataMeshPlatform是一种分布式数据架构，可通过共享和协调的自助服务数据基础架构实现互操作性，从而实现集中治理和标准化。4.什么是数据网格？DataMesh是现代数据管理的一种战略方法，也是一种加强组织数字化转型的方式，专注于提供有价值和安全的数据产品。DataMesh是一种数据管理方法，它超越了利用数据仓库和数据湖，强调组织灵活性，通过授权数据生产者和数据消费者访问来管理数据，并将数据所有权分配给使用数据作为产品提供、所有权的特定领域团队和管理。4.1数据网格和数据湖数据湖是一种技术方法，其主要目标是充当单一存储，以最简单的方式将数据移动到中央团队负责管理的地方。虽然数据湖可以提供巨大的商业价值，但它们也存在许多问题。主要问题是一旦数据搬入湖中，就失去了上下文，比如可能有很多文件包含客户的定义，一个来自物流系统，一个来自支付，一个来自营销，哪个合适使用？另外，数据湖中的数据没有经过预处理，数据问题在所难免。然后，数据消费者通常必须与数据湖团队合作以了解和解决数据问题，这成为使用数据回答初始业务问题的瓶颈。相比之下，DataMesh不仅仅是技术，它结合了技术和组织，包括数据所有权、数据质量和数据自治。从而使数据消费者对数据质量和数据所有权有了清晰的认识，可以更有效地发现和解决数据问题，最终使数据得到使用和信任。数据湖不再是DataMesh的中心，而是将数据湖的一些原理应用到面向数据源的领域数据产品中。然而，人们继续使用数据湖工具，无论是用于数据产品的内部实施还是作为共享数据基础设施的一部分。DataMesh将领域数据产品作为第一类关注点，将数据湖工具和管道作为第二类关注点。同样的原则适用于用于业务报告和可视化的数据仓库。它只是数据网格上的一个节点，可能位于面向消费者的网络的边缘。也就是说，将大数据作为一个整体分解为一个协调、协同、分布式的数据网格生态系统。4.2DataMesh和DataFabricDataFabric专注于各种技术能力的集成，它们相互配合，为最终用户生成一个接口。DataFabric的许多支持者正在通过机器学习等技术使其自动化，使最终用户更容易访问数据。这对于简单的数据使用很有价值，但对于更复杂的情况，或者需要将业务知识集成到数据中的情况，DataFabric的局限性就变得很明显。可以说，DataFabric可以用作DataMesh自助服务平台的一部分，其中DataFabric将数据公开给可以将其业务知识嵌入到最终数据产品中的域。DataMesh的目标是创建一个从分析数据和历史事实中获取价值的基础，它可以扩展以适应数据场景的不断变化、数据源和消费者的扩展、用例多样性和需求所需的转换和处理。对变化的反应。5数据网格的四项核心原则数据网格的四项核心原则作为一个整体对于实现大规模弹性是必要且充分的，同时解决不兼容数据孤岛或运营成本增加的问题。5.1领域驱动数据所有权和数据架构要理解什么是领域驱动数据，就必须知道什么是领域。在数据网格中，域是负责数据管理和创建的相关数据和业务功能，负责聚合、转换数据并使数据可供最终用户使用。最终，该领域将其数据公开为数据产品，其整个生命周期由该领域本身拥有。也就是说，DataMesh的核心是建立去中心化并将责任分配给最接近数据的人，以支持持续变化和可扩展性。那么，您如何分解和分散数据生态系统的组件及其所有权呢？包括分析数据、元数据和为其提供服务所需的计算。为了促进这种分解，需要一个按域排列分析数据的模式。在此体系结构中，域与组织其余部分的接口不仅包括操作功能，还包括对域所服务的分析数据的访问。这意味着必须进行解耦，以便域为其分析数据提供服务，并且计算数据的代码独立于其他域。为了扩展，必须支持领域团队在发布和部署其操作或分析数据系统方面的自主权。当然，每个域都可以依赖于其他域的操作和分析数据端点。5.2数据即产品发现、理解、信任并最终使用高质量的数据是一个重要的问题。随着提供数据域的团队数量的增加，这个问题只会随着DataMesh而恶化，这是域自治的结果。数据即产品原则旨在解决数据质量和数据孤岛问题，例如Gartner所说的暗数据——组织在日常业务活动中收集、处理和存储的信息资产，但通常不能用于其他目的。域提供的分析数据必须被视为产品，数据的消费者应被视为客户。领域数据产品负责人必须深入了解数据用户是谁、他们如何使用数据以及他们喜欢使用什么方法。这种对数据用户的深刻理解导致设计出满足需求的数据产品接口，所有的数据产品都可以开发为支持标准化接口。数据用户和产品所有者之间的对话是建立数据产品接口的重要组成部分。每个域都将包括负责构建、维护和服务域数据产品的数据产品开发人员的角色，他们将与域中的其他开发人员一起工作。每个领域团队都可以提供一种或多种数据产品，也可以组建新的团队来服务那些天然不适合现有领域的数据产品。从本质上讲，数据质量的问责制向上游移动，尽可能靠近数据源。数据产品是网格上的一个节点，它封装了功能所需的三个结构组件，提供对领域分析数据作为产品的访问。代码：它包括（a）负责消费、转换和服务上游数据的数据管道的代码；(b)提供数据访问、语义和句法模式、可观察性指标和其他元数据的API代码；(c)实现功能特性代码，例如访问控制策略、合规性、出处等。数据和元数据：根据域数据的性质及其消费模型，数据可以用作事件、批处理文件、关系表、图形等，同时保持相同的语义。为了使数据可用，有一套相关的元数据，包括数据计算文档、语义和句法声明、质量指标等；数据固有的元数据，例如其语义定义，以及用于实现预期行为特征的元数据，例如访问控制策略。基础设施：基础设施组件支持构建、部署和运行数据产品的代码，以及存储和访问大数据和元数据。一般来说，数据产品是由领域生产的，由下游领域或用户消费，创造商业价值。数据产品与传统数据集市的不同之处在于，它们是独立的，并且自己负责与保持数据最新相关的安全性、来源和基础设施方面。数据产品支持清晰的所有权和问责制，可以被其他数据产品或最终消费者直接使用，以支持商业智能和机器学习活动。5.3自助数据平台领域团队领域团队自主拥有数据产品的唯一方法是访问基础架构的高级抽象，从而消除数据产品生命周期供应和管理的复杂性。这需要一个新的原则，自助数据基础架构作为支持域自治的平台。自助服务数据基础架构包含许多功能，域成员可以轻松使用这些功能来创建和管理他们的数据产品。自助服务平台功能通过模型??中的调用分为类别或平面，每个平面服务于不同的用户配置文件。平面类似于网络中的控制平面和数据平面。自助服务数据平台由基础设施工程组支持，其主要职责是管理和操作所使用的各种技术。这是一种关注点分离，领域团队专注于数据，而自助服务数据平台团队专注于技术。自助服务数据平台的衡量标准是域自治。也就是说，数据平台可以被认为是用于运行和监控服务的现有交付平台的扩展。但是，目前用于运营数据产品的底层技术栈与数据服务的交付平台有很大的不同，这也是大数据技术栈与业务系统平台的区别。例如，业务领域团队可能将服务部署为Docker容器和使用K8s的交付平台，但是，数据产品可能将其管道代码作为Hadoop集群上的作业运行。这是两套完全不同的基础设施，DataMesh需要这种级别的互操作性和互连性，在有意义的地方融合。5.4联邦系统的治理传统的数据治理通常被视为数据价值创造的障碍。DataMesh通过将治理关注点嵌入到域的工作流中来实现数据治理的许多方面，并且使用指标和报告必须是此定义的一部分。使用了多少数据以及如何使用数据是了解数据产品成功价值的关键。DataMesh的实现需要一个治理模型，包括域自治、标准化互操作、动态拓扑，最重要的是平台自动执行决策，可以称为联邦计算的治理。由领域数据产品所有者和数据平台产品所有者组成的联盟领导的决策模型，具有数据所有权和领域本地决策权，同时创建并遵守一组全局规则，即一组适用于所有的规则数据产品及其接口，以确保生态系统的健康和互操作性。这个团队有一项艰巨的任务：在集中化和本地治理之间保持平衡，哪些决策需要本地化到每个域，哪些决策需要全球化到所有域。最终，全球决策只有一个目的，即通过数据产品的发现和组合来创造互操作性和复合网络效应。数据仓库和数据湖的数据治理DataMesh的数据治理集中团队负责定义如何构建构成质量的模型负责数据安全负责定义数据安全的各个方面，例如平台内置和自动监控的数据敏感度级别负责合规性负责定义平台内置和自动监控的监管要求数据集中保管按域联合保管数据负责整体规范数据建模负责对跨多个域边界的数据元素建模团队独立于业务领域团队，由来自各个领域的代表组成良好的静态数据结构，用于有效的网格操作，包括变化和动态的网格拓扑单体湖/仓库的集中化技术每个领域使用的自助服务平台技术基于治理e数据（表格）按数量或数量衡量成功基于网络效应衡量成功（代表网格上用于数据消费的连接）人工干预的手动流程平台支持的自动化流程防止错误检测错误并通过自动化恢复支持性组织结构平台流程激励模型和结构对于联合治理模型的运作是必要的：达成全球互操作性的决策和标准，并在尊重本地域自治的同时有效地执行总体战略。在所有域及其数据产品的平台实施和强制执行的全球标准化内容与留给域决定的内容之间取得平衡可能是一门艺术。6.数据网格实施数据网格实施为希望在不确定的经济环境中茁壮成长的组织提供了灵活性，所有组织都需要能够以低成本、高回报的方式应对环境的变化。新数据源的引入、遵守不断变化的监管要求或满足新的分析要求的需要都是组织数据管理活动发生变化的驱动因素。当前的数据管理方法通常基于位于业务和分析系统之间的复杂、高度集成的ETL，并且需要努力及时更改以支持业务需求。DataMesh提供了一种更具弹性的数据管理方法，可以有效地应对这些变化。DataMesh是一种涉及人、流程和技术的社会技术方法，需要在人、流程和技术三个维度进行组织变革，可能将70%的精力花在人和流程上，30%的精力花在技术上。人们分散在集中数据团队的各个领域，现有的劳动力对于数据网格的成功采用至关重要，他们必须贡献知识和技能。因此，管理水平和奖励机制也发生了变化。为了促进可持续和敏捷的数据架构，组织内需要进行流程更改。考虑到数据治理，围绕数据策略的定义、实施和执行将需要新的流程，这将影响访问和管理数据的流程，以及将数据作为业务流程的一部分加以利用的流程。技术能力是实施和运行数据网格的关键，出于以下原因可能需要新技术：为了减少技术开发之间的摩擦，这些新技术的互操作性可能至关重要。让领域自给自足，专注于第一种关注点，即数据而不是技术。允许在线购买新的数据平台，这些平台暴露的数据可以无缝暴露，以支持跨DataMesh的治理报告，例如数据产品使用、标准合规性、数据产品反馈。在构建DataMesh生态系统时，一个关键的DataMesh实施原则是通过利用现有投资连接数据源：数据湖或数据仓库；云或本地设施等。在所有不同数据集之间生成连接后，下一个目标是为业务和分析团队创建一个接口来查找数据，称为逻辑域。所需的所有数据都驻留在各自的域中，并且域团队有权自主工作。有了自助服务的概念，数据消费者可以更加独立地完成。下一步是如何将数据集转换为数据产品。然后，使用数据产品创建图书馆或数据产品目录。创建数据产品是一项强大的功能，它使数据消费者能够非常快速地从发现转变为构思和洞察。事实上，DataMesh可能并不适合所有组织，它可能主要针对在运营和环境中经历不确定性和变化的大型组织。如果组织的数据需求很小并且这些数据需求不会随时间变化，那么数据网格可能是不必要的开销。7小结面对数据产生场景的变化、数据源的增长和扩散、数据用例和用户的多样性以及对变化的响应速度，当前的数据平台或数据中心面临着更大的挑战，DataMesh可能是解决这些问题的一种尝试。为了应对这些挑战以在提供数据质量和完整性保证的同时实现规模化承诺，任何数据网格实施都体现了四个基本原则：面向领域的分散数据所有权和架构数据作为产品自助服务数据基础设施作为平台联合计算治理在总之，DataMesh是一种现代数据管理的战略方法，是加强组织数字化转型的一种方法，其重点是提供有价值和安全的数据产品。
