数据可观测性

数据可观测性是通过跨数据、存储、计算和处理管道等区域收集和关联事件，来了解数据和数据系统的运行状况的能力。

要构建和运营可复原、可缩放且高性能的数据平台，需要跨代表职能领域的团队，采用已证实的由 DevOps 启发的流程。 数据可观测性使企业所有者、DevOps 工程师、数据架构师、数据工程师和站点可靠性工程师能够自动执行问题检测、预测和预防，并避免可能破坏生产分析和 AI 的故障时间。

数据可观测性的关键方面

大多数数据平台在数据可观测性的下列关键方面进行操作：

• 数据平台服务监视
• 数据管道性能监视
• 数据质量监视
• 数据世系
• 数据发现

端到端数据可观测性不仅涉及捕获事件和测量所有这些组件中的指标，还涉及到将这些事件和指标进行关联。 这提供了企业数据环境的运行状况和可靠性的综合视图。

本文介绍每个组成部分及其如何有助于实现数据可观测性。

数据平台服务监视

为了实现存储和计算，企业数据平台的基本基础结构可同时包括提供商管理的基础结构和自管理基础结构。 DevOps 工程师或基础结构工程师需要监视该基本基础结构，以便识别和解决影响新式数据和分析管道的系统中断问题和性能瓶颈。

监视数据库和网络层中的数据可以提高处理吞吐量，并最大程度地降低网络延迟。 团队需要工具能够用来捕获指标、进行通知、跟踪和修正事件，并与数据和分析问题关联。

我们建议团队将可观测性即代码纳入基础结构即代码层，以便在创建资源后立即启用监视检测。 大多数 Azure 服务为关键资源指标（如诊断数据）提供现成的检测。

数据管道性能监视

数据管道包含多个阶段和依赖项，变得日益复杂，现在会生成大量的监视数据。 此数据包括事件、指标和日志。 你可收集和分析监视数据来优化数据管道性能。

数据团队应跨多个相关数据产品和业务领域跟踪数据管道的状态。 当团队提前收到比预期时间更长的故障或运行时的通知时，他们可最大程度地减少和修正故障时间。 管道监视数据和平台服务监视的相关性可以提供性能优化的建议，例如提升高负载管道的 CPU 和内存。

数据质量监视

数据质量是数据准确、完整、及时和符合组织要求的程度。 你需要不断监视数据集的质量，确保其支持的数据应用程序始终可靠、可信。 DataOps 通过自动执行数据质量测试（单元、功能和集成），一直在不断提高数据的可靠性和性能。 这些改进可使故障检测和数据分析更快、更高效。

要在数据质量中采用 DevOps 和 SRE 原则，团队必须构建可重复的迭代流程和框架，来捕捉数据质量问题、跟踪仪表板中的问题，并针对任何偏差设置警报。

可通过数据质量监视来跟踪检测时间 (TTD)、恢复时间 (TTR) 和其他数据质量指标。 TTD 是指数据团队检测任何类型的数据质量问题所花费的时长，范围涵盖从新鲜度异常到破坏整个管道的架构更改。 TTR 是指团队在发出警报后解决数据事件所花费的时长。 提高数据质量不仅是技术挑战，还涉及到重要的组织和文化支持。

数据质量的“治理”部分探讨了如何在方案中实现数据质量。

数据世系

数据世系被广泛理解为一个连续记录，记录了整个数据资产中数据的来源、转换和随时间的移动。 数据世系用于追溯任务，包括排查、调试管道问题和跟踪这些问题的根本原因。 世系还用于数据质量分析、合规性和“what if”场景，这些通常称为“影响分析”。

世系以可视化的方式表示，显示从源到目标的数据移动，包括数据随时间的转换情况。

数据世系的“治理”部分探讨了如何在方案中实现数据世系。

数据发现

对使用者来说，数据发现是数据分析或数据管理工作负载的第一步。 在企业数据湖平台中，数据使用者（例如数据科学家和分析师）很难找到他们需要的数据并评估其可靠性。 借助提供以下信息的数据索引，使用准确的元数据的数据目录让搜索变得更简单：

• 可用数据的位置
• 数据质量检测
• 数据结构理解
• 数据世系理解
• 访问所需数据

提供这些搜索功能的数据目录可提高所有数据发现过程的速度。

数据目录的“治理”部分探讨了如何在方案中实现数据发现。

SLA、SLA 和 SLO

组织的团队可采用 DevOps 样式的站点可靠性工程 (SRE) 做法来监视数据。 服务级别协议 (SLA)、服务级别指示器 (SLI) 和服务级别目标 (SLO) 可帮助组织减少故障时间，并确保数据的可靠性。

服务级别协议 (SLA)

SLA 需要定义完善的 SLI 和商定的 SLO，其中 SLI 是服务质量的量化度量值，SLO 是每个 SLI 应满足的理想值或范围。

要设置数据 SLA，所有将受到 SLA 影响的利益干系人都需要积极参与和协作。 这些利益干系人可以包括数据生成者、数据工程师、数据分析师、数据使用者、业务分析师等等。

设置可靠性 SLA 通常涉及到 3 个步骤：定义、度量和跟踪。

设置 SLA 从定义可靠性的含义开始。 所有关键利益干系人必须就此定义达成一致。 确保每个关键利益干系人都参与进来，尤其是在下游使用者来自不同的团队或不同的地理区域和时区时。

SLA 需要精心设计。 如果数据使用者是外部付费客户，请让法律团队参与进来。 对于内部客户，SLA 定义应包括数据承诺、数据质量和数据事件处理流程（如果未满足承诺）等方面。

示例 SLA

