批处理中的数据质量如何保证? - Weingarten

22-09-20 banq

下面是我在尼尔森工作时的实现,这在 Airflow 中使用 Soda 来实施数据质量检查的博客类似。

当我在尼尔森时,还没有一个数据质量的总体框架或平台,所以我们“开发”的只是内部供我们自己使用。我们决定采取一种方法,对我们流程的每个关键部分进行检查。我们将拥有一个运行检查库,然后根据问题的严重性为它们分配不同的严重性级别。这些结果将存储在一个表中,然后根据需要进行标记。

当时,我们没有使用像DeequGreat Expectations这样的库来运行这些检查。我们只是将它们实现为 Spark 应用程序,我们在其中读取上一步生成的数据并对数据运行适当的检查。如果发现任何严重错误(例如,不应该出现的重复错误),我们将失败该步骤并且我们的管道将因此停止。

实施优点
当发现一个关键的错误时,能够停止你的应用程序绝对是一个适当的行动。毕竟,如果数据有问题,为什么还要继续处理,如果继续处理,问题只会越来越严重?从长远来看,有这样的断路器逻辑是最好的方法,只要关键故障不常见到持续延迟数据交付(尽管这将指向一个更严重的问题)。

为历史目的将结果存储在一个表中总是好的。这允许团队建立DQ故障历史的可视化,这可以帮助指出需要更多调查的更大问题。此外,该设计相当灵活。增加更多的规则或改变严重程度只是一个小小的代码变化。

实施的缺点
这个实现的最大缺点是检查本身。它们都是独立的方法,将运行适当的逻辑,然后收集结果,将它们存储在一个DataFrame中供将来参考。使用一个基本上能做到这一点的库(Deequ有意义,因为我们是以Spark为中心的)肯定会简化事情(而且我们可能会在更多的研究中采取这种方法)。当时,我们并没有想到要使用一个现有的框架,尤其是当这些单元测试方法在构建过程中已经存在于代码中时。

结论
考虑到我们当时开发了一个内部的数据质量解决方案,我觉得我们的方法是很靠谱的,这也反映在Airflow能用Soda做的事情上(把检查作为自己的步骤来运行,必要时失败,以实现断路)。更大的问题是,当你的应用程序不在一个直接的管道中时,该怎么做。

当涉及到微服务设计时,并没有明确区分一个步骤何时结束,下一个步骤何时开始。这就是像数据核对这样的方法更有意义的地方,这样数据可以在各层之间进行比较,并在必要时加以标记。由于我们没有一个管道将所有的事情联系在一起,所以这是由我们决定的节奏运行。

当然,一个正确实施的数据质量平台有可能照顾到所有这些。毕竟,能够连接到仓库层以外的数据,肯定会简化事情。