第三章：数据可观测性在数据组织中的角色-灵析社区

在上一章中，您了解了数据可观测性的定义以及数据技术和团队如何拥抱它。在本章中，我将系统地研究数据可观测性，分析它如何融入数据组织，比如数据架构和文化。因为数据文化本身就是一个复杂的系统，所以我将分两个部分来讨论它：

通过数据组织中的数据工程角色来看待数据文化。
数据在我们经济演进中的作用（因此也是组织的作用）。

数据架构

数据架构是数据组织的关键组成部分。它为每个部门的数据如何以个别和协作的方式提供价值奠定了基础。本节的目的不是定义理想的数据架构，如果存在的话，而是回顾数据可观测性必须在组织中引入的位置，以支持可持续的数据使用管理。

不是所有的组织在数据架构方面都是平等的；有些组织已经有一个既定的架构，预计会发展或部分或完全替代，而其他组织则从白纸开始。因此，我将解释为什么在构建新架构时必须从一开始考虑数据可观测性，以及如何在现有数据架构中引入它作为附加组件，尽管它起到了中心作用。

数据可观测性在数据架构中的位置如何？

为了讨论数据可观测性在数据架构中的位置，我必须将数据可观测性分为两部分：数据可观测系统和数据可观测平台。这是为了遵循架构的一个基本原则：关注点分离。

数据可观测系统

数据可观测系统涉及数据可观测性作为数据应用程序的一个要素。回顾前几章，数据可观测性是一种能力，可以从数据应用程序内部引入，这些应用程序可以生成整个数据可观测性核心模型。因此，数据可观测性首先包含在数据架构的应用程序层中，如图3-1所示。

在这一层面必须考虑两种不同情况：当数据工具、框架和库部分地或尚未具备数据可观测性，以及当它们在本质上具备数据可观测性时。

当支持创建数据应用程序的组件并非完全具备数据可观测性时，根据工具和架构的不同，需要在一个或两个位置添加附加组件。这些位置在图3-1中用标签1和2表示。标签1位于“应用程序”上，代表了我将在第4章中讨论的引入数据可观测性能力。标签2表示工具被扩展以通过默认生成所有使用它们构建的数据应用程序的数据观测的附加构件（例如代理），我将在第5章中讨论。

然而，在未来，所有工具和库都将通过设计或本质上具备数据可观测性，这意味着默认情况下所有数据应用程序都将具备数据可观测性，因此将被视为理所当然。因此，在架构图中我没有表示这个显而易见的部分，以避免膨胀架构图并加速新架构的定义。

然而，在此期间，我必须考虑那些要么是遗留的，要么太封闭（黑盒）以至于无法让我们有机会应用第4章和第5章中介绍的实践的工具。对于这些工具，我在数据可观测系统中保留了一个位置，它一边与数据层接触，一边与数据可观测平台接触。第6章将详细介绍这个特定但暂时的情况。

数据可观测性平台

如图3-1所示，所有应用程序都是通过本地方式或适当的扩展进行数据可观测，这些扩展将在接下来的章节中介绍。数据可观测性平台是一个系统，用于汇总和观察由相互连接的数据应用程序生成的数据观测。

每个应用程序生成的数据观测都有潜力解决第1章中强调的挑战。这些挑战涉及到需要在扩展环境中检测数据问题的系统，简化识别和解决根本原因的过程，并主动预测其再次发生的可能性。通过利用数据观测的力量，我们可以开发有效解决这些挑战的解决方案，确保数据生态系统更加强大和有韧性。此外，每个应用程序很可能在强（例如，编排）或弱（例如，使用相同的数据源）依赖于其他应用程序，因此在全局数据观测的相互作用中存在巨大的潜在价值。例如，通过遵守数据可观测性核心模型，可以利用有关这些依赖关系（例如，血统）的信息来自动检测和解决数据问题。

