第一章：介绍数据可观测性-灵析社区

从前，有一个年轻的数据分析师，名叫Alex，他对数据充满了深厚的热情。Alex热爱数据能够帮助企业做出明智的决策，推动增长并取得成功的方式。然而，Alex也意识到误解数据或者对数据的可见性不足可能带来的风险。

Alex正在与一位名叫Sarah的数据工程师一起进行一项关键项目。Sarah负责准备数据，确保它准备好供分析使用。随着他们深入研究项目，Alex和Sarah意识到有许多变量在起作用，而他们所使用的数据并不像他们最初想象的那样简单。

有一天，在Alex进行分析以生成洞察力的过程中，他发现当天呈现的结果看起来很奇怪，与他此前看到的情况难以相关联。他去找Sarah讨论这个情况，但Sarah需要更多关于他以前的解释、期望以及他要求她检查什么的背景信息。

在经过四天的合作、双人审查和多次头脑风暴后，Sarah和Alex发现，入站数据的半打变量的分布微小变化会在几个转换步骤后改变生成的洞察力。一些变量有更多的缺失值，因此在清理转换中被删除，另一些变量的平均值大幅增加，而一个数据集由于从操作源更好地提取数据而刷新，几乎是以前的两倍多。

尽管最初Sarah和Alex认为数据的质量可能下降了，但事实上，数据只是发生了变化，他们对数据的假设需要调整。他们意识到，他们很幸运这发生在项目投入生产之前，而这种情况将来可能会发生多次。如果他们没有预见到这些变化，他们将陷入困境。

这个经历让他们意识到数据可观测性的重要性。他们需要对数据、数据的转换和数据的使用情况有可见性，以便能够迅速对任何变化做出反应。他们开始采纳数据可观测性原则，并为数据管道添加所需的功能，以提供实时洞察数据、数据质量和数据使用情况。

从那天开始，他们拥有了仪表板和通知系统，用于跟踪管道中数据的健康状况，并提醒他们需要关注的问题，以确保客户始终收到准确可靠的数据。

通过这个经验，Alex和Sarah学到了数据是一个不断变化的生命体，需要持续监控和观察。他们意识到，如果没有数据可观测性，他们永远无法迅速应对变化，从而将项目的成功置于风险之中。

如果您正在阅读这本书，可能是因为您像Sarah和Alex一样，在自己的数据工作中经历或预计将经历类似的情况。您理解数据的力量，但也明白即使微小的变化未被注意到可能会带来灾难性后果。

但是您可能不知道需要做什么或如何入手。不用再担心了。在本书中，您将了解到Alex和Sarah是如何采纳数据可观测性原则的，以确保他们的数据管道可靠，客户获得准确可信的数据。通过将这些原则应用到自己的工作中，您可以避免不可靠数据的陷阱，为您的数据驱动项目的成功打下坚实的基础。

在深入探讨数据可观测性在规模上的作用和提供之前，让我们首先看看数据团队的发展以及他们面临的挑战。

扩展数据团队

更多的角色，更多的责任，更多的工程。数据团队是一组数据从业者，他们共同合作收集、处理、分析和解释数据，以生成洞察，并为决策提供信息，以推动更好的业务结果和提高组织绩效。

由于数据团队在组织中扮演战略角色，他们的运营效率可能成为将高需求数据纳入关键业务运营的瓶颈。为了应对这一挑战，数据团队的发展类似于上世纪50年代的IT团队——专门的角色，如系统工程师、Web工程师或后端工程师被增加，以支持特定操作，而不是拥有通才角色。

随着数据团队通过增加角色来增加其运营复杂性，会产生更多成员和团队之间的相互作用和相互依赖，进而增加了对更大可见性、透明度和标准化的需求。

在本节的其余部分，我将以搜索趋势为例，说明数据团队的创建和扩展以及数据工程师角色。随之而来的影响和挑战将在下一节中进行讨论，该节还描述了其他角色，例如分析工程师。让我们从谷歌趋势搜索开始（图1-1），搜索词为“数据团队”，时间跨度从2004年到2020年。我们可以看到，虽然数据团队一直存在，但对数据团队的兴趣始于2014年，并在2014年至2020年之间显著加速增长。

尽管“大数据”方面的兴趣减少（如图1-2所示）。

显然，这并不意味着不再需要大数据，但正如图1-3所示，2014年开始关注数据科学，因为它与价值生成的关联更加直观。

然而，尽管数据科学的兴趣开始上升，但很明显，数据的可用性成为许多数据科学项目的障碍。

数据科学团队并没有取代大数据团队。相反，数据团队已经拥抱了分析，因此增加了这个相对较新的数据科学家角色。

