数据网格中的架构和职能

Last reviewed 2022-10-06 UTC

数据网格是一种架构和组织框架，它将数据视为产品（在本文档中称为“数据产品”）。在此框架中，数据产品由最了解数据并遵循组织范围的一组数据治理标准的团队开发。将数据产品部署到数据网格后，组织中的分布式团队可以更快速、高效地发现和访问与其需求相关的数据。为了实现此类运行状态良好的数据网格，您必须先确立本文档介绍的概要架构组件和组织角色。

本文档是系列文章中的一篇，该系列介绍了如何在 Google Cloud 上实现数据网格。本文档假定您已阅读并熟悉使用 Google Cloud 构建现代分布式数据网格所述的概念。

本系列文章包含以下部分：

• 数据网格中的架构和函数（本文档）
• 为数据网格设计自助式数据平台
• 在数据网格中构建数据产品
• 在数据网格中发现和使用数据产品

在本系列文章中，所介绍的数据网格在组织的内部。虽然可以扩展数据网格架构以向第三方提供数据产品，但这种扩展方法不在本文档的讨论范围内。扩展数据网格涉及到其他注意事项，而不仅仅是组织内的使用。

架构

以下关键术语用于定义本系列文章中所介绍的架构组件：

• 数据产品：数据产品是一个或多个相关数据资源的逻辑容器或分组。
• 数据资源：数据资源是存储系统中的物理资产，用于保存结构化数据或存储生成结构化数据的查询。
• 数据特性：数据特性是数据资源的字段或元素。

下图简要介绍了在 Google Cloud 上实现的数据网格中的关键架构组件。

上图显示了以下内容：

• 中央服务可以创建和管理数据产品，包括影响数据网格参与者的组织政策、访问权限控制（通过 Identity and Access Management 群组）以及特定于基础架构的工件。创建平台组件和解决方案中介绍了此类承诺和预留以及便于数据网格正常运行的基础架构的示例。
• 中央服务主要为数据网格中的所有数据产品提供数据清单，并为这些产品的潜在客户提供发现机制。如需了解如何在数据清单中注册数据产品，请参阅描述和整理数据网格中的数据产品和资源。
• 数据域通过明确定义的数据使用接口将其数据子集公开为数据产品。这些数据产品可以是表、视图、结构化文件、主题或数据流。在 BigQuery 中，数据产品是数据集；在 Cloud Storage 中，数据产品是文件夹或存储桶。您可以将不同类型的接口公开为数据产品。一个接口示例是 BigQuery 表上的 BigQuery 视图。在数据网格中构建数据产品中讨论了最常用于分析的接口类型。

数据网格参考实现

您可以在 data-mesh-demo 代码库中找到此架构的参考实现。该参考实现中使用的 Terraform 脚本只是对数据网格概念进行了演示，但并不适用于生产用途。通过运行这些脚本，您将了解如何执行以下操作：

• 将产品定义与底层数据分隔开。
• 创建用于描述产品界面的 Data Catalog 模板。
• 使用这些模板标记产品界面。
• 向产品使用方授予权限。

对于产品界面，该参考实现会创建和使用以下界面类型：

• 针对 BigQuery 表的授权视图。
• 基于 Pub/Sub 主题的数据流。

如需了解详情，请参阅代码库中的自述文件。

数据网格中的职能

为使数据网格正常运行，您必须为在数据网格中执行任务的人员定义明确的角色。所有权会分配给团队原型或职能。这些职能保留了操作数据网格的人员的核心用户体验历程。为明确描述用户体验历程，已将其分配给用户角色。这些用户角色可以根据每个企业的状况进行拆分和组合。您无需与组织中的员工或团队直接映射角色。

数据域与业务部门 (BU) 或企业内的职能保持一致。业务域的常见示例可能包括银行的抵押贷款部门，或企业的客户、分销、财务或人力资源部门。从概念上讲，数据网格中有两个与域相关的职能：数据提供方团队和数据使用者团队。请务必注意单个数据域可能会同时充当这两个职能。数据域团队根据其拥有的数据提供数据产品。该团队还使用数据产品进行业务数据分析，并提供派生数据的产品以供其他域使用。

