| 摘自Jacek Majchrzak, Sven Balnojan, and Marian Siwiak的《Data Mesh in Action》。 本节选探讨了数据网格作为一个概念的四个原则。 如果你有兴趣了解什么是数据网格以及如何使用它，请阅读此文。 |
打75折 数据网格在行动在manning.com结账时在折扣代码框中输入fccsiwiak。
Zhamak Dehghani首先将目前的数据网格概念的化身描述为一套四项原则：领域所有权、领域数据作为产品、联合计算治理和自我服务数据平台。然而，从我们的角度来看，数据网格实施成功的关键在于理解它是一个社会技术架构，而不是一个技术解决方案。在这篇文章中，我们将介绍Dehghani的4个原则，并解释社会技术方面的问题，这是理解Data Mesh架构的关键。
面向领域的去中心化数据所有权和架构
第一个原则是，数据及其相关组件应该由最接近它的人拥有、维护和开发，也就是数据领域内的人。这就要求在数据世界中应用领域和受限环境的概念。这也意味着对所有权和架构的去中心化的应用。
这个想法是，领域内部的工程师负责开发数据接口，允许其他用户（例如数据科学家、自助式BI用户、数据工程师和系统开发者）使用领域数据。一个数据产品的数据工程师应该是单一领域内的专家，这样可以最大限度地减少沟通问题和对数据的误解。
数据应该有明确的所有权，它不应该在集中的组织层面上；我们应该把这个责任放在最接近它的人的手中。在面向源的数据集的情况下，这可能是领域团队，也可能是数据工程团队、分析工程团队或数据科学团队，用于从其他方面创建的新数据集。如果我们的数据集是一个非常面向消费者的数据集，它也可以是使用该数据的组织单位。
领域是我们业务的一个区域或部分。它是一种对公司进行切分和分解的方式。很多时候，我们的组织结构类似于业务领域。
在任何给定的业务中，你可以找到像内容分发、内容生产和市场、以及品牌发展这样的领域。
图1.一个名为Messflix LLC的虚构企业的简化业务领域简图。
领域所有权原则说，拥有这些领域的每个团队或单位也应该拥有在这些领域内创建的数据。因此，开发软件以支持内容生产的团队也要对内容生产数据负责。但是，对数据负责是什么意思呢？
对数据负责意味着为组织的其他部分，即为其他域，托管和提供数据集。所有权不仅跨越了数据；团队还应该对管道、软件、清理、重复数据和丰富数据负责。
就像敏捷原则和敏捷团队一样，如果没有同时拥有自主权，所有权本身就没有多大意义。这就是为什么团队应该能够自主地发布和部署运营和分析数据系统。
每个企业都由许多领域组成。这些领域中的每一个通常都可以进一步分割成子领域。通过应用这一原则，我们最终将得到一个由相互连接的领域数据节点组成的网状结构。网状结构的节点可以，甚至应该被连接起来。当需要时，数据可以在各域之间移动、复制和改变形状。例如，数据通常会从面向源头的数据域（运营系统的输出）移动到更面向消费者的数据域，在那里，原始数据会被习惯性地汇总并转化为更适合消费者的形状和格式。
在这样一个由相互关联的领域和子领域组成的网状结构中，只有接近数据的人对其有足够的了解，才能真正使用它。以图1为例："内容 "这个词在所有三个领域中的含义都一样吗？希望不是，因为在 "生产内容 "领域，我们将有正在创建的内容的 "草案版本和想法"，以及随后将成为真正生产的内容。然而，在 "分发内容 "领域，这将意味着生产化的最终内容。
试想一下，一个来自 "分发内容 "领域的开发者，应该从 "生产内容 "领域编制一个 "内容作品 "的清单。他可能会产生一个已生产的内容片段的列表。然而，这将错过重点。这个要求可能是要求所有的内容片断的列表，包括想法，仍然在生产的东西，和取消的片断。此外，这些内容作品的状态也应该包括在内。
然而，这个领域之外的人甚至不会知道这些是重要的数据。因此，使域内的人成为唯一真正能够处理这种数据的人。
源数据域通常服务于代表业务事实的数据和信息。数据应该被暴露给其他域，以服务于运营目的（如REST API）和分析目的。源数据域应该暴露出领域事件和随时间汇总的历史快照。对于后者，我们应该确保底层存储为大数据分析消费而优化（如数据湖）。在前面的例子中，"生产内容 "域成为一个源数据域，当它暴露了生产的内容片断的列表。这是由创建内容的业务流程创建的原始数据。
消费者数据域与消费紧密结合。这种领域的一个很好的例子是管理报告和预测。在Messflix LLC的案例中，它可能是内容建议域，可能是内容分发的一个子域。如果现在营销团队把制作好的内容列表，用相关的营销材料、用来推广的推文等来充实它，那么新的列表就会滑向消费者数据域。
数据域之间的部分数据是可以重复的。尽管如此，由于它的目的不同，它的建模方式也会不同；这意味着域的边界通常也是数据模型的边界。因为我们希望给团队尽可能多的自主权，所以我们并不试图为整个组织创建一个单一的规范模型。我们给他们自由，以他们需要的方式来建立数据模型。除了源和消费者对齐的域，我们还可能遇到整个组织使用的核心数据域，通常代表关键实体或对象。
当我们在整个组织内分享数据的责任时，我们会获得巨大的可扩展性和可维护性。例如，当我们想向Mesh添加新的数据集时，我们将添加一个新的自主节点。同时，拥有数据集的团队将处于一个非常舒适的状态。他们将只拥有他们真正理解的数据。
数据作为一种产品
第二个原则是，必须将数据视为一种产品。这就要求引入产品思维，并将其纳入数据管理。
通常，当我们谈论数据时，首先想到的是一个文件或数据库中的一个表。当我们想到数据的时候，我们经常会看到一个电子表格或文件中一系列带有命名的列的行。从这个角度来看，我们很容易将数据简化为技术细节。但是，更重要的问题是：从组织的角度看，是什么赋予了数据以价值？或者反过来说：是什么阻止了我们的数据被转化为有价值的决策？
如果没有一套合适的描述，即使准备得再好的数据也不会被发现，因此也无法从中提取价值。缺少关于数据的回顾性或完整性的信息可能会使其在需要这些属性的情况下完全失去作用。 这就是为什么值得把数据看作一个产品，即一个更大的整体，最终构成了使用它的用户的体验。
数据团队提供的数据应遵循典型的产品特征，如。
- 可行的质量--由专门的领域专家保证。
- 预测用户需求--向外界提供数据的团队应了解企业的业务环境，例如，以容易被现有数据管道消化的格式呈现数据，以确保所提供数据的可用性和易于使用。
- 保证可用性--确保产品的可用性，以便在用户需要的时候满足他们的需求。
- 关注用户目标--关注一个领域并不意味着数据团队与其他用户缺乏沟通；相反，寻求协同效应和共享工具集应该创造一个机会来更好地了解彼此的需求。
- 可查找性--任何数据产品都应该可以通过简单的方式被发现，这是数据库中的随机表格所缺乏的。
- 可互操作性--不同的数据产品应该能够以一种增加其价值的方式进行组合。
什么时候我们可以把数据称为产品？
在日常生活中，我们与许多产品打交道。一般来说，产品可以被定义为 "有意识的行为的结果"。如果我们以一条牛仔裤为例，我们确信它符合某些预先确定的条件。一个产品要被称为一条牛仔裤，它必须有一个合适的形式和形状，并由某种材料制成。此外，它应该有其独特的名称（特别是如果制造商提供许多特定类型的产品），因为我们购买的是一个特定的模型，而不是一般的牛仔裤。
它还应该符合一些标准，以确保一条牛仔裤在使用几个小时后不会坏掉。除此之外，还有人对这个产品、它的质量以及在公认的、不言而喻的使用条件下的使用后果负责。我们可以用这种思维来思考数据的问题。
把数据当作一个产品，将意味着有人有意识地设计了这个产品，然后创造并发布了它，对它负责，并主要对它的质量负责。在数据网的背景下，这将是数据产品所有者（设计数据产品的人）和实施数据产品的开发者的责任。就像商店里货架上的产品一样，一个数据产品有其独特的名称和既定的特征，包括。
- 质量水平
- 可用性水平
- 安全规则
- 更新的频率
- 具体内容
当我们考虑产品时，仅仅暴露数据是不够的。我们还需要确保我们为终端用户最大限度地提高其可用性。在这种情况下，数据产品负责人的角色至关重要，因为他或她要对数据的最终用户体验负责。
参照前面提到的Messflix的例子，我们可以想象在生产内容领域有几个典范的数据产品。
- 成本报表
- 脚本
- 演员
- 电影受欢迎程度
- 电影趋势
把数据当作一个产品来对待，使我们直接进入了产品思维的方法；从你的客户希望解决什么问题开始，让它来驱动数据产品的设计过程。然后，作为一个数据产品负责人，你应该根据预先定义的成功标准，提供一个解决这些问题的数据产品。
数据作为一种产品也意味着一定程度的标准化，允许单一元素被纳入一个更大的数据网生态系统中。要把一个给定的数据集称为数据产品，它应该是。
- 自我描述和可发现--数据应该被描述，而且这种描述应该是数据产品的一个组成部分。一个数据产品应该能够在数据网的生态系统中注册自己，因此，应该是可发现的。
- 可寻址--它应该有一个唯一的地址（例如URI地址的形式），这样它就可以被引用，数据产品之间的关系也可以被创建。
- 可互操作性--数据产品应根据预定的标准制作，涉及数据共享的形式、标准化的格式、词汇表、术语或标识符、安全和值得信赖。一个数据产品应该满足既定的和声明的SLA，并且能够控制访问，从两个角度确保数据安全：知识产权和GDPR类型的法规。
作为一个自主组件的数据产品
在满足之前建立的条件的同时，一个数据产品应该同时构成一个自主的组件，这样它就可以由负责特定数据产品的团队独立开发。从技术解决方案的角度来看，我们可以把数据产品看作是数据世界中微服务的一个类似物。除了提供数据之外，数据产品还嵌入了与数据转换、清理或协调有关的代码。它还公开了与数据网环境和平台自动集成的接口，提供了，除其他外。
- 输入逻辑和输出端口- 用于从源头摄取和向消费者暴露数据的形式和协议。
- 操作指标--用户数量、吞吐量、获取的数据量等。
- 数据质量报告--不完整数据的数量、格式不兼容、异常值的统计措施等。
- 元数据--数据模式的规范和描述、领域描述、业务所有权等。
- 配置端点--在运行时配置数据产品的手段，例如，设置安全规则。
这些是可以构成数据产品的技术组件的几个例子。
联合计算治理
第三个原则是在数据网的所有参与者中实现数据治理的联合化和自动化。它的目的是为基本独立的数据产品的生态系统提供一个统一的框架和互操作性。其目的是使自主的数据产品在实际的数据网中工作，而不仅仅是作为独立的产品。
联合计算治理需要两个不可分割的要素：一个管理机构和一个执行手段。
总体规则和条例应由一个由数据产品所有者、自助数据基础设施平台团队、安全专家以及CDO/CIO/CTO代表组成的机构商定。该机构还将作为一个讨论场所，例如，开发新的数据产品与向现有数据产品添加新的数据集，摄取新的外部数据源的方法，中央平台开发的优先级，等等。
有效的数据治理是至关重要的，数据安全是所有行业和规模的公司的CDO/CIO的主要关注点之一。同时，大多数大型企业需要引入政府或商业法规强制执行的数据安全和治理的控制措施，例如GDPR、HIPAA、PCI DSS或SoX。
数据治理的联邦化
乍一看，数据网格给已经很庞大的数据治理范围增加了一层新的复杂性，因为它现在还需要解决对数据产品的责任转移。反过来，每个数据产品都需要配备流程，允许以安全和有效的方式处理拥有的基础设施、代码和数据（和元数据）。此外，数据治理流程需要平衡公司范围内的数据解决方案的凝聚力，通常是通过标准化与提供给数据产品团队的自主性驱动的灵活性和创造性来实现的。
必须明白，没有银弹解决方案来平衡中央治理和地方自治！这总是取决于具体的细节。这将始终取决于你的组织的具体情况。例如，你的数据产品拥有者的需求和成熟度是什么？组织的数据相关风险偏好是什么？你的中央数据治理团队的专业知识水平如何？你所处理的数据有多敏感？你需要回答这些问题以及更多的问题，然后你才能设定中央和地方团队的职权范围。
另一套政策是需要的，以确保数据产品的互操作性和数据消费者能够随时将它们连接在一起。最后，程序需要提供不同的数据产品的兼容性，而不明确地强制执行一个总体的数据模型，因为这样的方法已经被证明会在数据操作中造成瓶颈。
数据网试图通过数据治理的联邦化来满足这一需求。在这种情况下，联邦化意味着治理结构在不同的层面上运作--中央和地方。中央层面的治理，由数据治理委员会执行，将决定一套最小的全球规则，以确保数据产品的安全和可靠的可发现性和互操作性。
由数据产品所有者领导的数据产品团队负责开发他们的产品，具有高度的自主性，决定其职权范围内的所有技术和程序问题（在企业技术栈的边界内）。
对于责任的精确划分、数据治理委员会的结构以及管理数据世界的确切规则，没有银弹解决方案。相反，每个企业都会有自己的一套全球规则，让领域团队对其数据产品有不同程度的控制。
数据治理的计算元素
Federated Computational Governance这个名字是由Zhamak Daghani在她事实上的"Data Mesh宣言"博客文章中提出的。然而，由于计算治理在其他地方没有定义，我们将假设这个术语与数据治理自动化的元素有关，由作为连接不同数据产品的媒介的中央平台的存在来实现。
可以自动化并嵌入数据平台的数据治理要素包括，但不限于。
- 元数据
- 目录、参考和主数据
- 血统和来源
- 验证和核查
- 存储和操作
- 安全和隐私
再次，没有银弹解决方案来决定其中哪些应该被自动化。这需要你的团队努力工作，以确定哪些数据治理任务在你的组织的数据网格开发中造成瓶颈，并将其自动化。然而，这将会得到回报。首先，它将为数据产品拥有者提供解决方案，使他们的数据产品能够无摩擦的连接。其次，它将使用户能够有效地使用暴露的数据。
当我们讨论自助式数据基础设施即平台的细节时，你会了解更多关于数据治理的自动化元素。
作为平台的自助式数据基础设施
第四项原则是将数据网的重复工作提取到一个平台中。它要求将 "平台思维 "应用于数据背景。平台思维意味着，那些在整个公司范围内较大程度上重复的工作也可以打包成一个 "平台"，从而只做一次，但作为一种 "服务 "提供给其他人。
就像任何人都可以在主要的云供应商之一租用云资源，并根据自己的需要进行定制，带走重复维护自己的云的努力，他的想法可以缩减到公司内部的努力。
建立和维护数据产品是资源密集型的，需要一系列非常专业的技能（从计算环境管理到安全）。将所需的努力乘以数据产品的数量将危及整个数据网想法的可行性。中央平台的想法是在必要的程度上集中可重复和可通用的行动（这也取决于公司的背景！），并提供一套工具来抽象出专业技能。它将减少数据产品开发者和数据产品消费者的进入和访问障碍。
你可以从你的第一个数据产品拥有者的要求开始，反复建立设置，以满足你的组织的需求。
基础设施支持可以在内部计算能力或云中提供，这取决于企业政策。它的元素可以在IaaS、PaaS、SaaS或其混合模型中提供。数据网平台可以支持。
- 可管理性--所有与数据治理过程相关的数据计算都需要被纳入，并在连接到数据基础设施的每个数据产品上自动执行。
- 安全性--基础设施解决方案应确保所有数据产品为用户提供操作自由，其访问允许他们满足其信息要求，并确保安全，避免未经授权的访问。为了做到这一点，数据产品创建者和用户应可以使用一套随时可用的流程、工具和程序。
- 灵活性、适应性和弹性--基础设施需要支持多种类型的业务领域数据。这意味着启用不同的数据存储解决方案、ETL和查询操作、部署、数据处理引擎和管道。所有这些都需要是可扩展的，以便在业务需求出现时为其服务。
- 弹性--数据驱动型企业的顺利运作需要数据的高可用性。因此，他们在每个基础设施元素的设计层面上确保冗余和灾难恢复协议。
- 流程自动化--从数据产品注册处的数据元数据注入到确保访问控制，通过中央基础设施的数据流需要完全自动化，可能使用机器学习和人工智能来确保高效的数据处理、质量和监控。
现在你已经很好地掌握了四个关键的数据网格原则，让我们来谈谈作为社会技术架构的数据网格。
社会技术架构
Data Mesh不是一个解决数据问题的技术方案。Data Mesh使用社会技术架构或社会技术系统设计来解决这些问题。我们认为这是Data Mesh作为一种范式的最大优势，我们认为你应该将社会技术架构视为数据网格实施的基础。你需要有意识地应用社会技术架构来使其成功。
但在这之前，我们需要获得一些背景信息。为此，我们研究了康威定律，以了解为什么我们无法自行改变技术，然后再研究团队拓扑框架，其本质是关于社会技术架构。最后，我们研究一下认知负荷，这是团队拓扑框架所利用的主要思想之一。
康威定律
"任何组织在设计一个系统（广义的定义）时，都会产生一个设计，其结构是该组织通信结构的副本。
Melvin Conway在1967年提出了这一观点，就在第一种广泛使用的高级语言FORTRAN发布的十年后。没过多久，我们就在实践中看到了这种强大的、几乎是引力的力量。这股 "力量 "迟早会改变我们的架构，使它看起来像我们的组织结构。作为建筑师，我们需要充分意识到隐含的后果。
我们应该以名为合气道的武术为例。合气 "是指与攻击者的动作相融合的武术原则或战术，以最小的努力控制他们的行动。合气道的大师们教导你，你不应该用武力来对付武力。相反，你应该利用你的对手所施加的力量。同样地，我们应该警惕并利用康威法则的优势。
**例子 中央数据仓库
**
康威定律很好地解释了为什么人们说 "中央数据仓库"，但意思是 "由中央数据团队操作的中央数据仓库"。这是因为通常当你发现一个中央数据仓库时，它是由一个中央数据团队建立的。
康威法则简单地告诉我们要同时照顾到组织方面和技术方面的事情。仅仅改变技术上的东西是不会产生影响的。组织会扭曲或误用技术方面的东西。
团队拓扑结构
顾名思义，在社会技术架构方法中，我们试图同时共同设计社会和技术架构元素。这样一来，我们就可以预先考虑到所有的限制和关注。
构建团队拓扑结构的不恰当的例子
试着想一想建造摩天大楼的过程。它在结构上与村民们集体为他们社区中的一个成员建造谷仓不同。一座摩天大楼是由高度专业化的团队建造的，其中一些人负责 "前线"，一些人负责 "支持 "角色。你不会派电工去安装窗户（双关语）。在特定的时间，在特定的地点使用的技术的要求决定了执行任务的团队。
这一节是关于今天以及在数据网社区内用来做好社会技术架构的一种主要架构方法。
"团队拓扑结构是一种清晰、易懂的现代软件交付方法，强调优化团队互动的流程。"（来源：teamtopologies.com）
Matthew Skelton和Manuel Pais创造了团队拓扑结构，由于其简单和直接的应用，他们开始在社区中得到一些关注。团队拓扑是一种帮助你不落入康威法则的陷阱的方法。团队拓扑框架的设计是为了优化公司内部的团队，使其达到最佳流程。它在很大程度上依赖于认知负荷的理念，在这个流程中适当地分配工作负荷，并将团队分离为少数几个团队，以及将互动模式分离为旨在最小化认知负荷的模式。
由于团队拓扑结构专注于公司的最佳流程，它将帮助我们优化公司内部的数据到价值流。
认知负荷
认知负荷是一个来自认知负荷理论的术语，它意味着一个人所使用的心理资源（工作记忆）的数量。这个理论首先被应用于教学领域，它影响了我们如何编写说明，使读者能够轻松地消化它们。但在那之后，它被用于越来越多的领域，比如IT。
认知负荷有三种类型。
- 内在的：你构建产品所需的技能和知识（如编程语言、框架和模式）。
- 外在的活动不是产品开发的一部分，但在发布产品时需要（如基础设施、部署和监控）。
- 全局性的：业务和问题空间的知识（比如，如果你是Messflix LLC的开发者，那么电影的类型）。
作为社会技术架构师，我们应该塑造我们的团队，使总的认知负荷得到限制。这与道路交通非常相似，如果你把道路的每一平方米都塞满汽车，你就无法最大限度地提高汽车的流量；当车辆之间有足够的空间使它们能够以接近限速的方式行驶时，交通才会以最快的方式前进。这对团队来说也是如此。
那么，我们能做些什么来使Data Mesh团队的性能提高呢？因此，首先，我们应该把我们的技术栈规划得简单，以限制内在的负载。其次，我们应该接受平台思维，不要强迫团队每次都用另一个监控和日志解决方案来重新发明车轮，以限制外在的负载。做到这两点，就可以让团队完全专注于重要的事情：相关的负载，又称业务领域。但是，外在的负载也应该被限制，我们将通过把解决方案分解成更小的面向领域的数据产品来做到这一点。
所有的原则都受到社会技术思维方式的影响。
面向领域的分散的数据所有权和架构，通过分散领域和相应数据的责任，减少外在的负荷。
数据作为一种产品，通过使数据可查找、可访问、可互操作和可重用，减少了团队之间访问数据的协作；通过将数据以预期和已知的格式和端口暴露给消费团队，限制了外在的负载。
作为平台的自我服务数据基础设施通过提供自我服务平台来减少外在的负荷。
联合计算治理通过执行共同的标准和模式，使团队之间的合作更加容易；它通过减少公司内部可能的技术堆栈，使团队成员的转移更加容易。
正如你所看到的，在每个原则的核心，我们发现社会技术的思维方式。由于这种范式转变的社会技术性质，我们必须清楚这种转变可能带来的好处。
虽然数据网格是一个解决许多问题的社会技术解决方案，但也有一些与之相关的重大挑战。
现在就说到这里。谢谢你的阅读。
The post ThePrinciples of the Data Mesh Architectureappeared first onManning.