随着数据和分析对公司的成功变得更加核心，向合适的人提供正确的数据仍然是一个持续的挑战。加特纳（Gartner）指出，到2018年，数据工程师已经成为应对数据可访问性挑战的关键因素，因此数据和分析领导必须“将数据工程学作为其数据管理战略的一部分”。

因此，显然缺少一个专门负责为下游用例生成数据的角色。这就是为什么自从大约2020年以来，随着公司开始雇佣工程师专门帮助构建数据管道并整合来自不同源系统的数据，对数据工程师的搜索量显著增加的原因。如图1-3所示，今天数据工程正趋势迎头赶上数据科学家在搜索流行度上。

正如之前介绍的，以这种方式扩展数据团队，增加人员、角色和责任，会带来自己的挑战。让我们在下一节深入探讨这个主题。

扩展数据团队的挑战

随着公司寻求扩大其数据使用，它们也必须扩展其数据团队。我将用以下示例来介绍挑战及其后果：

数据团队中角色和责任的出现描述。
随着团队的扩大而增加的运营复杂性的分析。
数据发行管理（包括数据）的挑战以及它们对数据团队的心情和效率的影响。
提醒注意在机器学习/人工智能之旅中避免失败。

考虑一个起始只有一个人的数据团队，任务包括数据摄入、数据集成，甚至最终的报告生成。对于这个人来说，第一个项目可能是生成最近客户获取情况的视图。

数据工程师需要从公司的客户关系管理（CRM）系统中查询和摄入源数据到数据湖，将其集成到数据仓库中，并创建一个报告，供销售总监了解过去几周内销售进展情况。

这位初期的数据团队成员实际上是一把瑞士军刀：既涵盖数据工程又涵盖数据分析的职责，以交付项目成果（报告）。

在更大的数据团队中，这项工作所需的技能在数据工程、数据分析和业务分析之间平衡。然而，在一个团队中，个人必须精通构建和运行管道所需的技术，掌握报告工具，并理解业务关键绩效指标（KPI）。值得注意的是，每个领域都需要具体的专业知识。

到目前为止，这个人很开心，工作范围和责任如图1-4所示。

当然，这个过程并不是那么简单。例如，应该遵循整个系统开发生命周期（SDLC）将数据投入生产并使其可供最终用户分析。然而，在一个非常抽象的层面上，上述的基本过程大致是我们通常认为的数据项目中的“产生价值”的过程。

在只有一个团队成员和一个数据项目的情况下，整个数据生态系统相对来说是可控的。

这个过程对于一个人来说足够简单，整个项目的责任也归因于个人。因为团队只有一个人，他们还与业务利益相关者（如销售总监）有密切的关系，因此在用例的使用和项目的业务目标方面建立了一些领域知识。虽然通常情况下这是业务分析师执行的角色，但在这种情况下，数据工程师也承担了这个角色。

因此，如果用户提出任何问题，很明显应该由谁来解决。毕竟，他们不仅执行了过程的每个步骤，还了解了过程的每个领域。

然而，随着利益相关者认识到数据可能提供的潜力和价值，对这个人提出了更多的新报告、信息、项目等请求。因此，需求的复杂性增加，最终，个人在当前设置下达到了生产能力的极限。因此，迫切需要扩展团队并投资于专门的成员，以优化生产效率。

在接下来的部分中，我们将看到随着特定角色的创建，这个团队如何开始增长，如表1-1所示，表中还突出了每个角色的责任和依赖关系。

市场上数据工程、数据科学和数据分析技能也存在短缺，因此扩展团队变得极为具有挑战性。这在一开始时尤为真实，因为一切都需要并行构建，如文化、成熟度、组织结构等。因此，更加重要的是保留你拥有的人才，这意味着要确保他们的角色和责任与其技能集相匹配。因此，在下一节中，我们将了解这些角色是如何被添加的，他们将被期望做什么，以及随着时间的推移团队将会发生什么变化。

分工明确的角色与责任和组织复杂性

这个单人团队已经达到了构建新报告的最大容量，并增加了另一名成员以跟上不断涌入的请求速度。如前所述，重要的是要专业化团队成员，以最大化他们的产出、满意度，当然还有工作质量。因此，现在有一名数据分析师根据与利益相关者定义的报告，基于数据工程师构建的数据集，来交付报告。

分工角色的影响是数据工程师现在离利益相关者更远，失去了与业务需求的直接联系。从某种意义上说，数据工程师失去了对项目最终目的的部分可见性和最终结果的部分责任。相反，工程师将把所有的努力和精力集中在他们的可交付成果上——ETL、SQL或用于构建数据的任何框架或系统。

图1-5中显示了团队及其交付物，我们可以看到距离和依赖关系正在发生变化。