除了基于域的职能之外，数据网格还具有一组由组织内的集中式团队执行的职能。这些中央团队通过提供跨域监督、服务和治理来实现数据网格的运行。他们可以降低数据域在提供和使用数据产品的运营负担，并提升数据网格运行所需的跨域关系。

本文档仅介绍了具有数据网格专用角色的职能。无论平台采用什么架构，任何企业都需要一些其他角色。但其他角色不在本文档的讨论范围内。

数据网格中的四个主要职能如下：

• 基于数据域的提供方团队：在生命周期内创建和维护数据产品。这些团队通常称为数据提供方。
• 基于数据域的使用者团队：发现数据产品并将其用于各种分析应用。这些团队可能会使用数据产品来创建新的数据产品。这些团队通常称为数据使用者。
• 中央数据治理团队：定义和实施数据提供方之间的数据治理政策，以确保为使用者提供高数据质量和数据可信度。该团队通常称为数据治理团队。
• 中央自助式数据基础架构平台团队：为数据提供方提供自助式数据平台。该团队还会提供用于数据使用者和数据提供方所用的集中式数据发现和数据产品可观测性的工具。该团队通常称为数据平台团队。

需要考虑的可选额外职能是数据网格的卓越中心 (COE) 的职能。COE 旨在提供对数据网格的管理。COE 也是负责解决任何其他职能引起的任何冲突的指定仲裁团队。此职能对于关联其他四个职能非常有用。

基于数据域的提供方团队

通常，数据产品是在数据物理存储库（单个或多个数据仓库、数据湖或数据流）的基础之上构建的。组织需要传统的数据平台角色来创建和维护这些物理存储库。但是，这些传统的数据平台角色通常不是创建数据产品的人员。

如需通过这些物理存储库创建数据产品，组织需要混合使用数据从业者角色，例如数据工程师和数据架构师。下表列出了数据提供方团队所需的域专用的所有用户角色。

角色	职责	所需技能	预期的结果
数据产品所有者	充当数据产品的主要业务联系人。 负责定义、政策、业务决策以及公开为产品的数据的业务规则的应用。 充当业务问题的联系人。因此，所有者在与数据使用者团队或集中式团队（数据治理和数据基础架构平台）会面时代表数据域。	数据分析 数据架构 产品管理	数据产品为使用者带来价值。对数据产品的生命周期进行可靠的管理，包括决定何时弃用产品或发布新版本。 通用数据元素与其他数据域实现协调。
数据产品技术主管	充当产品的主要技术联系人。 负责实现和发布产品接口。 充当技术问题的联系人。因此，技术主管在与数据使用者团队或集中式团队（数据治理和数据基础架构平台）会面时代表数据域。 与数据治理团队合作，在组织中定义并实现数据网格标准。 与数据平台团队合作，结合提供和使用数据生成的技术需求来开发平台。	数据工程 数据架构 软件工程	数据产品符合业务需求，并遵循据网格技术标准。 数据使用者团队使用数据产品，并且数据产品显示在数据产品发现体验生成的结果中。 可以分析数据产品的使用情况（例如每日查询数量）。
数据产品支持	充当生产支持的联系人。 负责维护产品服务等级协议 (SLA)。	软件工程 站点可靠性工程 (SRE)	数据产品满足规定的服务等级协议 (SLA) 要求。 解决了数据使用者有关数据产品使用的问题。
数据域的主题专家 (SME)	与来自其他数据域的 SME 会面来确立组织中通用的数据元素定义和边界时代表数据域。 帮助数据域中的新数据提供方定义其产品范围。	数据分析 数据架构	与来自数据域的其他 SME 协作，确立并维护对组织中的数据及其使用的数据模型的全面理解。 有利于创建与组织的整体数据模型匹配的互操作数据产品。 数据产品创建和生命周期管理有明确的标准。 来自数据域的数据产品提供了业务价值。
数据所有者	负责内容领域。 负责数据质量和准确性。 批准访问请求。 为数据产品文档做出贡献。	任何技能，但必须充分了解业务职能。 任何技能，但必须充分了解数据的含义及其业务规则。 任何技能，但必须能够确定数据质量问题的最佳解决方法。	跨职能领域使用的数据准确无误。 利益相关方了解数据。 数据使用符合使用政策。