假设 Contoso 是一家媒体公司，它运行一个企业数据湖，此数据湖支持跨不同业务领域的多个数据产品。 Contoso 的数据应用团队负责交付前一天的销售数据，为 Contoso 的销售仪表板提供支持。 当他们错过数据交付或交付不完整的数据时，数据工程团队将收到来自不满的高管的电子邮件，并且不得不手动会审应交付销售数据的已中断的管道。 为了衡量和改进其可交付结果，数据团队与销售团队一起设置了一个 SLA，如以下部分所示。

服务级别协议 - 数据团队到销售团队

协议	说明
业务领域	数据团队承诺赋予销售团队做出数据驱动决策的能力
Promise	数据团队承诺交付前一天的销售数据来支持销售仪表板。 此数据可以为所有美国区域提供销售和转化率。 数据管道将在 6:00 UTC 之前提供数据来支持销售仪表板
数据质量	Null 检查：客户名称不能为 null。 缺失值：客户区域不能缺失。 新鲜度：销售日期应包括 24:00 UTC 之前的所有交易
数据事件管理	如果未满足上述数据交付承诺，销售团队可以报告问题，数据团队承诺将在 TTR < 6 小时内解决问题

服务级别指标 (SLI)

SLI 应始终满足或超过 SLA 中概述的 SLO。 设置 SLI 时，首先定义可跟踪和度量的关键指标，以实现商定的 SLA。

SLI 示例

假设 Contoso 的数据团队识别来自不同方面的关键指标，以满足上一示例中概述的 SLA。 他们还生成仪表板，设置关键指标是否偏离设定基线的警报，并自动执行操作来缓解某些问题。

指标	目的
Spark 群集 CPU 和内存使用情况	测量用于运行数据管道的基本基础结构中的任何性能瓶颈
管道总运行时（分钟）	测量管道花费的时间是否超过预期运行时间
管道失败和成功率	度量管道的失败或成功次数
数据质量指标（下游）	确保数据管道交付的数据符合预期
数据质量指标（上游）	确保符合原始数据质量的上游准则
转换元数据更新	确保从上游到下游的世系包含有关应用于数据的所有转换的元数据
下游数据索引和更新	确保销售团队发现为其仪表板提供支持的所有数据集
用于测量 TTD 和 TTR 的已定义过程	测量 TTD 和 TTR 并确保 TTR < 6 小时

服务级别目标 (SLO)

SLO 由 SLI、测量 SLI 的持续时间以及实际可实现的目标成功率组成。 一开始，定义方向和目标成功可能是一项艰巨的任务。 不要期望完美，而是要在多次迭代中稳步改进。

SLA 可以依赖于：

• 数据产品
• 数据类别
• 数据源区域
• 数据可观测性组件

SLO 示例

假设 Contoso 的数据团队跨 7 个不同的美国区域交付销售数据。 所有区域每年交付 210 个数据集，其中只有 200 个数据集是完整的并满足 SLA。 这些成功的交付意味着该年的成功率为 95.99%。 有 10 个失败的（不完整）数据集，错误率为 4%，这是可接受的。

数据团队创建一个监视仪表板来跟踪聚合的 SLI，从而在 30 天内监视此 SLO。 在未达到目标成功率时，数据团队和销售团队都会收到通知。

数据可观察性成熟度模型

数据可观测性是 DataOps 框架的重要组成部分，在努力改进组织的 DataOps 流程时也应考虑可观测性。 成熟度模型可帮助你评估数据可观测性的当前状态，并决定你的历程的后续步骤。

阶段	数据平台服务监视	数据管道性能监视	数据质量监视	数据世系	数据发现
阶段 5（超高级）	通过统一视图中的一个或多个数据产品中的所有数据可观察性组件收集数据，并使用机器学习关联数据以发现任何异常。 仪表板跨所有数据可观测性组件跟踪 SLO、SLI 和 SLA。	跨多个数据产品跟踪数据管道性能指标。 根本原因分析由系统完成并驱动。	建立对数据质量的高度信任。 数据使用者可以验证数据的可靠性。	数据世系以可视化的方式表示，并按多种方式使用，例如跟踪管道故障的根本原因、数据质量分析和合规性。	数据使用者可以轻松找到所需的可用数据。
阶段 4（高级）	仪表板跨最关键的数据可观测性组件跟踪 SLO、SLI 和 SLA。 利用自动化技术将平台监视数据与管道性能监视数据进行关联。	数据事件工具监视和度量任何事件的 TTD 和 TTR 指标。	数据质量通过可用于多个数据产品的框架进行维护，并使用仪表板进行跟踪。	数据世系包括数据质量标记，并连接到数据可发现性。	数据世系现在已连接到数据可发现性，并包括数据质量标记。
阶段 3（发展）	定义完善的 SLO、SLI 和 SLA 涵盖了数据可观测性几乎所有最关键的组件。 数据事件使用专用工具进行管理。	使用某种程度的自动化技术将平台监视数据与数据管道性能监视相关联。	数据质量检查定义良好，并映射到自定义指标。	数据世系已成熟，包含决策制定所需的足够多的元数据。	使用专用数据目录工具实现数据可发现性。
第 2 阶段（规划）	SLO、SLI 和 SLA 的初始草稿涵盖了数据可观测性所需的最关键组件。 平台监视数据集中，并且整个数据环境有统一的视图。 所有数据事件管理都是手动的。	会定义和度量数据管道性能指标。	有数据质量检查，但未定义、测量和可视化标准指标。	数据世系仅限于单个数据产品，或者没有被跟踪。	实现了数据可发现性，但没有使用复杂的工具。
阶段 1（学习）	每个关键平台服务（提供商托管和自管理）都在数据环境中受到监视。	管道监视最少。 故障会触发警报，但没有关于任何可能的原因的见解。	可以从管道运行数据质量测试，但不会测量或跟踪任何指标。	数据世系不存在。	数据可发现性不存在。