图1-5还显示了在数据团队采用新的管理体制后，已经交付了一些项目后所产生的工作范围。数据生态系统开始增长，端到端的可见性较少，因为它分散在两者的头脑中，责任分散在团队成员之间开始隔离。

接下来，一名数据科学家被加入到团队中，因为利益相关者愿意探索建立无需人为干预的自动决策系统，或者拥有专门负责监督结果和扩大数据产生的价值的团队成员。

如图1-6所示，这增加了更多的规模，这些项目将需要更多的数据，速度更快，机制更复杂，因为整个过程需要自动化以生成预期的结果。

随着时间的推移和整个系统的扩展，问题不可避免地开始出现。正如Google的一篇论文《高风险人工智能中的数据级联》所指出的，任何项目中至少有一个数据问题发生的概率高达92%。

由于系统已经发展得如此之多且如此之快，这些问题难以进行故障排除和解决。到底发生了什么？事实上，没有人知道。

系统内部缺乏可见性，再加上其复杂性，使其对于甚至是那些建立它的人来说都成了一个完全的黑匣子（一段时间以前）。

正如您在图1-7中所看到的，组织的数据生态系统已经变得像IT中的“传统系统”一样，只不过发生得更快。

在接下来的部分中，我将带您深入了解如何处理这些问题以及它们对数据团队动态的影响。然而，在此之前，让我们分析一下这些数据问题的构成。

数据问题的构成和后果解析

数据问题对大多数组织来说是一个持续且常见的挑战。根据邓白氏（Dun & Bradstreet）的一项调查，42%的企业表示他们曾经遇到过不准确的数据。

导致数据问题的最常见原因包括：

监管数据隐私或其他数据法规要求对数据的收集、摄入或存储进行更改，这可能会引发意想不到的问题。例如，通用数据保护条例（GDPR）的出台迫使零售公司更改了他们收集的数据，并将其限制为仅用于完全尊重客户的完整性的优化推荐引擎所需的数据。
业务需求不同的业务用例需要不同的数据配置。例如，某个业务用例可能依赖于收货地址而不是账单地址。因此，账单地址可以从数据中删除。然而，如果财务部门使用相同的数据，他们可能需要这些账单地址，但可能已经无法访问它们，因为这种用法不是“已知”的。
人为错误数据问题通常是由简单的人为错误引起的。例如，数据工程师意外地发布了一个删除所有金额列中负值而不是将它们设置为null值的转换应用程序。因此，数据用户获得的数据比预期的要少，从而降低了他们分析的准确性。
潜在信息错误这不是数据错误，而是对数据的解释错误。例如，由于运输工人罢工，蓝色运动鞋的销售量大幅下降，因为库存没有补充。然而，运动鞋的受欢迎程度非常高，买家们改买了棕色的。市场营销团队不知道实际情况（例如与运输效率和库存供应相关的潜在变量），估计棕色成为了新的蓝色。因此，生产了更多的棕色运动鞋，在一周后罢工结束时仍未售出。
数据漂移错误更加隐匿，这种错误也是对数据的误解，可能是由于潜在变量引起的；然而，最初的解释是准确的。随着时间的推移，数据真正发生了如此大的变化，以至于假设不再成立；因此，洞察力是错误的。这样的漂移示例可能发生在时尚领域，当某种产品受到年龄在28-31岁的人的喜爱时，但数据的范围是25-30岁和30-35岁。在这种情况下，明年，25-30岁范围（29岁的人）的兴趣可能会大幅下降，而移动到30-35岁范围（30-32岁的人）；因此，相关产品的推荐必须更改以适应最具代表性的范围。

导致数据问题的最具挑战性的方面之一是参与数据或应用程序更改的工程师通常不了解他们所做更改的影响。不幸的是，通常直到数据价值链的最后才会发现问题。总之，本书的整个目的是教大家如何在继续评估、沟通和验证对数据的理解和假设的同时，参与对任何此类情况作出快速反应的责任。

通常情况下，正如我们在扩展数据团队故事中讨论的那样，业务用户正在像往常一样工作，运行报告等，通过直觉和他们以前使用数据的经验来认识到数字“看起来不对”。但是，在那时，已经太迟了。在发现不准确之前，可能已经基于错误数据做出了业务决策。没有时间来解决数据问题，数据团队努力寻找谁具有知识和技能来帮助解决问题。然而，通常不清楚谁负有责任，或者解决问题需要哪些知识和技能。分析师？工程师？IT？

责任也可能会在一刹那间发生变化。也许分析师改变了某些信息计算的方式，现在影响到了销售报告，但甚至在此之前，数据工程团队可能已经调整了支持业务用户运行销售报告的销售分析工具的连接之一。