基于数据域的使用者团队

在数据网格中，使用数据产品的人员通常是数据产品域外部的数据用户。这些数据使用者使用集中式数据清单查找与其需求相关的数据产品。由于有可能多个数据产品满足需求，因此数据使用者最终可以订阅多个数据产品。

如果数据使用者找不到其使用场景所需的数据产品，则有责任直接咨询数据网格 COE。在咨询期间，数据使用者可以提高其数据需求，并寻求有关如何通过一个或多个域满足这些需求的建议。

寻找数据产品时，数据使用者会查找有助于其实现各种使用场景的数据，例如永久性分析信息中心和报告、各个性能报告以及其他业务性能指标。或者，数据使用者可能会寻找可用于人工智能 (AI) 和机器学习 (ML) 使用场景的数据产品。为了实现这些使用场景，数据使用者需要混合使用数据从业者角色，如下所示：

角色	职责	所需技能	预期的结果
数据分析师	搜索、识别、评估和订阅单域或跨域数据产品，以便为商业智能框架运行建立基础。	分析工程 业务分析	提供干净、精选的汇总数据集，供数据可视化专家使用。 创建有关如何使用数据产品的最佳实践。 汇总和精选跨域数据集来满足其域的分析需求。
应用开发者	开发应用框架，以便使用一个或多个数据产品中的数据，无论是在域内部还是在域外部。	应用开发 数据工程	创建、提供和维护使用一个或多个数据产品中的数据的应用。 创建数据应用以供最终用户使用。
数据可视化专家	将数据工程和数据分析术语转换为业务利益相关方可以理解的信息。 定义用于填充来自数据产品的业务报告的流程。 创建和监控描述战略性业务目标的报告。 与组织内的工程师协作，设计从所用数据产品中汇总的数据集。 实施报告解决方案。 将高级业务需求转换为技术需求。	需求分析 数据可视化	向最终用户提供有效、准确的数据集和报告。 通过开发的信息中心和报告满足了业务需求。
数据科学家	搜索、识别、评估和订阅适合数据科学使用场景的数据产品。 从多个数据域中提取数据产品和元数据。 训练预测模型并部署这些模型以优化域业务流程。 提供有关多个数据域可能的数据精选和数据注解方法的反馈。	机器学习工程 分析工程	创建预测模型和规范模型来优化业务流程。 及时完成模型训练和模型部署。

中央数据治理团队

数据治理团队使数据提供方和使用者能够以自助方式安全地共享、汇总和计算数据，而不会给组织带来合规性风险。

为了满足组织的合规性要求，数据治理团队混合使用数据从业者角色，如下所示：

角色	职责	所需技能	预期的结果
数据治理专家	提供监督并协调单一合规性视图。 建议网格范围内有关数据收集、数据保护和数据保留的隐私权政策。 确保数据管理员了解政策并可以访问这些政策。 根据需要告知并咨询最新的数据隐私权法规。 根据需要告知并咨询安全问题。 执行内部审核，并定期分享有关风险和控制方案的报告。	法律 SME 安全 SME 数据隐私权 SME	政策中的隐私权法规是最新的。 数据提供方会及时收到政策更改通知。 管理团队会及时、定期收到有关所有已发布数据产品的政策合规性的报告。
数据管理员（位于每个域内）	将数据治理专家创建的政策标准化。 定义和更新分类，以便组织使用发现和隐私权相关的元数据对数据产品、数据资源和数据特性进行注解。 在利益相关方各自域的内部和外部之间协调。 确保其域中的数据产品符合组织的元数据标准和隐私权政策。 向数据治理工程师提供有关如何设计数据平台功能并确定其优先级的指导。	数据架构 数据监管	为域中的所有数据产品创建了必需的元数据，并准确描述了该域的数据产品。 自助式数据基础架构平台团队构建了合适的工具来自动进行数据产品的元数据注解、政策创建和验证。
数据治理工程师	开发可自动生成数据注解且可供所有数据域使用的工具，然后使用这些注解强制执行政策。 实现监控功能，以便在发现问题时检查注解和提醒的一致性。 通过实现提醒、报告和信息中心，确保组织中的员工了解数据产品的状态。	软件工程	自动验证了数据治理注解。 数据产品遵循数据治理政策。 及时检测到数据产品违规。

