沃卡惠你是否知道那个卡通比喻：堤坝上出现了漏水，卡通角色很快用手指堵住了它，却发现又出现了一个需要堵住的漏水，以此类推，直到没有更多的手指或整个大坝爆发?
数据工程师非常清楚这种感觉。
出现异常情况，并指派了一名数据团队成员来解决它，但根本原因分析过程需要很长时间，以至于当一切都解决时，又出现了三个泄漏，并且没有更多的尸体可以扔到问题。
简而言之，根本原因分析和异常解决方案花费的时间太长。事实上，当我们对Wakefield Research 的 300 名数据专业人员进行数据质量状况调查时，我们发现解决数据事件的平均时间为 9 小时!
受访者还报告平均每月发生 61 起数据事件，这意味着数据团队平均每个月要旋转根本原因分析轮 549 小时。
与其在无休止的跑步机上运行修复损坏的管道和调查空值，不如数据工程师可以简化这个过程呢?如果我们成功的秘诀就在我们眼前呢?
这是一个与时间一样古老的故事(与几年前一样古老)。尽管如此，在我看来，最好的方法是让数据团队开始处理他们的关键数据资产，比如生产软件，包括事件解决方案。
如何识别和分类数据异常
在我们进入根本原因分析最佳实践之前，了解数据和管道中断的方式非常重要。数据在这方面非常有创意，也是单元测试数据不足以检测大多数事件的原因之一。
虽然几乎有无数种方式或根本原因可以解释为什么“这些数字看起来不正确”，但好消息是大多数异常可以分为四种类型。
1. 新鲜 度：数据新鲜度异常(有时称为及时性)是指数据没有及时更新。这通常是由业务需求决定的。高管可能需要每个季度的客户流失数据，营销人员可能需要每天早上 8:00 的新广告数据，或者流媒体网站上的机器学习驱动的推荐引擎可能需要近乎实时的数据。
2. 分布 ：分布异常是指您的数据值超出可接受的范围。在某些情况下，它可能是一个可接受的异常值，例如在会议期间访问您的网站的访问者激增，或者是在胡说八道的时候，例如报告从纽约到洛杉矶的货物在几秒钟内发生。无论哪种方式，这表明您应该深入研究。
3. 容量 ：容量异常是指您的数据过多或过少，表明您的数据源的健康状况可能存在问题。如果 2 亿行突然变成 500 万行，你应该知道。
4. 模式 ：当数据的组织发生变化时，模式异常就会发生。它可以像重命名、添加列或将字段类型从流更改为数字一样简单。当这些变化是意料之外的(而且它们往往不是)时，它们会破坏下游的流程。
数据团队了解这些异常类别非常重要，这样他们才能快速评估问题、标记问题并使用添加词汇进行交流。
对异常进行分类的另一个原因是数据异常类型有时可以作为问题所在的线索 (从而加快解决问题的时间)。对于具有该特定平台经验的数据工程师来说尤其如此，他们会因过去的事件而伤痕累累。
例如，发生数据新鲜度异常的方式有很多种，但是当您看到其中的一种时，您应该做的第一件事是检查您的 Airflow DAG以查看作业是否失败。一旦数据消费者通过电子邮件发送了关于数据质量的讨厌说明，这些检查就可以手动完成。不过，更好的方法是实施自动数据监控，以便您的团队第一个知道。
我们敢在破碎仪表板的阴暗墓地里唱歌，“准备好了吗?”
主动数据监控不仅可以保持数据信任并加快检测时间，还可以加快解决问题的时间。
尽管如此，因为有更快的认知跳跃和对因果关系的直观理解 - 或者最近在导致问题的环境中可能发生了什么变化。
评估影响和分类
你还记得那些土狼追赶路行者如此匆忙的时候，当他低头时，他发现他的脚下没有地面?他行动迅速，但效率不高，结果一落千丈。
异常解决方法相同。数据团队花费如此多时间的原因之一是他们发现自己以相同的努力追逐每一个异常，却不知道何时或是否会从他们身下跌落。
换句话说，他们不知道异常的影响是否与响应成正比。例如，如果仪表板在 4 小时内没有更新，这是一个问题吗?有时是，有时不是。
避免 SPLAT 的一种方法是确定您最重要的数据资产并与业务利益相关者合作创建数据 SLA。与消费者一起编写他们的期望和用例，为有效的事件分类提供必要的背景。
挑战在于数据资产不断增加，数据消费模式也在不断变化。自动化数据沿袭可以帮助团队在不断发展的环境中有效地识别他们的关键表。
跨团队主动沟通
沟通对于根本原因分析和异常解决方案至关重要。第一步是确保正确的数据工程师有正确的警报。
就像 Jack Skelington 在万圣节比圣诞节表现得更好一样，数据团队的成员将更有效地解决他们自己领域或专业领域内的异常问题。发送警报和分配任务对于在避免倦怠的同时创建所有权和责任感至关重要。
为什么会倦怠?好吧，对于团队来说，指派他们最有才华的工程师来帮助扑灭任何可能着火的地方是很诱人的，虽然这项任务很紧迫，但也可能很乏味。
作为 Red Ventures 的(数据)产品管理总监，Brandon Beidel 表示，不良数据可能“……触发工程师进行 2 到 3 小时的考察，以追查问题的根源。不幸的是，最擅长发现这些问题的工程师随后被这些类型的问题所淹没。我们需要找到一条出路，摆脱这种享乐主义的跑步机和无休止的时间循环，从高效的人身上夺走时间。”
第二步是通知您的数据消费者存在问题，因此他们不会对不良数据采取行动或传播不良数据。我们认识的一位数据工程负责人描述了一种将表格用于执行报告的情况。
他们发现了数量异常，并迅速通过电子邮件发送给他们的矩阵合作伙伴或业务利益相关者，他们拥有该报告只是说：“我们现在遇到问题，但我们正在努力解决。请不要发送您的每日报告。”
业务利益相关者非常欣赏他们的积极主动性。这是矩阵合作伙伴知道数据工程团队支持他们的时刻。突然之间，数据团队从解决问题转变为提供服务。
最后，重要的是不仅要在数据工程团队内部进行沟通，还要在可能是问题根源的其他团队之间进行沟通。
例如，该模式是否会更改一次性异常，还是会由于软件工程团队推出的一项新功能而改变您正在摄取的产品遥测数据的输出?您的 IT 团队可能知道。
确定上游依赖项
一旦确定了异常类型并评估了影响，数据团队需要确定受影响最大的“上游”表。换句话说，不良数据首先从哪里进入您的环境?
这很关键，主要有两个原因。首先是上游表将为根本原因分析提供关键上下文。 如果异常是最上游的表之一，则可能是数据源的系统问题。如果问题起源于数据消费者附近的下游，则可能是代码问题或 dbt 模型是罪魁祸首。
第二个是，如果你不是……好吧，在它的根源上，你就无法解决根本原因。 否则，无论您多频繁地将正确数据回填到表中，不良数据将继续从其来源处级联。
自动化数据沿袭可以帮助团队避免通过 SQL 查询来手动跟踪和重新跟踪表依赖关系的卡通化过程，在无尽的迷宫中找到异常的起源点。如果您手动执行此操作，您会发现“您应该在阿尔伯克基左转”。
分析引入异常的三个基础设施层
每种异常类型的根本原因几乎是无限的，但它们都源于数据基础架构三层的问题。
了解这些层以及它们如何产生数据异常可以为您的事件解决过程提供结构。
系统根本原因： 当系统或客户在提取、加载和转换过程中应用于数据的工具引入错误时，系统或操作问题被发现。这方面的一个示例可能是运行时间过长的 Airflow 检查，从而导致数据新鲜度异常。另一个示例可能是依赖于访问 Snowflake 中的特定模式的作业，但它没有访问该模式的正确权限。
代码根本原因 ：第二种数据事件根本原因与代码有关。例如，您的 SQL 或工程代码有什么问题吗?不正确的 JOIN 语句可能会导致不需要或未过滤的行?还是 dbt 模型意外添加了一个非常严格的 WHERE 子句，导致输出数据行数减少而触发卷异常?如果您能找到一个在引入异常的大致时间前后修改过的查询或 dbt 模型，那么这是一个很有希望的迹象，表明您已经找到了根本原因。这个过程可以通过整个堆栈的数据监控和日志分析来加速。
自动化数据监控和日志分析的示例。
数据根源： 系统和代码问题在软件工程中也很典型，但在数据工程的精彩世界中，数据本身也可能出现问题，使其成为更具动态性的变量。例如，它可能是一个消费者应用程序，其中客户的输入很古怪。假设您是一家在线宠物零售商，有人输入他们的狗重 500 磅而不是 50 磅，这会导致现场健康异常。虽然您可以手动运行多个查询以通过重复 Bart Simpson 在被拘留的黑板上写下他的台词来分割数据，但这也是一个可以自动化的过程。有多种数据质量解决方案，包括数据可观察性平台，可以快速可视化破坏用户定义的业务逻辑的“坏行”，以帮助查明问题所在。
快速查看异常行分布有助于查明数据级事件。
整合事件解决流程
由于数据异常可能源自管道的每个组件以及数据本身，因此事件解决方案会变得混乱。
数据团队可能会为 Fivetran、Databricks、Snowflake、Airflow 和 dbt 打开选项卡，同时查看其 ETL 引擎中的日志和错误跟踪，并运行多个查询来分割数据。
数据可观察性可以帮助您在单一窗格中查看对 SQL 代码、dbt 模型和 Airflow 问题的任何更改，只需单击一下即可查看完整的数据沿袭。这减少了上下文切换，从而实现更快的分辨率。
借助数据可观察性，您可以在单个窗格中立即查看事件的关联 SQL 查询、dbt 模型等。
您的团队需要更快地解决数据问题以减轻负面影响，以便将更多时间花在为业务增加价值的任务上。
否则，每一次数据事件都会让人感觉就像有人把钢琴掉在了你的头上。