为了尝试解决问题，每个人都依赖于每个人对所做的事情、工作原理、文档的位置是否准确、（代码）历史中最后更改的理解等方面的知识。毕竟，问题归结为在同事协作或艰难地（独自在黑暗中）手动查找和解决问题。这是因为没有人能确定哪些字段或表将影响到下游的数据使用者。

解决问题所涉及的费用和时间以及对企业生产力、销售、总收入甚至声誉的负面影响都是显著的。邓白氏报告还告诉我们，近五分之一的企业因不完整或不准确的数据而失去了客户。将近四分之一的公司表示，数据质量差导致了不准确的财务预测，当然，其余的75%可能也因不准确的数据而受到其他用途的影响。不过，对于公司稳定性来说，25%的错误财务预测仍然令人印象深刻。

持续的数据问题可能会导致在基于数据洞察力做出业务决策时缺乏信心。根据最近对1300名高管的研究，70%的受访者表示他们不确定他们用于分析和预测的数据是否准确。

数据问题对数据团队动态的影响

首先，数据问题由数据用户检测到，他们开始怀疑，因为收到的数据与预期不符，或者分析的结果与预期不一致。这些怀疑的直接副作用是在用户心中埋下了对产生数据的团队或整个数据平台的不信任情绪。

图1-8描述了目前的情况，其中一个数据使用者开始对数据感到担忧，并想象刚刚发现的问题可能会在使用它的某些或所有应用程序中产生其他尚未发现的后果（也称为数据级联，问题传播）。

在这种情况下，用户总是在对他们来说不合适的时候检测到问题。他们需要在那个时刻的数据；否则，他们就不会访问或检查数据。

因此，用户陷入困境，当然会变得不高兴。事实上，用户不得不找出如何“修复”数据，而不是按计划工作。因此，最终的利益相关者将无法按时获得他们的数据。

此外，找出如何修复数据并不是一件简单的事情，因为接收到的数据可能已经被生成它的任何应用程序损坏。在这一点上，要遵循的过程取决于（数据）操作的组织方式；一个示例可能是创建一个带有评论“数据不正确，请尽快修复”的“事故”（工单）。

最终，在我们的示例过程中，有一个数据管理员负责有问题的数据。数据管理员负责解锁用户（至少是如此），并分析其他潜在后果，这可能会导致更多的事故。

要解决这种事故，数据管理员将不得不涉及负责生成数据的团队或个人。现在，时间线取决于那些需要时间来诊断症状并提出解决方案的人的可用性。

嗯，这听起来比实际情况要容易一些。该事故需要重新分配给制造商，制造商可能已经忙于正在进行的项目，不太可能立即找到问题。这还假设您能够找到正确的制造商！相反，可能会联系所有制造商，可能会召集他们开会，以了解情况。他们将对“问题”提出质疑（例如，“你确定这是个问题吗？”），并要求更多细节，这将回到已经生气的用户（很可能不会非常合作）。

因此，涉及到触及这些数据并被确定为潜在罪犯的应用程序的应用程序必须进行彻底分析，其中包括以下任务：

访问生产数据，通过运行一系列探索性分析（例如查询，在Spark中进行的聚合计算）手动验证和了解数据问题。考虑到对数据的访问权限可能尚未被授予。
重复此操作，通过时光旅行数据（如果可能）来识别问题何时开始出现（例如，delta表可以帮助进行时光旅行，但仍然需要找到问题出现的时间）。
访问应用程序的生产日志（通过SSH登录计算机或从日志平台访问），分析其行为，甚至审查其历史记录（版本等），以防应用程序的业务逻辑发生了更改，这可能会影响结果。考虑到与数据访问一样，日志可能需要特殊权限才能访问。
分析业务逻辑，以追溯到应用程序消耗的原始数据，以识别潜在的数据级联（问题传播）。

重复此过程，直到找到根本原因，知道哪些数据和应用程序需要修复，最终执行回填（以恢复真相）。

那么，坦率地说，因为时间至关重要（请记住，用户感到不满），根本原因可能不会被跟踪，而是将应用两种临时的最终补丁之一：

运行临时脚本（也称为数据质量工具）来“修复”导致过程失控的数据（例如，超出数据生命周期的范围等）。
更新其中一个应用程序以“清理”接收到的数据。这涉及在本地解决问题，可能会产生尴尬的副作用，例如删除或填充空值，这可能会改变变量的分布，如果数字增加并对下游产生副作用（例如，糟糕的决策）。

事实上，这个称为“故障排除”的过程困扰了许多人，其中许多人甚至不需要为此事受到。值得注意的是，虽然故障排除正在发生，但问题的范围已显著扩大，如图1-9所示。

而且，在此数据上检测到的问题可能对其他项目、用户和决策产生其他后果（请记住，数据级联！），这会进一步扩大问题的范围，影响数据的所有用途。