您还需要考虑过去数据观测中存在的价值，因为可以更有效地基于过去状态来确定数据在其使用环境中的当前状态。一个简单的例子是数据摄取应用程序。摄取的数据量很可能遵循底层模式（例如，时间序列），可以从中学习，以确定当前摄取的数据量是否异常或不正常；参见“期望”。

因此，数据架构必须通过一个额外的中央组件进行扩展，即数据可观测性平台。最起码，此组件负责摄取所有数据观测，对其进行聚合，并在理想情况下从中学习以提供这些功能。图3-2更新了图3-1，其中包含了该平台以及其他中央组件。

数据可观测性平台不是孤立运行的，而应与其他平台（如编排器或应用可观测性平台）合作。推荐进行这种协作，因为正如第1章中所概述的，数据可观测性是可观测系统的一个维度。数据可观测性充当缓冲，为数据治理和所有其他数据管理领域之间提供控制和可见性。

数据可观测性还在数据（工程）团队的效率方面发挥着重要作用，我将在后面的部分进行讨论。首先，让我们看看数据架构必须确保系统具备数据可观测性以及如何引入数据可观测性平台的情况。

带有数据可观测性的数据架构

在理想的情况下，您将从一开始就引入数据可观测性。然而，在现实世界中，首先要交付平台和第一个价值。如果时间和能力允许您“不工作于直接业务价值生成”，那么监控和降低总拥有成本（TCO）可能会成为下一个优先事项。

我见过很多公司愿意进行关于数据可观测性的“概念验证”，但实际上，我们真的需要证明生成数据观测以增加对系统信息的了解是有益的吗？好吧，我理解数据可观测性平台，我的意思是工具，需要“测试”，以验证其能力是否与期望和需求相匹配。然而，是否应该使系统具有数据可观测性根本不应受到质疑。它必须被数据架构和整个组织的数据社区共同接受。因此，我建议尽早开始构建具有数据可观测性的系统，并寻找适合您特定环境的数据可观测性平台。您如何做到这一点呢？让我涵盖两个广泛的类别：新的和现有的架构。不是所有情况都完全适用于这些类别；有些情况介于两者之间。因此，了解这两个类别提供了对哪种混合可能对您最有用的情况有很好的了解。

在架构中引入数据可观测性取决于系统的具体设计和实施。对于新架构，建议选择那些已经具备数据可观测性或可以轻松变得可观测的数据技术。我还建议在架构的基础层引入数据可观测性平台，这里已经有其他解决方案，比如编排器。另一方面，对于已经存在的架构，应该不会妨碍在基础层引入数据可观测性平台，因为它可以独立运行。然而，这并不会自动使建立在架构上的系统具有数据可观测性。要实现数据可观测性，关键是将现有的数据技术转变为可观测的技术，除非它们已经是可观测的。对于继承的技术，第六章可能会提供帮助。在向架构中添加其他技术时，选择那些专门设计为原生数据可观测性的技术非常重要。这将使系统能够在其开发和运营过程中保持一致的数据可观测性水平。在任何架构的设计和实施中优先考虑数据可观测性至关重要，以确保数据可以得到有效的监控、管理和利用。

数据可观测性如何帮助应对数据工程的潜在问题

既然数据架构已经扩展，引入了数据可观测性的能力，那么在本节中，我将关注由Joe Reis和Matt Housley在《数据工程基础》（O'Reilly出版）中引入的数据工程潜在问题，我将在第五章中深入讨论。这些潜在问题通常被认为是复杂和不方便的，但在数据可观测性的基础上，它们要简单得多。让我们从安全性开始。

安全

安全性必须融入组织的文化中，这意味着它不能复杂或难以实施。尽管自动化所有安全性任务具有挑战性，但系统正在不断发展，以处理其中的许多任务。例如，在软件开发中，可以检测到存在安全问题的软件包，并且专用平台可以自动生成拉取请求。

对工程师来说，难点在于他们必须考虑尽可能多的灾难性情景，预见他们希望观察到的所有事件，并自动化预防（例如，过滤）和传播（例如，断路器）。