中央自助式数据基础架构平台团队

自助式数据基础架构平台团队（或者只是数据平台团队）负责创建一组数据基础架构组件。分布式数据域团队会使用这些组件来构建和部署其数据产品。数据平台团队还会推广最佳实践并引入工具和方法，有助于在采用新技术时减少分布式团队的认知负担。

平台基础架构应能够与运营工具轻松集成，以实现全球可观测性、插桩和合规性自动化。或者，该基础架构应有助于此类集成，以便为取得成功建立分布式团队。

数据平台团队具有与分布式域团队和底层基础架构团队配合使用的共担责任模型。该模型展示了平台使用者需要承担的责任，以及数据平台团队支持的平台组件。

由于数据平台本身是内部产品，因此该平台并不支持每种使用场景。相反，数据平台团队会根据优先路线图持续发布新服务和功能。

数据平台团队可能拥有一组已提供和开发中的标准组件。但是，如果团队的需求与数据平台提供的组件不一致，则数据域团队可能会选择其他一组唯一的组件。如果数据域团队选择不同的方法，他们必须确保所构建和维护的任何平台基础架构都遵循组织范围有关安全性和数据治理的政策和安全措施。对于在中央数据平台团队之外开发的数据平台基础架构，数据平台团队可能会选择共同投资或让其自己的工程师加入域团队。数据平台团队选择共同投资还是让工程师加入取决于数据域平台基础架构对组织的战略重要性。通过参与数据域团队的基础架构开发，组织可以提供重新打包开发中的任何新平台基础架构组件以供将来重复使用所需的协调和技术专业知识。

如果您的初始目标是获得利益相关方的批准以扩容数据网格，则可能需要在构建数据网格的早期阶段限制自主性。但是，限制自主性风险会在中央数据平台团队中造成瓶颈。此瓶颈可能会阻止数据网格扩缩。因此，任何集中式决策都应谨慎考虑。对于数据提供方，从数量有限的一组可用方案进行技术选择可能比从数量无限的一组方案本身进行评估和选择更可取。提升数据提供方自主性并不等同于打造不受控制的技术环境。相反，目标是在自由选择和标准化之间实现适当的平衡，从而提高合规性并和平台采用率。

最后，一个出色的数据平台团队是公司其余员工的核心教育来源和最佳实践。我们建议中央数据平台团队开展的一些最具影响力的活动如下所示：

• 推动对新职能项目进行定期架构设计审核，并提出跨开发团队的常见开发方法。
• 分享知识和经验，并共同定义最佳实践和架构准则。
• 确保工程师使用适当的工具来验证和检查是否存在代码问题、bug 和性能下降等常见误区。
• 组织内部黑客马拉松，使开发团队能够满足其内部工具需求。

中央数据平台团队的示例角色和责任可能包括：