另一个称为影响分析的过程与我们刚刚涵盖的故障排除有些相似。但是，它的目标略有不同，因为它旨在预防或传达问题。

事实上，不仅目标不同，而且影响分析也要复杂得多，更加敏感，因为它需要请求所有用户的时间来检查他们的数据、结果、分析或决策。

更糟糕的是，有些人可能会发现决策在更长的时间内都是错误的，可能与问题出现的时间一样长，而一切都发生得悄无声息。

在这一点上，考虑到故障排除和影响分析，数据问题的范围如图1-10所示一样大。数据管理员必须尽快解决这个问题。

这就是为什么我们称数据为“悄无声息的杀手”。在我们的示例中，它使每个人都变慢，破坏了所有的信任，并产生了压力、愤怒和焦虑，却没有引发任何警报或“异常”（如在软件中）。事实上，数据不会引发警报或异常——至少目前不会；然而，有一种方法可以启用这种功能，我们将在下一章中看到。

在这个分析中，我已经强调了与流程中所涉及的时间和人员相关的挑战，以及在临时修补上浪费的大量努力，这只会产生更多的数据负债。尽管这些挑战的重要性不言而喻，但在问题被检测到的时候，我们失去的另一无法估量的资源是信任，既对数据又对数据团队。

这种信任已经建立了几个月，甚至几年（例如，对于敏感的基于人工智能的项目），但由于没有预期到如何维护它，它就像一堆纸牌一样在几秒钟内崩溃。这种情景和由此产生的后果对整体情绪产生了负面影响，导致了高度有才华的团队成员的沮丧和离职。

因此，我们可以在事故管理过程中识别出许多问题，如果在错误的时间提出，可能会破坏情绪：

谁对这个问题负有责任？
为什么是我：发现了问题？应该对此质疑？
为什么用户告诉我数据似乎不准确？
数据真的不准确吗？
什么应用可能会引起这个问题？
什么上游数据可能是原因？
这个问题的未知后果是什么（即还有其他项目在使用这个数据，也可能会受到影响）？

理解为什么会提出这些问题使我们能够确定问题的根源，这超出了任何数据问题及其原因。需要解决的挑战不是数据本身；问题在于在数据团队成员和利益相关者之间缺乏明确的问责和责任，这一挑战得以加强，因为缺乏对野外数据过程（即在生产中，使用过程中）的可见性。

因此，当这些问题由数据团队提出或提出时，它们会阻碍创造价值的障碍，因为它们将产生以下成本：

需要大量时间来解决，在此期间数据仍然无法被使用者使用。
需要大量的精力，并意味着在源头解决问题的能力受到了削弱，而本地的“补丁”很可能会成为默认的解决方案。
引发焦虑，加剧对可交付成果、数据和供应商的信任丧失。

这就是数据可观察性发挥关键作用的地方——它有助于更好地实现对数据和数据生态系统健康状况的可见性，并更好地分配（分发、分散）责任和责任。

扩展人工智能的障碍

在前一节中，我们介绍了在扩展数据团队时许多人面临的挑战。在本节中，我将重点关注组织期望从其数据团队中获得的最关键成就之一，即扩展其人工智能能力。

然而，这些与可见性有关的挑战，在问题出现时限制了价值的实现，也在实施人工智能时带来了重大挑战。

根据Gartner进行的分析（见图1-11），公司在开发其数据和人工智能计划时面临的最重要障碍包括数据量和/或复杂性、数据范围或质量问题以及数据可访问性挑战。

好消息是，数据可观察性有助于解决这些障碍，但在我们深入讨论如何解决之前，让我们更深入地了解主要障碍以及它们存在的原因。

调查结果表明，技术相关的挑战占据了问题的29%，现有基础设施的复杂性占据了11%。有趣的是，将近一半（48%）的受访者表示，他们面临的挑战与缺乏可见性以及对负责解决问题的人员缺乏明确性有关。

让我们来看看一些常见的障碍：

安全性/隐私担忧或潜在风险或责任几乎有五分之一（18%）的受访者在Gartner的调查中将这些问题视为实施人工智能的最大障碍。风险管理安全性涉及了解数据将由谁、为何以及出于什么目的使用。如果数据本身不正确，数据产生的结果也不准确，这可能会导致糟糕的业务决策，从而存在潜在的风险或责任。最后，还有担忧结果可能不符合某些伦理约束。
数据量和复杂性这个问题对8%的受访者来说是最大的障碍。数据的复杂性和大小需要进行大量实验，以了解并从中提取价值。由于在执行相同的大型和复杂数据集上进行实验时缺乏关于执行的可见性，例如分析和整理，因此它们是重复的。然而，这个过程需要时间和精力。
数据范围和质量对于6%的受访者来说，数据质量问题是最大的障碍。如果数据质量未知，那么很难对数据产生的结果或最终结果有任何信心。
治理问题或担忧、对AI的好处和用途缺乏理解以及难以找到用例总共有16%的受访者认为这些问题之一是实施人工智能的最大挑战。数据治理是一个重要问题，因为文档编制是手动且耗时的，这意味着它不总是做得恰当，因此其整体影响和价值并不总是明显。但是，如果没有良好的数据治理，将影响输入AI算法的数据质量，而且如果没有关于数据质量的可见性，利益相关者可能会担心数据的安全性以及AI输出是否准确。