然而，通过将数据可观测性系统与数据可观测性平台相结合，我们可以通过自动化繁琐和耗时的任务，只留下基于知识的任务（例如，计算已屏蔽数据的百分比），从而使工程师的工作变得更加轻松。这些任务与他们产生和维护的价值直接相关。

因此，标准信息，例如与数据访问相关的观察结果，由已经存在的数据可观测系统设计提供。数据可观测性平台通过将这些观察结果与平台的安全可观测性和自动化组件相匹配，来完成其余的工作，如图3-3所示。

其他观察结果还将支持工程师处理安全性问题，这些结果来自于提供观察结果的用户和应用程序可观测性领域。为了说明这一点，让我通过一些示例来为您演示。

第一个用例是检测数据应用程序突然获取的数据比过去多50％或使用方式发生变化，尽管数据本身的大小并未发生变化。此外，可以防止数据在流程中没有应用加密步骤而被外部暴露，如图3-4所示。

工程师可以在其自定义指标显示的掩码数据百分比下降时收到通知，这可能表明数据已泄露。

另一个示例是警告指出，被标记为重要的数据没有备份，因为没有运行“备份”应用程序，该应用程序会在其他地方读取和写入这些数据，如图3-5所示。

现在我们可以支持工程师在不大幅增加他们日常工作干扰的情况下达到令人满意的安全水平，让我们着手解决一个重要而广泛的基础问题——数据管理。

数据管理

在第1章中，我提出了DMBOK2数据管理框架，可以将数据可观察性引入作为一个新领域，围绕数据治理作为控制层跨越所有其他领域（图1-13）。在本节中，我将通过数据工程基础中提出的数据治理的视角来强调这一观点。

数据治理

为了充分了解数据治理中数据可观察性的影响和价值，重要的是要研究它与数据治理监管的其他数据管理领域的交叉点。通过分析这些交叉点，我们可以深入了解数据可观察性如何对实现大规模有效数据文化的画面起到关键作用。

换句话说，要充分理解数据治理中数据可观察性的好处和重要性，有必要探讨它与数据治理监管范围内其他数据管理方面的关系。通过这样做，我们可以更全面地了解数据可观察性如何有助于成功在更大范围内实施数据驱动文化。

可发现性

数据必须在项目和领域之间进行重复使用。为此，需要在新项目范围的分析阶段中发现数据，例如。这意味着数据的特征应该被暴露给一个引擎，允许人类或另一个系统根据他们的需求进行匹配。如果不是这样，那么所有数据都需要系统地分析，以找到最适合的用途，最终需要越来越多的时间和资源。简而言之，它很快就会变得不可持续。

特征的另一个词是元数据。我认为根据特征搜索数据比根据元数据搜索更直观。但是，元数据是用于描述这些信息的普遍接受的术语，因此我将使用该术语。

要暴露的元数据可以分为以下类别，每个类别都涉及特定类型的搜索和相关的决策：

业务元数据项目、用途、（数据）定义
技术元数据描述性元数据：位置、谱系、架构、管道内容元数据：容量、丢失数据、密度
运维元数据运行时标识符、依赖关系（编排）
参考元数据查找数据、代码等

这些元数据与第2章中提出的大多数观察实体相似，或者可以从它们中派生。

因此，一个数据可观察性系统也可以被描述为一个可发现性系统，因为与涉及的数据相关的观察将自动生成并汇总到数据可观察性平台中。

这是数据可观察性平台的作用——与数据目录合作，数据管理组件通常用于数据发现。这种合作将使数据目录能够始终根据用户的搜索返回最合适的数据，或者最终将信息推送给已表示有兴趣在数据关于某些特征可用时收到通知的用户。

问责制

因为工程师使用或生成数据的全部或部分，所以他们对这些特定操作负有一定的责任。例如，如果在流程中使用的一些传入数据未满足工程师的假设，工程师将被认为要么没有注意到它，要么更糟糕的是生成了不适当的数据（例如GIGO）。

