如何使数据异常解决不那么卡通化

如何识别和分类数据异常

在我们进入根本原因分析最佳实践之前，了解数据和管道中断的方式很重要。数据在这方面很有创意，这也是单元测试数据不足以检测大多数事件的原因之一。

虽然几乎有无数种方法或根本原因可以解释为什么“这些数字看起来不正确”，但好消息是大多数都可以分为四种类型的异常。

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 模型，则这是一个很有希望的迹象，表明您已经找到了根本原因。可以通过整个堆栈的数据监控和日志分析来加快此过程