你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

什么是数据产品?

每个应用程序都会临时或永久地创建和存储数据。 许多应用程序也会创建和保存数据来进行操作管理,例如错误记录和运行状况监视。 为了使用和处理这些应用程序生成的数据,集中式数据团队使用提取、转换和加载(ETL)过程。 应用程序操作团队通常具有其他数据处理流,例如应用程序运行状况数据和 KPI 状态监视数据。

对于数据集成,传统的瀑布式方法使团队遵循特定阶段顺序并不理想。 这可能会导致知识差距、所有权问题和通信冲突,这些冲突会影响用户的数据质量、时间线和价值。 应用程序团队对应用程序的性能和成功负责。 当他们使用瀑布方法时,他们会对其他团队拥有的下游流程进行更改。 有时,这些更改可能会影响其他区域。 例如,次要上游更改可能会大幅改变 KPI 的趋势。 这些冲突可能会影响你做出关键决策的能力。

作为产品的数据

为了防止这些问题,数据网格方法采用数据作为产品的概念。 应用程序所有者和应用程序团队会将数据视为他们负责的完全包含的产品,而不是另一个团队流程的副产品。 应用程序和分析数据服务任务都在域责任领域。

数据产品是专门为分析使用而创建的。 他们定义并商定了形状、使用接口、维护和更新周期,所有这些都记录在案。

数据产品是通过服务级别目标中的接口与下游进程共享的域数据资产或数据集。 除非另有要求,否则,在使原始数据可供使用之前,应处理、调整、清理、聚合和规范化原始数据,以满足商定的质量标准。

以下部分概述了良好数据产品的常见特征。

数据产品特征

确保数据产品为:

  • 可发现、可理解且可信。 为了提供可发现性和清晰度,请共享和更新有关每个数据产品、其数据的含义、数据的形状格式以及刷新周期的信息。 及时向下游使用者传达数据更改或形状更改。 为了确保可信度,接口为数据产品形状提供时间限制的向后兼容性。

  • 可寻址、可本机访问和安全。 若要提供可寻址性,请创建定义的进程来查找和获取对每个数据产品的访问权限。 针对各种访问要求实施安全措施。 将数据域所有权心态从守门数据转移到使用明确定义的安全预防措施提供数据。 记录良好的访问接口可能因不同的技术而异。 本机访问数据产品的常用接口包括 API、数据库用户、表或视图,以及具有必要访问权限的文件。

  • 可互操作、真实且有价值的操作。 若要提供互操作性,请确保数据遵循定义的常见标准,例如具有相同名称和数据类型的值。 例如,可以命名一个列,其中包含每个数据产品中的客户标识数据 CustomerID ,其数据可能始终为整数。 数据产品为客户提供价值,你可以将其用作同一域中或不同域中新数据产品的上游源。 但是,你不能仅仅在多个位置携带和复制相同的数据产品。 来自之前数据产品的每个数据产品都应为下游使用者提供新的价值和信息。 数据产品还必须提供真实、准确的数据。

使用设计良好、维护良好的数据产品及其接口来帮助避免复制数据并创建本机单一事实来源。

数据产品设计建议

为了满足数据产品服务要求,领域团队必须掌握一套新技能并使用新的工具和平台。

若要构建数据应用程序并生成或提供数据产品,请完全装备域应用程序团队。 你的团队可以使用熟悉的技术堆栈来生成数据产品。 他们可能还希望有自己的 Spark 实例或管道引擎。 例如,为许多数据产品提供服务的大型域可能会处理数据产品,并从其自己的 Azure Synapse Analytics 实例提供数据产品。 小型组织和大型组织的较小域可以在共享平台上开发和运行其数据应用程序,例如集中Azure 数据工厂、Azure Synapse Analytics 或 Azure Databricks 实例。

确保数据产品具有本文中所述的常见特征、世系存储库反映数据应用程序世系以及治理实现和访问。

下图显示了域和登陆区域中的示例数据应用程序逻辑布局。

显示域和登陆区域中可能的数据应用程序逻辑布局的关系图。

Azure 的数据产品和数据应用程序指南

如果域应用程序团队使用共享平台和共享服务集,则可以在 Azure 数据登陆区域中定位数据应用程序环境的方法。

此图显示了数据应用程序上下文中的数据-application-rg 资源组和 Core Services 上下文中的 shared-application-rg 资源组。

有关 Azure 数据登陆区域的数据应用程序模式模板,请参阅 示例数据应用程序

下一步