因此，为了对这种新的责任有信心，工程师必须建立实施防御性方法（在第2章中引入并在后续章节中描述）的实践，以增加他们成功的机会，而不会影响他们的交付能力。他们必须使构建和使用数据系统的数据可观察。然后，他们必须将生成的观察与以下两个过程相结合：

假设检查（±SLO）
期望处理（±SLA）

最后的选择是作为一个后备计划，如果需要，一个可以依靠数据可观察性平台来创建关于可能对工程师进行持续监视的潜在约束的可见性。

数据质量

在确保数据质量方面，数据工程师的角色通常具有挑战性。这是因为工程师响应于来自主题专家（SME）的新数据或适应数据的业务请求的请求，通常由多种因素触发，例如报告的探索、市场分析、关于领域的特定知识或可能影响业务的特殊事件的意识。

然而，SME可能难以向工程师解释这些因素，因为他们可能没有相同领域特定知识的水平。结果，验证最终结果对于工程师和SME都可能很困难，因为结果的数量可能超出他们的个人领域的知识。

此外，即使SME能够表达最终结果如何通过勾画他们的约束或期望来验证，也不总是可能确保穷尽性。此外，结果的验证过程可能在长期或在不断变化的情境下不成立，这是另一个重要的考虑因素。然后来的是，生成的数据通常会被原始请求者或其他用户重复使用，这些用户可能来自其他领域，他们发现数据对于他们自己的用例非常有价值。

在理论上，工程师和利益相关者可以定义一组用于验证数据质量的约束。实际上，这导致了一系列令人不快的讨论，其中没有一方真正能够做出坚定的决定，因此不能承担全部责任。对于利益相关者来说，被分配为“先验”定义“好数据”的责任复杂且风险很高，现在和将来都是如此。工程师经常会在将项目部署到生产中时感到焦虑，而不确定他们应用的所有转换是否产生有效的数据。

实际上，一个连续的改进过程对于在所有涉及的各方之间达成一致是必不可少的。每个方都应在此过程中有一个明确定义的角色。重要的是要承认数据问题是不可避免的，潜在的问题可能无限多。通过承认这一点并实施连续改进过程，每个人都可以共同努力，确保以合作和建设性的方式识别和解决数据问题。

因此，在预测数据问题方面投入的时间和资源必须平衡得当，以提供足够的（或“足够好的”）一致性，以及升级此验证过程所需的迭代。

现在，我们可以重新审视实现有效工程师和利益相关者之间高效协作的角色和责任：

工程师验证已知约束。
利益相关者描述已知约束。
工程师将观察生成到数据可观察性平台。
利益相关者使用数据观察来维护或创建约束，然而，平台应足够智能，可以自动执行此操作。
当发现新类型的问题并需要预测未来时，工程师和利益相关者应该通力合作。

这种关注分离允许迭代，减少了双方的时间成本，为双方提供了正确的期望和风险水平。换句话说，这是实现双赢局面的唯一方式。

主数据管理和数据建模

定义与组织的业务或内部流程相关的实体需要时间和资源。这些努力旨在制定跨数据团队和项目必须遵守的格式、结构和特征的标准。

数据可观察性有助于识别那些未适当遵循这些定义的情况。举个例子，假设一个数据管道负责将日期信息写入数据源。日期信息的格式必须在所有条目中保持一致。为了确保这种一致性，可以实施一个数据可观察性指标来跟踪不符合所需日期格式的条目数量。

可以通过规则（期望）来检查此度量标准，并且如果不匹配的条目计数不为零，则认为管道失败。通过监控这个数据可观察性度量标准，数据工程师可以主动识别和解决与日期格式不一致相关的任何问题，确保高质量的数据并将下游问题的风险降到最低。

再次，数据可观察性充当重要的控制层，以确保实践和约定在组织中得到尊重、维持、鼓励和奖励。

数据集成和互操作性