在撰写本文时，关于人工智能使用的一种中断出现了，即公众的可访问性，这是基于一种称为大型语言模型（LLM）的模型的文本生成的生成AI的使用。使用此方法构建的最受欢迎的工具是OpenAI的ChatGPT，因为它使任何不精通人工智能的人都能够与算法进行聊天；意味着进行结构化讨论，其中每个新答案都考虑到了讨论的余下部分（上下文）。讨论通常旨在基于某些说明（是的，就像编码一样）生成内容，例如博客帖子、定义、结构化的观点、提案等。

然而，从其普遍可用性的最初几周起，已经突出显示了这些大型模型中响应的准确性以及数据如何使用的问题。例如，意大利曾经禁止访问该服务，因为认为它可能有助于传播错误信息和偏见。尽管经过验证其符合年龄政策后已重新开放，但对不准确或带有偏见信息的明确说明并未提供类似的信息。

对于数以百万计甚至数十亿人使用的此类工具来说，设置正确的期望（例如准确性、及时性等）是至关重要的，以避免基于错误的“生成”信息做出不适当的决策或全球性的动态。这不过是将本节讨论的内容提升到另一层级的一个例子，即不仅适用于足够成熟以定期用于业务决策的公司，这可能会影响其生态系统，而且还适用于小企业和个人。

到目前为止，我已经带您了解了扩展数据团队和人工智能的旅程，我们已经确定了一些挑战，例如缺乏可见性（数据管道、数据使用等），以及关于责任和责任的清晰度的缺乏，导致了不信任和混乱，最终导致对数据的兴趣或信心的丧失。这凸显了数据管理的整体重要性。因此，下一节将介绍其在规模上的挑战，这将使一切都能够结合起来，并将数据可观性作为解决这些挑战的一种粘合剂。

目前的数据管理实践存的挑战

与任何公司转型一样，数据转型及其相关的数据团队的创建也引发了一个问题，即这些团队应该在组织中的哪个位置。是否应该有一个中央数据团队？它应该隶属于IT吗？或者，也许每个业务领域都应该有一个数据团队？它们应该隶属于IT，还是应该在每个领域都有一个团队？但是，它们如何进行协作，如何保持一致性和效率呢？等等，等等。

这些问题以许多不同的方式得到回答；数据网（在第3章中讨论）是为数不多（甚至可以说是唯一一个）通过重新思考所有层面的数据管理，包括体系结构、文化和组织层面，来解决这些问题的方法之一。

然而，不管数据团队在组织中的位置如何，让我们分析一下扩大这些团队对数据管理的影响。数据管理是一个广泛的主题，在文献中有着广泛的定义。对于这个分析，我将集中讨论DAMA（数据管理协会）在其《数据管理知识体系》第2版（DMBOK2）书中所定义的数据管理方式。

在DMBOK2中，数据管理涵盖了许多领域，如数据架构、元数据和数据质量。所有这些领域都参与了提升数据价值，数据治理旨在规定必须遵守的政策，以确保高效生成数据价值，并符合组织的核心原则。

这在框架中显示的“数据管理之轮”中得到了很好的体现，如图1-12所示。

随着越来越多的企业变成数据驱动型企业，具有数据洞察力的业务团队和数据团队正在组织中蔓延。因此，数据文化不再局限于一个明确定义的专业中心，而是一种价值观，必须纳入整个组织的价值观中。

因此，轮廓中划定的领域已经发展，以适应不同的情况和需求。自2017年以来，最突出的一个领域是数据治理，它在下一节中进行了讨论。例如，我们将讨论这种曝光如何影响其他领域，如数据质量和元数据。

规模化的数据治理影响

许多挑战源于数据管理实践和技术的演变，但我将集中讨论一个具体的挑战：如何在规模化的情况下控制数据文化的维持，不仅要尊重数据治理原则，还要尊重所得政策的定义和实施。数据治理确定了政策，每个领域都负责定义、规划和执行实施。

然而，随着实施的进行，引入了许多不同领域之间的依赖关系，再加上一切都在扩展；没有一个协调一致、明确定义和全局控制的层面，任何出现问题的领域都可能导致系统崩溃。