职务	需求管理代表的职责	所需技能	预期的结果
数据平台产品所有者	创建数据基础架构和解决方案生态系统，以助力分布式团队构建数据产品。降低技术门槛，确保嵌入了治理功能，并最大限度地减少有关数据基础架构的共同技术债务。 与领导层、数据域所有者、数据治理团队和技术平台所有者沟通，为数据平台制定策略和路线图。	数据策略和运营 产品管理 利益相关方管理	建立成功的数据产品生态系统。 生产环境中有可靠数量的数据产品。 缩短了最低要求的可行产品的创建时间和数据产品版本的生产时间。 已提供的通用基础架构和组件的组合可满足数据提供方和数据使用者的最常见需求。 数据提供方和数据使用者的满意度分数较高。
数据平台工程师	通过模板、可部署的架构蓝图、开发者指南和其他文档创建可重复使用的自助式数据基础架构和解决方案，以用于数据注入、存储、处理和使用。此外，创建 Terraform 模板、数据流水线模板、容器模板和编排工具。 开发并维护中央数据服务和框架，以便通过嵌入的安全措施、安全和合规性报告以及 FinOps 报告使针对跨职能问题的流程标准化，例如数据共享、流水线编排、日志记录和监控、数据治理、持续集成和持续部署 (CI/CD)。	数据工程 软件工程	标准化且可重复使用的基础架构组件和解决方案可供数据提供方进行数据注入、存储、处理、精选和共享以及必要的文档说明。 组件、解决方案和最终用户文档的版本与路线图保持一致。 用户报告客户满意度较高。 数据网格中的所有职能都拥有强大的共享服务。 共享服务的正常运行时间较长。 支持响应时间较短。
平台和安全工程师（网络和安全等中央 IT 团队中加入数据平台团队的代表）	确保数据平台抽象与企业范围的技术框架和决策保持一致。 通过在核心团队中构建数据平台交付所需的技术解决方案和服务，为工程活动提供支持。	基础架构工程 软件工程	为数据平台开发了平台基础架构组件。 组件、解决方案和最终用户文档的版本与路线图保持一致。 中央数据平台工程师报告客户满意度较高。 基础架构平台的健康状况对于数据平台使用的组件（例如，日志记录）得到改善。 底层技术组件的正常运行时间较长。 当数据平台工程师遇到问题时，支持响应时间较短。
企业架构师	使数据网格和数据平台架构与企业范围的技术和数据策略保持一致。 为数据平台和数据产品架构提供咨询和设计授权与保证，以确保与企业级策略和最佳实践保持一致。	数据架构 解决方案迭代和问题解决 共识构建	构建了成功的生态系统，其中包含可靠数量的数据产品，这些产品可以缩短创建最低要求的可行产品以及将产品发布到生产环境的时间。 为关键的数据历程制定了架构标准，例如为元数据管理和数据共享架构制定通用标准。

数据网格的其他注意事项

有多个架构方案可用于分析数据平台，每个方案的前提条件不同。如需启用每个数据网格架构，我们建议您的组织遵循本部分中介绍的最佳实践。

获取平台资金

如“如果要从财务开始转型”这篇博文中所述，平台从未完成：它始终根据优先路线图运行。因此，平台必须以产品形式而不是以具有固定端点的项目形式计费。

数据网格的第一个使用者承担费用。通常，费用在构成第一个数据域来启动数据网格的企业与中央技术团队之间分摊，而中央技术团队通常包括中央数据平台团队。

为了说服财务团队为中央平台批准资金，我们建议您针对集中式平台随时间实现的价值提出业务场景。该价值来自重新实现各个交付团队中的相同组件。

为数据网格定义最低要求的可行平台

为了帮助您为数据网格定义最低要求的可行平台，我们建议您测试并迭代一个或多个业务场景。在测试时，请找到所需的使用场景，以及使用者可以采用生成的数据产品的情况。这些使用场景应该有资金来开发数据产品，但应该需要技术团队的反馈。

确保实施测试的团队了解数据网格运营模型，如下所示：

• 企业（即数据提供者团队）负责积压、支持和维护。
• 中央团队定义自助模式，帮助企业构建数据产品，但将数据产品传递给企业以在其完成后运行和拥有。
• 主要目标是证明业务运营模型（域提供、域使用）。次要目标是证明技术运营模型（中央团队开发的自助模式）。
• 由于平台团队资源有限，因此请使用主干团队和分支团队模型来积累知识，但仍允许开发专用平台服务和产品。

此外，我们还建议您执行以下操作：

• 规划路线图，而不是让服务和功能自然发展。
• 定义在注入、存储、处理、分析和机器学习方面所需的最低要求的可行平台功能。
• 在每个步骤中嵌入数据治理功能，而不是作为单独的工作流。
• 实施治理、平台、价值流和变更管理所需的最低要求的功能。最低要求的功能可满足 80% 的业务场景。

规划数据网格与现有数据平台的共存

许多希望实现数据网格的组织可能已有数据平台，例如数据湖、数据仓库或两者的组合。在实现数据网格之前，这些组织必须针对其现有数据平台如何随数据网格的发展而变化来制定计划。

这些组织应考虑以下因素：

• 在数据网格中最有效的数据资源。
• 必须保留在现有数据平台中的资产。
• 资产是否必须迁移，或者资产是否可以保留在现有平台上并仍参与数据网格。

后续步骤

• 如需详细了解如何设计和运营云拓扑，请参阅 Google Cloud 架构框架。
• 如需查看更多参考架构、图表和最佳做法，请浏览云架构中心。