随着专门的SaaS应用程序的爆炸增长，每个应用程序都有其特点和相关的人物，组织拥有多个工具并存在相对重要的重叠并不罕见。此外，已经认识到跨领域合并数据预计会产生令人惊讶的结果，例如未知的利基或未被充分利用的机会。

因此，大多数工具都提供了分享其数据、集成外部数据或两者都能够更容易实现的能力。可以使用编程接口（例如Python、ETL）或更高级别的工具（例如Matillion等）更容易地实现此目标。

因此，工具之间或通过数据平台之间的连接数量正在以设置它们的复杂性减少的速度增加。这是数据可观察性带来价值的地方——控制互连网络，并确保防止问题传播。

数据生命周期管理

这是一个广泛的主题。我将自己限制在仅删除和归档数据，以应对安全性或隐私要求，例如。在这些情况下，数据可观察性提供了一种嵌入式功能，可以公开执行删除操作以及其效果（删除了多少数据）或创建的归档（多少、多久以及何时创建的）。

反过来也是数据可观察性的有效用法，因为它提供了一种机会，可以公开很少使用的数据（或其子集），这些数据可以被删除或存档。

伦理和隐私

随着人们对数据的潜在影响（积极或消极）的认识日益增长，组织还需要采取一种防御性方法，以防止不当使用或共享数据。这是必须作为组织数据文化的一部分实施的东西，因为大多数问题都是无意的，是由于错误而发生的。数据可观察性首先提供了关键的可见性，在伦理和隐私的情况下，这一点至关重要，因为组织必须尽可能透明。

数据可观察性对伦理和隐私提供了巨大的支持，因为新的数据使用和共享都已记录，包括数据与谁共享。请注意，数据可观察性不是完整的安全机制。实际上，如果与共享数据的应用程序可以执行相关检查（例如使用计算共享策略），则可以避免共享。然而，这不是数据可观察性，而是真正的应用安全。然而，数据可观察性允许暴露数据的不当用途，因此可以采取预防措施，以避免将来出现类似的情况。

还需要考虑的一种情况是，当有一个自动化的决策流程可能存在偏差，因为用于定义流程的数据存在偏差。这是出于不同原因发生的，最常见的原因是数据被扭曲，这意味着某些类别与其他类别相比被过多地代表。这种情况也可以得到数据可观察性的支持，例如，通过控制偏斜度度量的变化或简单地显示分类字段的直方图。

DataOps

DataOps并没有一定的明确定义。然而，在《软件工程基础》中，Joe和Matt很好地描述了一些可能会在各种定义或理解中保持不变的领域：自动化、可观察性和事故响应。

我将这些领域与一套旨在实现数据工程师多个目标的实践和工具联系在一起。这些目标包括：

确保快速高效地部署到生产环境，同时保持结果的可靠性和准确性。
在出现问题或错误时便于调试。
提供多种自动问题检测方式，以尽快捕获和解决问题。

通过实施这些实践和工具，数据工程师可以更高效、更有信心、更加放心地工作。让我们看看数据可观性在这个画面中的位置，从自动化开始。

自动化

扩展是关于扩展数据目标。为了平稳和可持续地扩展，必须满足以下条件：

复杂性必须减少——以找到更多的人才。
摩擦必须减少——以在生产中更快地前进。
重复性任务必须自动化——以节省时间。

因此，与在高度自动化的系统中创建和维护信任相关的所有活动必须自动化。否则，当团队处于时间紧迫的情况下，它们将成为瓶颈，并且在跳过这些任务时将会浪费。这就是为什么数据应用必须通过设计或扩展成为数据可观察的原因，如第5章中所提出的。

可观察性

这一部分基本上是闭环，因为数据可观察性是可观察性的一个领域。然而，可观察性必须是一个最佳实践，尽可能多地自动化，最好是通过设计，在数据转换过程的所有步骤和工具中。

