数据网格是一种架构和组织框架,它将数据视为产品(在本文档中称为“数据产品”)。在此框架中,数据产品由最了解数据并遵循组织范围的一组数据治理标准的团队开发。将数据产品部署到数据网格后,组织中的分布式团队可以更快速、高效地发现和访问与其需求相关的数据。为了实现此类运行状态良好的数据网格,您必须先确立本文档介绍的概要架构组件和组织角色。
本文档是系列文章中的一篇,该系列介绍了如何在 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 也是负责解决任何其他职能引起的任何冲突的指定仲裁团队。此职能对于关联其他四个职能非常有用。
基于数据域的提供方团队
通常,数据产品是在数据物理存储库(单个或多个数据仓库、数据湖或数据流)的基础之上构建的。组织需要传统的数据平台角色来创建和维护这些物理存储库。但是,这些传统的数据平台角色通常不是创建数据产品的人员。
如需通过这些物理存储库创建数据产品,组织需要混合使用数据从业者角色,例如数据工程师和数据架构师。下表列出了数据提供方团队所需的域专用的所有用户角色。
角色 |
职责 |
所需技能 |
预期的结果 |
---|---|---|---|
数据产品所有者 |
|
数据分析 数据架构 产品管理 |
|
数据产品技术主管 |
|
数据工程 数据架构 软件工程 |
|
数据产品支持 |
|
软件工程 站点可靠性工程 (SRE) |
|
数据域的主题专家 (SME) |
|
数据分析 数据架构 |
|
数据所有者 |
|
|
|
基于数据域的使用者团队
在数据网格中,使用数据产品的人员通常是数据产品域外部的数据用户。这些数据使用者使用集中式数据清单查找与其需求相关的数据产品。由于有可能多个数据产品满足需求,因此数据使用者最终可以订阅多个数据产品。
如果数据使用者找不到其使用场景所需的数据产品,则有责任直接咨询数据网格 COE。在咨询期间,数据使用者可以提高其数据需求,并寻求有关如何通过一个或多个域满足这些需求的建议。
寻找数据产品时,数据使用者会查找有助于其实现各种使用场景的数据,例如永久性分析信息中心和报告、各个性能报告以及其他业务性能指标。或者,数据使用者可能会寻找可用于人工智能 (AI) 和机器学习 (ML) 使用场景的数据产品。为了实现这些使用场景,数据使用者需要混合使用数据从业者角色,如下所示:
角色 |
职责 |
所需技能 |
预期的结果 |
---|---|---|---|
数据分析师 |
搜索、识别、评估和订阅单域或跨域数据产品,以便为商业智能框架运行建立基础。 |
分析工程 业务分析 |
|
应用开发者 |
开发应用框架,以便使用一个或多个数据产品中的数据,无论是在域内部还是在域外部。 |
应用开发 数据工程 |
|
数据可视化专家 |
|
需求分析 数据可视化 |
|
数据科学家 |
|
机器学习工程 分析工程 |
|
中央数据治理团队
数据治理团队使数据提供方和使用者能够以自助方式安全地共享、汇总和计算数据,而不会给组织带来合规性风险。
为了满足组织的合规性要求,数据治理团队混合使用数据从业者角色,如下所示:
角色 |
职责 |
所需技能 |
预期的结果 |
---|---|---|---|
数据治理专家 |
|
法律 SME 安全 SME 数据隐私权 SME |
|
数据管理员(位于每个域内) |
|
数据架构 数据监管 |
|
数据治理工程师 |
|
软件工程 |
|
中央自助式数据基础架构平台团队
自助式数据基础架构平台团队(或者只是数据平台团队)负责创建一组数据基础架构组件。分布式数据域团队会使用这些组件来构建和部署其数据产品。数据平台团队还会推广最佳实践并引入工具和方法,有助于在采用新技术时减少分布式团队的认知负担。
平台基础架构应能够与运营工具轻松集成,以实现全球可观测性、插桩和合规性自动化。或者,该基础架构应有助于此类集成,以便为取得成功建立分布式团队。
数据平台团队具有与分布式域团队和底层基础架构团队配合使用的共担责任模型。该模型展示了平台使用者需要承担的责任,以及数据平台团队支持的平台组件。
由于数据平台本身是内部产品,因此该平台并不支持每种使用场景。相反,数据平台团队会根据优先路线图持续发布新服务和功能。
数据平台团队可能拥有一组已提供和开发中的标准组件。但是,如果团队的需求与数据平台提供的组件不一致,则数据域团队可能会选择其他一组唯一的组件。如果数据域团队选择不同的方法,他们必须确保所构建和维护的任何平台基础架构都遵循组织范围有关安全性和数据治理的政策和安全措施。对于在中央数据平台团队之外开发的数据平台基础架构,数据平台团队可能会选择共同投资或让其自己的工程师加入域团队。数据平台团队选择共同投资还是让工程师加入取决于数据域平台基础架构对组织的战略重要性。通过参与数据域团队的基础架构开发,组织可以提供重新打包开发中的任何新平台基础架构组件以供将来重复使用所需的协调和技术专业知识。
如果您的初始目标是获得利益相关方的批准以扩容数据网格,则可能需要在构建数据网格的早期阶段限制自主性。但是,限制自主性风险会在中央数据平台团队中造成瓶颈。此瓶颈可能会阻止数据网格扩缩。因此,任何集中式决策都应谨慎考虑。对于数据提供方,从数量有限的一组可用方案进行技术选择可能比从数量无限的一组方案本身进行评估和选择更可取。提升数据提供方自主性并不等同于打造不受控制的技术环境。相反,目标是在自由选择和标准化之间实现适当的平衡,从而提高合规性并和平台采用率。
最后,一个出色的数据平台团队是公司其余员工的核心教育来源和最佳实践。我们建议中央数据平台团队开展的一些最具影响力的活动如下所示:
- 推动对新职能项目进行定期架构设计审核,并提出跨开发团队的常见开发方法。
- 分享知识和经验,并共同定义最佳实践和架构准则。
- 确保工程师使用适当的工具来验证和检查是否存在代码问题、bug 和性能下降等常见误区。
- 组织内部黑客马拉松,使开发团队能够满足其内部工具需求。
中央数据平台团队的示例角色和责任可能包括:
职务 | 需求管理代表的职责 | 所需技能 |
预期的结果 |
---|---|---|---|
数据平台产品所有者 |
|
数据策略和运营 产品管理 利益相关方管理 |
|
数据平台工程师 |
|
数据工程 软件工程 |
|
平台和安全工程师(网络和安全等中央 IT 团队中加入数据平台团队的代表) |
|
基础架构工程 软件工程 |
|
企业架构师 |
|
数据架构 解决方案迭代和问题解决 共识构建 |
|
数据网格的其他注意事项
有多个架构方案可用于分析数据平台,每个方案的前提条件不同。如需启用每个数据网格架构,我们建议您的组织遵循本部分中介绍的最佳实践。
获取平台资金
如“如果要从财务开始转型”这篇博文中所述,平台从未完成:它始终根据优先路线图运行。因此,平台必须以产品形式而不是以具有固定端点的项目形式计费。
数据网格的第一个使用者承担费用。通常,费用在构成第一个数据域来启动数据网格的企业与中央技术团队之间分摊,而中央技术团队通常包括中央数据平台团队。
为了说服财务团队为中央平台批准资金,我们建议您针对集中式平台随时间实现的价值提出业务场景。该价值来自重新实现各个交付团队中的相同组件。
为数据网格定义最低要求的可行平台
为了帮助您为数据网格定义最低要求的可行平台,我们建议您测试并迭代一个或多个业务场景。在测试时,请找到所需的使用场景,以及使用者可以采用生成的数据产品的情况。这些使用场景应该有资金来开发数据产品,但应该需要技术团队的反馈。
确保实施测试的团队了解数据网格运营模型,如下所示:
- 企业(即数据提供者团队)负责积压、支持和维护。
- 中央团队定义自助模式,帮助企业构建数据产品,但将数据产品传递给企业以在其完成后运行和拥有。
- 主要目标是证明业务运营模型(域提供、域使用)。次要目标是证明技术运营模型(中央团队开发的自助模式)。
- 由于平台团队资源有限,因此请使用主干团队和分支团队模型来积累知识,但仍允许开发专用平台服务和产品。
此外,我们还建议您执行以下操作:
- 规划路线图,而不是让服务和功能自然发展。
- 定义在注入、存储、处理、分析和机器学习方面所需的最低要求的可行平台功能。
- 在每个步骤中嵌入数据治理功能,而不是作为单独的工作流。
- 实施治理、平台、价值流和变更管理所需的最低要求的功能。最低要求的功能可满足 80% 的业务场景。
规划数据网格与现有数据平台的共存
许多希望实现数据网格的组织可能已有数据平台,例如数据湖、数据仓库或两者的组合。在实现数据网格之前,这些组织必须针对其现有数据平台如何随数据网格的发展而变化来制定计划。
这些组织应考虑以下因素:
- 在数据网格中最有效的数据资源。
- 必须保留在现有数据平台中的资产。
- 资产是否必须迁移,或者资产是否可以保留在现有平台上并仍参与数据网格。
后续步骤
- 如需详细了解如何设计和运营云拓扑,请参阅 Google Cloud 架构框架。
- 如需查看更多参考架构、图表和最佳做法,请浏览云架构中心。