下面是我在尼尔森工作时的实现，这在 Airflow 中使用 Soda 来实施数据质量检查的博客类似。
当我在尼尔森时，还没有一个数据质量的总体框架或平台，所以我们“开发”的只是内部供我们自己使用。我们决定采取一种方法，对我们流程的每个关键部分进行检查。我们将拥有一个运行检查库，然后根据问题的严重性为它们分配不同的严重性级别。这些结果将存储在一个表中，然后根据需要进行标记。
当时，我们没有使用像Deequ或Great Expectations这样的库来运行这些检查。我们只是将它们实现为 Spark 应用程序，我们在其中读取上一步生成的数据并对数据运行适当的检查。如果发现任何严重错误（例如，不应该出现的重复错误），我们将失败该步骤并且我们的管道将因此停止。
实施优点
当发现一个关键的错误时，能够停止你的应用程序绝对是一个适当的行动。毕竟，如果数据有问题，为什么还要继续处理，如果继续处理，问题只会越来越严重？从长远来看，有这样的断路器逻辑是最好的方法，只要关键故障不常见到持续延迟数据交付（尽管这将指向一个更严重的问题）。
为历史目的将结果存储在一个表中总是好的。这允许团队建立DQ故障历史的可视化，这可以帮助指出需要更多调查的更大问题。此外，该设计相当灵活。增加更多的规则或改变严重程度只是一个小小的代码变化。
实施的缺点
这个实现的最大缺点是检查本身。它们都是独立的方法，将运行适当的逻辑，然后收集结果，将它们存储在一个DataFrame中供将来参考。使用一个基本上能做到这一点的库（Deequ有意义，因为我们是以Spark为中心的）肯定会简化事情（而且我们可能会在更多的研究中采取这种方法）。当时，我们并没有想到要使用一个现有的框架，尤其是当这些单元测试方法在构建过程中已经存在于代码中时。
结论
考虑到我们当时开发了一个内部的数据质量解决方案，我觉得我们的方法是很靠谱的，这也反映在Airflow能用Soda做的事情上（把检查作为自己的步骤来运行，必要时失败，以实现断路）。更大的问题是，当你的应用程序不在一个直接的管道中时，该怎么做。
当涉及到微服务设计时，并没有明确区分一个步骤何时结束，下一个步骤何时开始。这就是像数据核对这样的方法更有意义的地方，这样数据可以在各层之间进行比较，并在必要时加以标记。由于我们没有一个管道将所有的事情联系在一起，所以这是由我们决定的节奏运行。
当然，一个正确实施的数据质量平台有可能照顾到所有这些。毕竟，能够连接到仓库层以外的数据，肯定会简化事情。