可观察性还在问题管理方面提供了价值，如下一节所讨论的，它负责生成优化整个过程所需的信息。如第2章中所介绍的，数据观察是为了使数据使用的可见性。因此，正如一些优化理论（例如，运营研究）中提到的那样，它们可以用于优化相关的维度，如时间、资源或结果。

没有将数据观察融入监控的话，系统将无法自我改进或具有确定性的改进过程。我在另一本书《数据治理是什么？》中已经讨论了这个话题，在其中我涵盖了成熟性的方面。在第三部分中，我强调了成熟度的第5级是：

优化（第5级）

数据治理计划侧重于持续改进，监控过程的质量和性能以及它们在实现业务目标方面的作用。组织以高效、一致的方式改进和调整其实践，以适应战略变化。

事故响应

DataOps的最后一部分与问题管理相关，主要是与响应报告的问题相关的过程。事实上，如果在数据出现问题时，没有数据可观性和本书中描述的相关实践，那么所有的事情都会匆忙进行，以尽快恢复信任。因此，没有什么是明显的，但是参与这种情况的双方都会感到整个过程的无效。

重新表达我的引言：问题管理效率低下，浪费了大量的资金。

因此，数据可观性的作用是提供有关问题管理的可见性，从问题检测到解决，再到事后分析，并帮助确定什么构成了事故响应的适当过程。

基于数据观察，包括用户参与和代码更改，可以从它们与已解决的工单数量的相关性、频率、涉及的数据、涉及的系统、解决过程的持续时间等方面绘制与组织改进或预防机制的相关性。因此，您可以将成本估计与TTD或TTR相关联，因此可以估算甚至预测（用于预算编制）总拥有成本（TCO），该成本考虑了与获取、实施和维护系统相关的所有成本。

软件工程

在数据工程领域，尽管这显然不仅限于该角色，但有一个重要的潜在因素。过去几十年来，特别是自计算机科学变得更加主流以来，已经建立和改进了一系列实践，其价值经常被低估。

的确，数据不能直接与软件进行映射，或更准确地说，软件，因为有许多子类别需要考虑，它们有自己的特点，将这种或那种实践的适用性分隔开来——嵌入式软件、Web 应用程序或简单的网站，例如，有许多专门的最佳实践。

因此，将数据视为软件的一部分并不完全荒谬，因为数据不能真正存在于没有处理的情况下。因此，许多软件实践适用于数据工程。您将在《数据工程基础》中找到其中的一些内容。我还会添加数据可观性，特别是使应用程序具备数据可观性，作为必须在所有数据从业者的DNA中编码的附加实践，就像软件工程师在其生产代码中记录、测试和检查接收到的消息的有效性（例如，编码、格式等）一样。

现在我们已经涵盖了架构和实践概念，让我们来讨论数据可观性在组织概念中发挥重要作用的领域。为此，我将使用我强烈信仰的一种范 paradigm）——数据网格（data mesh）。

支持数据网格的“数据作为产品”概念

我会从一个声明开始这个最后的部分：我的目的不是解释什么是数据网格——我会把这个任务留给它的创造者Zhamak Dehghani或其他投入大量时间思考它的专家。我的目标是为您提供一些建议，说明为什么数据可观性无疑是数据网格实践和技术组件的一部分，至少是在组织中的实施中如此。如果您想要或需要关于数据网格的解释，现在有两件事情我建议您去做：

阅读Martin Fowler的博客上的起源。阅读Zhamak的书《Data Mesh》（O'Reilly）。

在支持数据网格的许多概念中，我将专注于“数据作为产品”，这包括提供可以被视为组织资产的东西（例如，它可以被货币化）。在数据网格中，“数据作为产品”是支持数据产品实施的原则，这些数据产品是可以通过输入和输出API组合的工件，另外还有一个用于在纯数据流之外暴露的附加API，即控制API。该书将其表示为一个六边形，如“观测模型”所示。您可以看到API都带有标准化和领域无关的标注，这基本上是因为我在第2章中介绍的相同原因。