这就是为什么我建议不一定要改变数据管理的结构，如DMBOK2中所介绍的，而是通过一个额外的领域来扩展它，围绕着数据治理领域。

这个新领域是数据可观察性，它将通过为组织提供衡量其系统内数据的健康和使用情况，以及整个系统的健康指标的能力，来扩展组织的数据管理实践。然而，数据可观察性的更详细定义将在“可观察性领域”一节中进行解释。

将数据可观察性放在这个位置上使每个人都负责实施它。其原则和政策应该在所有领域中得以整合。

结果如图1-13所示；然而，这并不意味着一定需要一个数据可观察性的角色、团队或部门。它陈述了在规模化情况下，控制必须变得明确，因为数据可观察性在较小规模下可以以更加临时的方式处理。

在本书的其余部分，我们将探讨可观察性如何从IT DevOps领域延伸，并如何将其应用于数据和数据团队。

此时，应该清楚横向挑战（数据管理）和局部挑战（在数据团队内部）已经成为近年来扩展数据战略和实现对数据投资最大回报的瓶颈。现在让我们讨论一个全面解决这些挑战的解决方案，即数据可观察性。

数据可观察性来拯救

到目前为止，我已经讨论了随着数据团队的发展所面临的挑战，以及在组织试图扩展其数据和分析战略时，缺乏可见性和对责任不清晰会产生的作用。然而，这并不是我们第一次遇到这样的挑战；最接近的例子是当IT迅速扩展时，这导致了DevOps文化的发展。DevOps多年来发展壮大，因为越来越多的IT实践（例如服务网格）需要更多的最佳实践和相关工具来有效支持它们。其中最著名的最佳实践示例可能是CI/CD（持续集成和持续部署），但在基础架构或应用程序层面上的可观察性也已成为旨在提供更多可见性并建立对其应用程序和系统的信心的任何架构的一部分，同时加快上市时间并减少停机时间。因此，相关市场已经出现并增长，以支持这些可观察性要求。各种公司已经开发了与DevOps相关的各种服务和技术，涵盖了IT环境各个成熟度水平（例如Datadog、Splunk、New Relic、Dynatrace等）。在IT领域，“可观察性”是指IT系统生成行为信息的能力，以允许外部观察者重建（建模）其内部状态。从而，持续的可观察性允许外部观察者持续地对内部状态进行建模。从根本上讲，观察者在系统正在运行时无法与系统交互（例如，我们无法登录到服务器）；它只能观察到可以感知到的信息，因此被称为“观察”。现在，让我们讨论一下这些观察是什么。

可观察性的领域

IT系统天生复杂，由多个类别组成，这些类别的数量可以急剧增加，例如基础设施、云、分布式、机器学习、深度学习等。然而，在本书中，我将避免过于详细，而是将可以“观察”的IT系统类别合并为几个领域之一，其中一个领域与数据相关，如图1-14所示。

这些领域并不是完全独立的，因为它们在编码系统的复杂性时具有许多交互作用。这就是为什么Venn图似乎是最好的表示方式。

在详细讨论“数据”领域和“数据可观察性”之前，让我们简要回顾一下其他领域：

基础设施

使用基础设施日志度量，您可以推断与内部基础设施组件相关的性能特征。当发生故障或未满足某些性能参数时，可以设置积极的可行操作警报。

应用

观察应用程序端点、版本、打开线程、请求数量、异常等，可以帮助确定应用程序的性能如何以及是否存在问题以及为什么存在问题。

用户/目的

了解和“观察”是谁在使用或实施应用程序，项目的目的以及项目的目标非常有用。这有助于了解最常见的项目或目标，检测重复的努力或组成专业中心。

分析

观察分析，从简单的转换到复杂的AI模型，有助于识别并了解数据的持续使用以及从中产生的见解。

安全

观察与安全相关的操作，例如授予访问权限或分配角色的修改，或有关哪些角色比其他角色更常用的度量，可以使安全系统的效率以及可能的改进领域可见。其中一些领域在DevOps文献中已经得到了很好的涵盖。但是，我们专门关注数据可观察性。
因此，我们得出结论，数据可观察性可以定义如下：数据可观察性是系统生成关于数据如何影响其行为以及系统如何影响数据的信息的能力。如果系统具有“数据可观察性”能力，那么系统就具有数据可观察性。如果系统具有“可观察性”能力（基础设施、应用程序、用户、分析、安全和数据），那么系统就是（完全）可观察的。

