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

本文主要是介绍如何使数据异常解析不那么卡通化，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

异常现象突然出现，数据团队的一名成员被指派来解决它，但根本原因分析过程需要很长时间，以至于当一切都修复时，又出现了三个泄漏，并且没有更多的机构可以解决问题。

简而言之，根本原因分析和异常解决需要的时间太长。事实上，当我们使用 Wakefield Research 对 300 名数据专业人员进行数据质量状况调查时，我们发现数据事件的平均解决时间为 9 小时！

受访者还报告了平均每月 61 起数据事件，这意味着数据团队平均每月要旋转 549 小时的根本原因分析轮。

与其在无休止的跑步机上运行修复损坏的管道并调查空值，如果数据工程师可以简化此过程会怎样？如果我们成功的秘诀就在眼前呢？

这是一个与时间一样古老的故事（也与几年前一样古老）。不过，在我看来，最好的方法是让数据团队开始像对待生产软件一样对待他们的关键数据资产，包括事件解决。

如何识别数据异常并对其进行分类

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

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

1. 新鲜度：数据新鲜度异常（有时称为及时性）是指数据在应该更新时没有更新。这通常是由业务需求决定的。高管可能需要每个季度的客户流失数据，营销人员可能需要每天上午 8：00 的新广告数据，或者流媒体网站上的机器学习驱动的推荐引擎可能需要近乎实时的数据。

2. 分布：分布异常是指数据值超出可接受的范围。在某些情况下，它可能是一个可接受的异常值，例如在会议期间访问您网站的访问者激增，或者有时这是无稽之谈，例如报告从纽约到洛杉矶的货物发生在几秒钟内。无论哪种方式，这都表明您应该深入研究并进行调查。

3. 卷：卷异常是指数据过多或过少，表明数据源的运行状况可能存在问题。如果 2 亿行突然变成 500 万行，您应该知道。

4. 架构：当数据组织更改时，会发生架构异常。它可以像重命名、添加列或将字段类型从流更改为数字一样简单。当这些更改是意外的（而且通常是意外的）时，它们会破坏下游的流程。

数据团队必须了解这些异常类别，以便他们可以快速评估问题、标记问题并使用添加词汇进行沟通。

对异常进行分类的另一个原因是，数据异常类型有时可能是问题所在（从而加快解决问题的时间）。对于具有该特定平台经验的数据工程师来说尤其如此，他们背负着过去事件的伤疤。

例如，发生数据新鲜度异常的方式有很多种，但是当您看到一种异常时，您应该做的第一件事是检查您的 AirflowDAG以查看作业是否失败。一旦数据使用者通过电子邮件发送了有关数据质量的令人讨厌的说明，就可以手动完成这些检查。不过，更好的方法是实施自动数据监控，以便您的团队是第一个知道的人。

我们敢在破碎的仪表板的阴暗墓地里唱歌，“准备好了吗？

主动数据监控不仅可以保持数据信任并加快检测时间，还可以加快解决问题的速度。

尽管如此，因为有更快的认知跳跃和对因果关系的直观理解 - 或者导致问题的环境中最近可能发生的变化。

评估影响和分类

你还记得土狼匆忙追赶跑路者的时候，低头一看，发现脚下没有地面吗？他行动迅速，但效果不佳，结果一落千丈，陷入了卡通式的死亡。

异常解决方法相同。数据团队花费如此多时间的原因之一是，他们发现自己以相同的努力追逐每一个异常，而不知道何时或是否会从它们脚下掉下来。

换句话说，他们不知道异常的影响是否与响应成正比。例如，如果仪表板在 4 小时内未更新，这是有问题的吗？有时是，有时不是。

避免使用 SPLAT 的一种方法是确定最重要的数据资产，并与业务利益相关者合作创建数据 SLA。与消费者合作以编纂他们的期望和用例，为有效的事件分类提供了必要的上下文。

挑战在于数据资产不断添加，数据消费模式也在不断变化。自动化数据沿袭可以帮助团队在不断变化的环境中有效地识别其关键表。

主动跨团队沟通

沟通对于根本原因分析和异常解决至关重要。第一步是确保正确的数据工程师具有正确的警报。

就像杰克·斯凯灵顿（Jack Kelington）在万圣节比圣诞节好得多一样，数据团队的成员将更有效地解决自己领域或专业领域的异常情况。路由警报和分配任务对于创建所有权和问责制以及避免倦怠至关重要。

为什么要倦怠？好吧，对于团队来说，指派他们最有才华的工程师来帮助扑灭他们可能放火的地方是很诱人的，虽然很紧急，但这项任务也可能很乏味。

这篇关于如何使数据异常解析不那么卡通化的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！