暂时不考虑数据网格中的领域这个重要概念，我们可以将数据想象成产品，将它们的输入和输出API连接起来，形成一个图形（一个网格），如图3-8所示。

您可以看到网格是通过API连接的。实际上，在图3-8中带有连接器的线代表了数据在传输，因为数据通过输入和输出API进行交换，并由控制API进行控制。然而，为了在这样的网格中解释数据可观察性，我使用了一个双重图表。在这种情况下，双重图表是指我们将输入和输出API连接视为节点，而链接仅表示控制API。由于这可能难以表示，图3-9显示了图3-8中网格的双重图表。

实际上，这个双重图表可以被称为“数据使用网格”。我们可以看到数据产品DP1和DP2出现了两次。这并不意味着这些产品被复制了，而是受控信息的数据产品高度依赖于其使用方式（输出API的使用方式）。

如果一个节点未满足期望，那么下一个边缘可以断开以避免传播，这就是创建一个（可能是孤立的）子图的断路器，该子图与找到的问题相关联。在这些示例中，假设DP2只在DP4的上下文中出错；这将在数据网格图中传播问题，并标记所有受影响的下游数据产品，包括DP3、DP4、DP6和DP7，而不仅仅是DP4本身。通过将数据使用网格纳入决策过程，只会影响DP2、DP4和DP7，因此DP3和DP6将不受影响。

这显示了对期望的上下文管理的重要性，并突显了数据网格的好处——它围绕API构建。与通用数据源（例如文件、表等）相比，这一好处显而易见，通用数据源可以随机访问，而没有受控的API（例如JDBC、文件系统访问等）。

尽管如此，我仍然没有介绍数据可观察性如何支持在数据网格中创建和管理数据产品。为此，我需要打开一个数据产品，看看数据可观察性可以添加到哪里（参见图3-10）。

事实证明，在某种程度上，这里涉及到两个层次的数据可观察性。

第一个层次是外部于数据产品的，涉及通过控制API公开可见性和可信度，供构建在其上的其他数据产品使用。然而，这个层次很可能是粗粒度的，因为在这个层次的意图不是解释数据产品的所有细节，数据产品的工作方式很可能会随着时间的推移而改变，而不一定会影响到消费者，而是为了验证从输出API输出的数据。

在这个层次上，连接（上游数据血统）与输入API的可见性非常重要，以便在数据产品的边界内（其内部），如果在输出API上检测到的问题是从输入API传播的，还是由于数据的误用（在管道内）导致的，可以进行演示和分析。

然而，在数据网格中，数据产品是原子的，意味着其内部可能非常复杂且不暴露。

因此，当问题是由于数据产品的行为时，需要第二层数据可观察性，这一层是局部的，针对数据产品级别，因为它提供了解决问题所需的可见性。

这种精细的数据可观察性提供了在数据产品级别高效运作所需的机制，并且实际上可以成为在更高级别（数据产品级别）提供的汇总视图的来源。

由于数据可观察性的第一个层次在某种程度上是对第二个层次中可用信息的粗粒度（聚合），我只将数据可观察性平台连接到了后者，以最大程度地提供可见性而不重复冗余。

混合这两个层次允许在数据产品级别定义SLO（服务水平目标），这些SLO首先与暴露给控制API的SLA（服务水平协议）相关联（自下而上）。其次，通过利用数据可观察性平台在依赖数据产品的输入API上进行的持续验证，可以调整SLO，这些验证也可以在控制API中暴露，以将此信息提供给上游数据产品。

总结

本章介绍了数据可观察性作为构建强大数据生态系统的关键要素。通过将其实施在数据平台的基础层，组织可以培养强大的数据文化并有效地管理其数据。数据可观察性还与DataOps愿景保持一致，并支持其所有支柱。

此外，它填补了数据组织中的差距，以确保在规模上实施数据战略，并与数据网格等相关范例集成。然而，需要注意的是，数据可观察性平台不能独立运行，需要数据产品和数据管道具备数据可观察性。接下来的章节将探讨如何实现这一目标。