你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
数据协定
职责分布在联合体系结构中 域 之间，这可能导致难以监视依赖项并获取数据使用情况见解。 数据协定有助于获取数据使用情况见解，因为它们提供了有关拥有每个数据产品的人员的信息。 数据协定有助于设置标准，自信地管理数据管道。 它们对于可靠的数据管理至关重要，提供有关以下方面的信息：
- 正在使用哪些数据产品。
- 哪些用户正在使用什么数据产品。
- 是什么用途导致用户使用特定的数据产品。
数据产品分发和使用情况有两个维度：技术问题和业务问题。 技术问题包括数据管道处理和相互数据稳定性预期。 业务问题涵盖数据共享目的协议，该协议定义了使用、隐私和用途，包括任何限制。
这两个维度涉及不同角色。 通常，应该依赖应用程序所有者或数据工程师来关注技术问题，而产品所有者或业务代表则表示业务关注。
数据协定原则
数据协定类似于服务协定或数据交付协定。
在较大的或分布式体系结构中，难以监督更改。 只要数据产品广受欢迎且广泛使用，就可以通过实施版本控制和管理兼容性来简化监督。
如果应用程序耦合，则表示耦合应用程序之间高度相互依赖。 访问或使用其他应用程序数据的应用程序在耦合时总是会受到影响。 例如，对数据结构的任何更改都可能直接影响访问或使用该数据的其他应用程序。 在将许多应用程序耦合在一起的情况下，通常会遇到级联效应，其中对单个应用程序进行少量更改会影响许多其他应用程序。 即使是轻微更改也会增加意外影响的可能性，因此许多架构师和软件工程师避免生成耦合体系结构。
数据协定保证接口兼容性并包括服务条款和服务级别协议 (SLA)。 服务条款概述了如何使用数据，例如将数据的使用限制为仅用于开发、测试或生产。 SLA 介绍了数据交付和接口所需的质量。 可在 SLA 中指定的质量详细信息包括：
- 运行时间
- 错误率
- 可用性
- 弃用
- 路线图
- 版本号
可以将捕获这些详细信息的元数据置于源代码管理下，从而支持自动触发验证和部署。 有关源代码管理的详细信息，请参阅 Azure 数据工厂中的源代码管理。
数据协定提供了对域和应用程序之间耦合和依赖关系的见解。 协定还支持进行协定测试，用于确保所有应用程序和接口更改都根据使用者的数据要求进行验证。 可以通过检测架构偏差来判断数据流何时易受上游数据源更改的影响。 有关详细信息，请参阅映射数据流中的架构偏差。
数据协定通常是元数据驱动的引入框架的一部分。 可以将数据协定存储在集中托管的元存储内的元数据记录中。 在该中心位置，数据协定在数据引入的多个领域发挥着重要作用，包括：
- 管道执行
- 数据产品创建
- 数据类型验证
- 架构
- 互操作性标准
- 协议版本
- 缺失数据的默认规则
数据协定涉及大量技术元数据。 若要记录数据管道和数据产品，必须清楚地描述数据源、数据经历的所有转换以及最终传递数据的方式。
在分布式体系结构中，将数据管道框架分布在不同的域中，并且这些域符合常见的工作方式。 由于域自行处理数据，因此域有权控制数据并对其负责，而框架和元数据仍受中央治理。
实现联合方法时，应从小处着手。 从基本数据开始，例如用于架构验证的元数据存储、企业标识符以及对共享元数据存储库中其他数据集的引用。 添加数据世系支持，以帮助可视化数据移动。 启动您的流程并实施控制机制以验证技术数据质量。
所有控制都应是持续集成过程的一部分。 捕获所有运行时信息，包括指标和日志记录，并将此信息作为元数据基础的一部分，用于获取数据管道稳定性见解。 此设置可确保在域和中央管理考核中心之间具有反馈循环。
稳定所有数据移动时，请捕获不同数据使用者对应使用的数据属性（如表和列），并使用此信息继续缩放。 可以将此信息包含在集中托管的元存储中。 使用数据信息可以检测重大更改，并确定它们对数据生成者和使用者的影响。 如果某个数据产品数据集没有使用者，可以对其进行中断性更改。 使用源代码管理（如 Git）以允许数据提供程序和数据使用者之间的握手过程。
数据共享协议
数据共享协议是数据协定的扩展。 协议概述了数据使用情况、隐私和用途，涵盖任何限制。 数据共享协议是独立于接口的，并提供有关用于特定用途的数据的见解。 它们还充当数据安全控件的输入。 可以使用数据共享协议来概述哪些筛选器或安全保护措施必须应用于数据。
数据共享协议还有助于防止在数据使用方面产生误解。 在共享任何数据之前，域所有者应讨论数据共享和数据使用问题。 对于管理数据及其使用的能力以及确保能为组织提供价值而言，达成共识至关重要。 在所有域所有者达成协作理解后，请确保他们在数据共享协议中记录它。 在此协议中，你还可以解决以下方面的问题：
- 功能数据质量
- 历史化
- 数据生命周期管理
- 数据的进一步分发
应用分类和条件（例如敏感度标签或筛选条件）来保护数据。
上一部分的示意图显示了标记为“数据产品 sidecar”的某些元素。 数据产品 sidecar 是用于注入策略执行的组件或层，例如数据访问控制或数据消耗输出方法。 它是一种安全抽象，使用数据协定来处理域数据的安全强制实施。 可以从数据协定存储库创建数据产品 sidecar 作为访问控制列表 (ACL) 或无服务器视图，也可以使用为特定使用者选择和筛选的重复数据集创建数据产品 sidecar。 无论哪种方式，目标都是以完全自动化的方式从数据协定中派生安全视图。
连接数据协定属性和文档。 确保提供语义上下文和术语表的关系，以便使用者能够了解业务要求如何转换为实际实现。 如果与业务术语的关系对组织很重要，请考虑实现策略，例如仅在所有数据产品属性都链接到业务术语实体后才能建立数据协定。 还可以将此类策略应用于上下文更改，例如关系或定义调整。
使用数据协定
缓慢开始使用数据协定。 请勿同时引入太多更改；数据协定需要文化转变，用户需要时间来熟悉它们并了解数据所有权的重要性。 还需要在数据协定中查找过少和过多元数据属性之间的最佳平衡点。
以下步骤概述了为组织实施数据协定的过程：
- 确保技术数据管道稳定。 如果用例经过的管道遇到意外中断，用例就无法投入生产。
- 开始使用共享协议时，请制定简单实用的流程。 在 Microsoft Forms 中设计简单的表单或模板，以此开始。 用读者容易理解的清晰、简洁的语言进行编写。 第一阶段的重点是文化转变和收集要求。 确保不会把事情复杂化；接受手动流程，限制初始元数据要求，并循环访问直到这些要求处于稳定状态。
- 在确定第一个流程后，开始将手动表单替换为基于 Web 的应用程序、数据库和/或消息队列。 在此阶段，中央数据治理团队仍应负责监督。 此时的数据访问粒度通常是粗粒度的，侧重于文件夹或文件。 尽可能使用 REST API 来自动配置数据访问策略或 ACL。
- 让数据所有者或数据专员负责强大的审批管理工作流。 中央数据管理角色现在应该仅监督来自次要角色的审批，并定期审阅所有数据协定。 此时，应有一个像 Microsoft Purview 这样的数据目录启动并运行，其中显示了所有可供使用的数据产品。 通过支持细粒度选择和筛选来提升数据和安全强制实施功能，并考虑使用动态数据掩码等技术来防止数据被复制。
- 在数据协定实现旅程的最后阶段，一切都应是自助服务和完全自动化的。 自动化机器学习应该预测数据审批。 例如，安全视图会在审批后自动进行部署。
数据协定是数据网格体系结构相对较新但重要的补充，为数据使用和依赖关系提供透明度。 首先，在开始使用数据协定时，请关注技术稳定性和标准化，然后在循环访问时使用经验与教训流程。 慢慢生成和自动化数据治理，这样就不会增加组织的开销。
作为数据合同文档的一部分，还需要服务条款和服务级别协议（SLA）。 使用 SLA 概述数据传送和接口的质量要求，包括运行时间、错误率和可用性。 SLA 还可以包括需要定义的任何弃用、路线图和版本号要求。