将一个系统置于恒定的约束之下可能会导致脆弱性的进化。-- C.S. Holling, ecologist
成为一个数据驱动的组织是许多公司的战略目标之一，因为数据驱动的好处显而易见: 基于数据和个性化提供最好的客户体验; 通过数据驱动的优化降低运营成本和时间; 给予员工具有趋势分析和商业智能的力量。然而，尽管在构建数据平台方面付出了越来越多的努力和投资，仍然会发现结果并不理想。
当前的技术进步解决了数据处理计算的规模问题，但还有问题悬而未决: 数据产生场景的变化、数据来源的扩散、数据用例和用户的多样性以及对变化的反应速度。Data Mesh或许可以解决这些问题。
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 数据与自助服务的融合
将领域不可知的基础设施功能收集和提取到数据基础设施平台中，解决了重复设置数据流水线引擎、存储和流式计算的需要。数据基础设施团队可以提供必要的技术，而各个领域需要这些技术来捕获、处理、存储和服务它们的数据产品。将数据基础设施构建为平台的关键在于:
不包括任何特定于领域的概念或业务逻辑，保持其与领域无关;
确保平台隐藏了所有潜在的复杂性，并以自助服务的方式提供数据基础设施组件。
自助式数据基础设施可以降低“创建新数据产品的准备时间”，例如，通过配置和脚本自动化完成数据摄入，数据产品创建脚本及生成框架，自动将数据产品注册到目录中，等等。云作为底层，可以降低提供对数据基础设施按需访问的操作成本和工作量。
这样的新型数据平台， 被业界命名为“Data Mesh”。Data Mesh 平台是一个分布式数据架构，通过共享和协调的自助服务数据基础设施来实现互操作性，进而实现集中治理和标准化。
4. 什么是Data Mesh？
Data Mesh是现代数据管理的一种战略方法，也是加强组织数字化转型的一种方法，它集中于提供有价值且安全的数据产品。Data Mesh是超越利用数据仓库和数据湖的数据管理方法，强调组织灵活性，通过授权数据生产者和数据消费者的访问来管理数据，数据所有权分配给特定于领域的团队，这些团队将数据作为产品提供、拥有和管理。
4.1 Data Mesh 与 数据湖
数据湖是一种技术方法，其主要目标是作为一个单一的存储，以尽可能简单的方式将数据转移到中央团队负责管理的地方。虽然数据湖可以提供显著的业务价值，但它们也存在许多问题。主要的问题是，一旦数据被移动到湖中，它就失去了上下文，例如，可能有许多文件包含客户的定义，一个来自物流系统，一个来自支付，一个来自营销，哪一个适合使用呢？此外，数据湖中的数据没有经过预处理，因此不可避免地会出现数据问题。然后，数据使用者通常必须与数据湖团队联系，以理解和解决数据问题，这将成为使用数据回答初始业务问题的瓶颈。
相比之下，Data Mesh不仅仅是技术，它结合了技术和组织，包括数据所有权、数据质量和数据自治。因此，数据消费者对数据质量和数据所有权有着清晰的认识，数据问题可以更有效地发现和解决，最终可以使用和信任数据。
数据湖不再是Data Mesh的中心，而是将数据湖的一些原则应用于面向数据源的领域数据产品。然而，无论是用于数据产品的内部实现，还是作为共享数据基础设施的一部分，人们仍然继续使用数据湖工具。Data Mesh是把领域数据产品作为第一类关注点，把数据湖工具和管道作为第二类关注点。同样的原则也适用于用于业务报表和可视化的数据仓库。它只是Data Mesh上的一个节点，可能位于面向消费者的网络边缘。也就是说， 将大数据整体分解成一个协调、协作和分布式的数据网格生态系统。
4.2 Data Mesh 与 Data Fabric
Data Fabric 侧重于各种技术能力的集成，这些技术能力相互协作为最终用户生成一个接口。许多Data Fabric 的支持者通过像机器学习这样的技术来实现自动化，使得终端用户能够以更简单的方式访问数据。对于简单的数据使用来说，这是很有价值的，但是对于更复杂的情况，或者需要将业务知识集成到数据中的情况，那么 Data Fabric 的局限性就会变得明显。
可以说，Data Fabric 可以用作 Data Mesh 自助服务平台的一部分，在这个平台中，Data Fabric 将数据公开给领域，这些领域可以将其业务知识嵌入到最终的数据产品中。
Data Mesh的目标是为从分析数据和历史事实中获得价值创造一个基础，这些数据和历史事实在规模上适应于数据场景的不断变化、数据来源和消费者的扩大化、用例需要的转换和处理的多样性以及对变化的反应速度。
5 Data Mesh 的 四个核心原则
Data Mesh 的四项核心原则作为一个整体是必要且充分的，使规模具有弹性，同时解决不兼容数据的孤立问题或运营成本增加的问题。
5.1 领域驱动的数据所有权和数据架构
要理解什么是领域域驱动数据，必须知道领域是什么。在Data Mesh 中，领域是负责数据管理的相关数据和创建的业务功能，负责聚合、转换和向最终用户提供数据。最终，该领域将其数据作为数据产品公开，其整个生命周期由该领域自身所有。
也就是说，Data Mesh 的核心是建立去中心化并把责任分配给最接近数据的人，以支持持续的变化和可扩展性。那么，如何分解和去中心化数据生态系统的组成部分及其所有权呢？包括分析数据、元数据和为其服务所需的计算。
为了促进这种分解，需要一个按领域排列分析数据的架构。在此架构中，领域与组织其余部分的接口不仅包括操作能力，还包括对该领域所服务的分析数据的访问。这意味着必须消除耦合，以使领域服务于它们的分析数据，并使计算数据的代码独立于其他领域。为了扩展，必须支持领域团队在其操作或分析数据系统的发布和部署方面的自主性。当然，每个领域可以依赖于其他领域的操作和分析数据端点。
5.2 数据即为产品
发现、理解、信任并最终使用高质量数据是个重要的问题，随着提供数据领域的团队数量增加，这个问题只会随着Data Mesh而恶化，这就是领域自治的结果。数据即产品原则是为了解决数据质量和数据竖井问题而设计的，例如 Gartner 所说的暗数据——信息资产组织在日常业务活动中收集、处理和存储，但通常不能用于其他目的。领域提供的分析数据必须被视为一种产品，数据的消费者应该被视为客户。
领域数据产品所有者必须深入了解谁是数据用户，他们如何使用数据，以及对使用数据感到舒适的方法是什么。这种对数据用户的深入了解导致了满足需求的数据产品接口设计，所有数据产品都可以开发支持标准化接口。数据用户和产品所有者之间的对话是建立数据产品接口的必要部分。每个领域将包括数据产品开发人员的角色，负责构建、维护和服务领域的数据产品，数据产品的开发人员将与该领域的其他开发人员一起工作。每个领域团队可以提供一个或多个数据产品，还可以组建新的团队来服务那些自然不适合现有领域的数据产品。本质上，数据质量的问责制向上游转移，尽可能接近数据源。
数据产品是网格上的节点，它封装了功能所需的三个结构组件，作为产品提供对领域分析数据的访问。
代码: 它包括(a)负责消费、转换和服务上游数据的数据流水线的代码 (b)提供数据访问、语义和语法模式、可观测性指标和其他元数据的 API 代码; (c)执行功能特性的代码，如访问控制政策、合规性、出处等。
数据和元数据: 根据领域数据的性质及其消费模型，数据可以作为事件、批处理文件、关系表、图表等，同时保持相同的语义。为了使数据可用，有一组相关的元数据，包括数据计算文档、语义和语法声明、质量指标等; 数据固有的元数据，例如其语义定义，元数据用于实现预期行为的特征，例如访问控制策略。
基础设施: 基础设施组件支持构建、部署和运行数据产品的代码，以及存储和访问大数据及元数据。
总的来说，数据产品由领域生产，由下游领域或用户使用，以创造业务价值。数据产品不同于传统的数据集市，因为它们是独立的，本身负责与确保数据保持最新有关的安全、来源和基础设施等方面的问题。数据产品支持明确的所有权和责任，可以由其他数据产品或最终消费者直接使用，以支持商业智能和机器学习活动。
5.3 自助式的数据平台
领域团队能够自主地拥有数据产品的唯一方法是访问基础设施的高级抽象，从而消除提供和管理数据产品生命周期的复杂性。这就需要一个新的原则，自服务数据基础设施作为一个平台，支持领域自治。
自助式数据基础设施由许多功能组成，领域的成员可以轻松地使用这些功能来创建和管理其数据产品。自助式平台功能按照模型中的调用分为多个类别或平面，每个平面服务于不同的用户配置文件。一个平面类似于网络中的控制层和数据层。自助式数据平台由一个基础设施工程小组提供支持，该小组的主要任务是对所使用的各种技术进行管理和操作。这是一种关注点分离，领域团队关注数据，自助式数据平台团队关注技术。自助服务数据平台的度量标准是领域的自主性。
也就是说，可以将数据平台视为已经存在的用于运行和监视服务的交付平台扩展。然而，当前用于操作数据产品的底层技术堆栈与数据服务的交付平台非常不同，也是大数据技术栈与业务系统平台的分歧。例如，业务领域域团队可能服务部署为 Docker 容器，交付平台使用 K8s， 然而，数据产品可能将其流水线代码作为一个 Hadoop集群上的作业运行。这是两套完全不同的基础设施，而DataMesh 需要这种级别上的互操作性和互连性，在合理的地方趋于一致。
5.4 联邦体系的治理
传统的数据治理往往被看作是数据创造价值的阻碍因素。DataMesh 通过将治理关注点嵌入到领域的工作流中，数据治理有许多方面，使用度量和报告必须成为这个定义的一部分。数据的使用量以及如何使用这些数据是理解数据产品的价值从而获得成功的关键点。
Data Mesh的实现需要一个治理模型，该模型包括领域自治、标准化的互操作性、动态拓扑结构，最重要的是平台自动执行决策，可以称之为联邦计算的治理。一个由领域数据产品所有者和数据平台产品所有者联盟领导的决策模型，拥有数据所有权和领域本地决策权，同时创建并遵守一套全局规则，即一套适用于所有数据产品及其接口的规则，以确保生态系统的健康和互操作性。这个团队有一个艰巨的任务: 维持集权和地方分治之间的平衡，哪些决策需要本地化到每个领域，哪些决策需要全局化到所有领域。最终，全局决策只有一个目的，即通过发现和组合数据产品，创建互操作性和复合网络效应。
|
数据仓库和数据湖的数据治理 |
Data Mesh 的数据治理 |
|
中心化团队 |
负责定义如何建立构成质量的模型 |
|
负责数据安全 |
负责定义数据安全的各个方面，例如平台内置和自动监控的数据敏感性级别 |
|
负责遵守规章制度 |
负责定义平台内置和自动监控的法规要求 |
|
数据的集中保管 |
按领域联合保管数据 |
|
负责整体规范的数据建模 |
负责建模跨越多个领域边界的数据元素 |
|
团队独立于业务领域 |
团队由各领域代表组成 |
|
针对定义良好的静态数据结构 |
旨在实现有效的网格操作，包括不断变化和动态的网格拓扑结构 |
|
整体式湖泊/仓库的中心化技术 |
每个领域使用的自服务平台技术 |
|
根据受治理数据(表)的数量或容量来度量成功 |
基于网络效应(表示网格上数据消耗的连接)来度量成功 |
|
人工干预的手工过程 |
由平台实现的自动化流程 |
|
防止错误 |
通过平台的自动化处理检测错误并恢复 |
一个支持性的组织结构、激励模式和架构是联邦治理模式发挥作用的必要条件: 在尊重地方领域自主性的同时，达成全局互操作性的决策和标准，并有效地执行整体策略。在所有领域及其数据产品的平台实施和执行的全局标准化内容与留给领域决定的内容之间取得平衡或许是一门艺术。
6. Data Mesh的实现
Data Mesh的实现为那些希望在不确定的经济环境中蓬勃发展的组织提供了灵活性，所有组织都需要能够以低成本、高回报的方式来应对环境的变化。引入新的数据源、需要遵守不断变化的法规要求或满足新的分析要求，这些都是促使组织数据管理活动发生变化的驱动因素。当前的数据管理方法通常基于复杂的、高度集成的 ETL，这些 ETL 位于业务系统和分析系统之间，需要努力及时变化以支持业务需求。Data Mesh为数据管理提供了一个更具弹性的方法，以有效地应对这些变化。
Data Mesh是一种涉及人、过程和技术的社会化技术方法，需要在人、过程和技术的所有三个维度上对组织进行变革，可能会将70% 的精力花在人员和流程上，30% 的精力花在技术上。人员从中心化的数据团队分散到各个领域，现有的工作人员对于采用Data Mesh的成功至关重要，他们拥有的知识和技能会做出贡献。因此，管理层级和奖励机制也发生了变化。为了促进可持续和敏捷的数据架构，需要在组织内部进行流程更改。考虑数据治理，将需要围绕数据策略定义、实现和执行的新流程，这将影响访问和管理数据的流程，以及将该数据作为业务流程的一部分进行利用。
技术能力是实现和运营Data Mesh的关键，可能需要新技术的原因如下:
- 减少跨技术开发的摩擦，这些新技术的互操作性可能是至关重要的。
- 使领域能够自给自足，并将重点放在第一类关注点上，即数据而不是技术。
- 允许在线购买新的数据平台，并且可以无缝地公开这些平台所暴露的数据
- 支持跨Data Mesh的治理报告，例如数据产品使用情况、遵守标准情况和数据产品反馈。
在构建Data Mesh生态系统的时候，一个关键的 Data Mesh 实现原则是通过利用现有的投资来连接数据源: 数据湖或数据仓库; 云或内部设施等。在生成跨所有不同数据集的连接之后，下一个目标是为业务和分析团队创建一个用于查找数据的接口，称之为逻辑域。需要的所有数据都驻留在各自的领域中，领域团队有权自主工作。通过自助服务的概念，数据使用者可以独立完成更多的工作。下一步是如何将数据集转换为数据产品。然后，使用数据产品创建一个库或数据产品目录。创建数据产品是一项强大的功能，使数据消费者能够非常快速地从发现过渡到构想以及洞察。
事实上，Data Mesh 可能并不适合于每个组织，可能主要针对那些在运营和环境中遇到不确定性和变化的大型组织。如果组织在数据方面的需求很小，而且这些数据需求不会随着时间的推移而改变，那么Data Mesh可能是一个不必要的开销。
7 小结
面对数据产生场景的变化、数据源的增长和扩散、数据用例和用户的多样性以及对变化的反应速度，当前的数据平台或数据中台面临着较大的挑战，而Data Mesh 或许是解决这些问题的一种尝试。
为了面对这些挑战，以实现规模化的承诺，同时提供使数据质量和完整性保证，任何Data Mesh的实现都体现了四个基本原则：
- 面向领域的分散数据所有权和体系结构
- 数据作为产品
- 自助数据基础设施作为平台
- 联邦计算治理
一句话，Data Mesh是现代数据管理的一种战略方法，也是加强组织数字化转型的一种方法，它集中于提供有价值且安全的数据产品。