值得注意的是，Gartner已经定义了数据可观察性，其与我们的定义基本一致：数据可观察性是组织具有对其数据景观和多层数据依赖关系（如数据流水线、数据基础设施、数据应用程序）进行广泛可见性的能力，以实现在可接受的数据SLA范围内迅速识别、控制、防止、升级和纠正数据中断的目标。数据可观察性使用连续的多层信号收集、整合和分析来实现其目标，并向其提供更好的性能设计和更好的治理建议，以匹配业务目标。

Gartner的定义还讨论了数据可观察性的用途（例如，防止问题）。但我没有将这作为我的定义的一部分，因为我想关注它是什么，而不是它的作用（另外，我不将苹果定义为能够满足我的饥饿的水果）。尽管如此，了解数据可观察性的好处非常重要。在下一节中，我们将更详细地探讨数据可观察性的用途。然而，我和Gartner都同意，应考虑重要的“多层”或“多领域”组件。然而，我使用了术语“领域”，因为层意味着存在一定程度的独立性，而实际上并非如此。

如何让数据团队立即利用数据可观察性

数据可观察性的主要用例目前主要集中在数据问题管理方面。然而，随着数据不断增加和其用途的扩展，将会出现更多的用例。

低延迟数据问题检测

数据可观测性与应用程序（其使用环境）越同步，问题与其检测之间的延迟就越小。事实上，数据可观测性可以在数据使用的确切时刻利用，以避免监控与使用之间的任何滞后。这将允许您尽快检测到数据问题，帮助您在用户之前发现问题。

以这种方式利用数据可观测性可以减少问题的检测时间（TTD），因为数据工程师会及时收到警报，因为任何数据使用问题都会在实时中观察到（即同步可观测性）。

高效的数据问题排除

在大多数组织中，当出现数据问题时，数据工程师需要花费大量时间来找出问题所在、问题的根源以及如何解决它。而整个过程的每一步都需要大量时间。有了数据可观测性，解决问题的时间（TTR）会快得多，因为整个系统都有可见性，这要归功于上下文可观测性，它提供了有关数据及其使用背景的信息。这使得数据工程师能够在问题影响到下游业务用户之前解决问题。

预防数据问题

当作为整个开发生命周期的一部分实施，包括生产环境时，数据可观测性提供了对数据和数据生态系统健康的持续验证。持续验证可以显著提高应用程序的可靠性，预防数据问题，降低总拥有成本。

分散式数据质量管理

服务级别协议（SLAs）可以像在IT DevOps中用于确保可靠性和其他关键指标一样，管理和确保数据质量。这种新型的数据质量管理需要数据可观测性，一方面，它可以提供同步（接近实时）和持续验证数据的能力，进一步提高了现有服务级别协议（SLOs）的效率。但更重要的是，另一方面，数据可观测性将允许在使用情境（例如应用程序）内以其使用的粒度定义SLAs和SLOs。这个能力解决了数据质量管理计划中一个最重要的障碍，即由所有者、数据监护人或主题专家（SMEs）定义SLAs的问题，因为他们很难定义一组可以满足所有使用期望的约束条件。因此，他们不能提出一个单一的（中央的）SLAs集合，因为每种用例可能会以不同的方式感知SLAs。数据SLAs的关键区别在于它们可以采用非常多种多样的形式，几乎无限; 例如，对于来自随机CSV文件的单个字段，您可以有关于最小表示、空值数量、类别数量、偏度、0.99分位数等的SLAs。因此，利用数据可观测性以上下文化的方式（使用情境）来分散SLAs的定义对于管理数据质量、定义责任和明确角色和责任的文化至关重要。

补充现有的数据治理能力

还记得之前提到的 DAMA-DMBOK2 数据治理框架吗？因为数据可观测性是该架构的一部分，并围绕数据治理的所有领域，它提供了对在数据级别互动的所有不同组件的可见性。这使得数据团队能够自动创建文档，使用相同类型的数据、数据存储和数据建模，同时提供更多关于不同数据模型的可见性，了解已发布到数据目录的数据，运行了哪些数据分析，以及使用了哪些主数据。

未来和更远的未来

通过更好地理解数据可观测性的不同用例，您现在应该能够理解数据可观测性如何用于优化您的数据系统以及数据团队。

在接下来的章节中，我将更深入地介绍如何设置这些用例，并介绍捕获每个用例所需信息的最有效和有价值的方法的最佳实践。

总结

数据可观测性是现代组织的一项重要能力，这些组织依赖数据来实现其目标。随着数据团队规模和复杂性的不断增长，建立促进透明度、治理和数据验证的实践变得越来越重要。本书从数据可观测性的视角着重关注数据治理的技术方面。通过采用简单而强大的习惯，组织可以确保其数据工作在整个数据生命周期内可见、可控制和可管理。接下来的章节将探讨数据可观测性的核心原则以及使系统具备数据可观测性的最佳实践和方法。