以下为作者观点，来看看你认同吗？

如果西西弗斯（编者注：希腊神话中的人物）是一个数据分析师或数据科学家，他在山上滚动的巨石将是他的数据质量保障。即使所有获取、处理和建模的工程流程都无懈可击，但在数据管道的任何阶段测试数据质量的能力，以及面对 "Is this OK "的问题，已经够难了。

为什么呢？因为很难定义OK的含义。

传统上，数据质量被分成6个方面。

• 准确性：一项信息在多大程度上反映了现实？
• 完备性：它是否满足你对全面性的期望？
• 连贯性：存储在一个地方的信息与存储在其他地方的相关数据是否一致？
• 及时性：当你需要时，你的信息是否可用？
• 有效性：信息是否有特定的格式、类型或大小？它是否遵循业务规则/最佳实践？
• 完整性：不同的数据集能否被正确地连接起来，以反映一个更大的画面？关系是否被很好地定义和实施？

这些维度是在对设计数据仓库采取广泛的观点时定义的。考虑了所有定义和收集的数据集，它们之间的关系，以及正确服务于组织的能力。

当我们看一个单一的数据集时，我们的质量考虑就比较“狭窄”:

• 它不需要完整性，因为其他数据集可能会弥补。
• 一致性和完整性是不相关的，因为其他数据集没有被考虑。
• 时效性主要取决于工程管道的运作，而不是数据的质量。

在我们的案例中，问一个数据集是否可以，等于问 “它是否有效和准确？”。

在这篇文章中，我将描述有效性测试，分解准确性测试的概念，并回顾现有的测试框架。

验证：元数据测试

元数据是描述数据的信息，而不是数据本身。例如，如果数据是一个表，元数据可能包括模式，例如列的数量，以及每一列中变量的名称和类型。如果数据是在一个文件中，文件格式和其他描述性参数，如版本、配置和压缩类型可能是元数据的一部分。

测试的定义很直接：对元数据的每个值都有一个期望，这个期望来自于组织的最佳实践和它必须遵守的规定。如果你是一个软件工程师，这种类型的测试非常像一段代码的单元测试。就像单元测试覆盖率一样，可能需要一些时间来创建所有这些测试，但达到高测试覆盖率是可能的。

每当元数据改变时，维护测试也是需要的。当然期望值往往有差距，当我们习惯于在改变代码时更新我们的单元测试时，我们必须愿意投入同样的时间和注意力，在我们的模式演变时维护元数据的验证。

数据准确性的三种类型

类型1：入门级的事实核查

我们收集的数据来自于我们周围的现实，因此它的一些属性可以通过与已知记录的比较来验证，例如:

• 这个地址是真实的吗？
• 这是一个活跃的网页吗？
• 我们是否出售这个名字的产品？
• 对于价格栏，其数值是否为非负值？
• 对于一个强制性的字段，它不是空的吗？
• 值来自于一个给定的范围，所以最小和最大是已知的。

获取验证值通常需要查询另一个能够可靠地提供答案的数据集。这个数据集可以是公司内部的，比如人力资源系统中的雇员记录。以及公司外部的来源，如街道、城市、国家注册数据库等。

一旦获得了验证值，测试本身就是一个简单的比较/包含查询，其准确性仅限于所用的外部数据集的准确性。

这个测试验证了数据本身，而不是其元数据。最好是在收集数据的时候尽可能地进行这种验证，以避免准确性问题。例如，如果数据是由一个人填表收集的，数字表格可以只提供有效的选项。由于这并不总是可能的，建议在获取阶段对数值进行验证。

类型2：设置级别健全性

事实核查是测试单一记录中的一个值。当涉及到大数据时，我们需要测试我们拥有的集合的属性。这个集合可能包括来自某个时间段的数据，来自某个操作系统的数据，ETL过程的输出，或者一个模型。不管它的来源是什么，它作为一个集合都有我们想要验证的特征。这些特征是统计学上的，比如说：

• 数据预计来自于一个给定的分布。
• 平均数、方差或中位数的值被预期在一个给定的范围内的概率很高。

统计学测试仍然需要你知道预期，但你的预期现在有了不同的形式。

• 这个数据来自这个分布的概率够高吗？
• 这一栏的平均值应该在这个范围内，概率为95%。

想象一下，一张保存着扑克游戏中发给玩家的手牌的表格。在这种情况下，可以预先计算出手牌的预期分布。

我们进行的测试将查看持有发牌手数的那一列的数值，并询问，这组数值来自预期分布的概率是多少？

在这个统计测试中，定义通过/失败的参数将必须是概率性的。如果分布是均匀的，概率小于X%，你会得到一个警报。当然，你宁愿手动检查一个被警告的数据集，也不愿意让一个错误连带着进入你的数据管道。

类型3：基于历史的集合级别的正确性

就像统计准确性测试一样，我们要看的是一组记录的属性。只是在这种情况下，我们没有一个现实世界的真相来源可以依赖。我们有数据集本身的历史：同一个数据集随着时间的推移而演变。

我们可以使用这些历史数据来创建一个数据特征的基线，然后测试今天的新数据集是否与基线一致。

我们可以从历史数据中推断出一些特征的例子。

• 某一列中数值的期望值和方差。
• 某一列中数值的分布，如一天中每分钟的事件数量。
• 寻找数据的特征和它们的预期分布。
• 预计随着时间的推移，会有一定的季节性，例如黑色星期五的销售高峰，周末的流量较少。
• 运行异常检测算法，查看特征的历史，看看当前的值是否正常。

学习基线不仅为测试结果增加了概率方面，也为基线值的有效性增加了概率。我们执行与类型2相同的统计测试，但我们对其正确性有一个额外的风险，因为我们所比较的基线只有一定的概率是正确的，因为它是从历史数据中统计推导出来的。

我们还应该进行这个测试吗？如果基线正确的概率足够高，而且你明智地使用了阈值，那么绝对应该。建议你记住，警报系统需要在假阳性和假阴性之间取得平衡。

• 假阴性:测试失败，而它本应通过。
• 假阳性:测试通过了，而它应该是失败的。

你应该根据业务需要，以优化所需错误的方式构造你的测试。你会有错误，所以要确保你有你能接受的错误，而且是高概率的。

推荐几个数据质量测试框架工具

Deequ

一个来自AWS实验室的开源工具，可以帮助你定义和维护你的元数据验证。Deequ是一个建立在Apache Spark之上的库，用于定义 “数据的单元测试”，衡量大型数据集的数据质量。Deequ适用于表格数据，例如CSV文件、数据库表格、日志、扁平化的json文件。基本上任何你能装入Spark数据框架的东西。

该项目正在努力发展到上述的准确性测试，但其主要能力是在验证领域内。

Great Expectations

同样专注于验证，这个开源工具允许轻松地集成到你的ETL代码中，并可以测试来自SQL或文件接口的数据。由于它的结构是一个日志系统，它可以通过文档格式使用，并从定义的测试中创建自动文档。它还提供对数据进行剖析，并自动生成测试期间断言的预期。

Torch by Acceldata

Torch允许使用一个基于规则的引擎进行验证。可以根据你自己的领域专业知识和Torch提供的大量规则来定义规则。该系统提供了一些与数据集历史分析有关的能力，但这些都是非常基本的第二类测试。Acceldata为数据管道的可观察性提供了一套更广泛的工具，涵盖了数据质量的6个维度的其他方面，Torch是其模块之一。

OwlDQ

OwlDQ是基于对数据集的动态分析和对预期的自动适应。规则允许对要跟踪的特征进行定义，以及通过/失败的概率，但繁重的数据特征分析则留给了OwlDQ引擎。

MonteCarlo

这是一个无代码的实现可观察性平台。它使用机器学习来推断和学习你的数据是什么样子的，主动识别数据问题，评估其影响，并通过与普通运营系统的集成发出警报。它还可以进行根本原因分析。

Databand

一个管道元数据监控工具，也提供开箱即用的数据质量指标（如数据模式、数据分布、完整性和自定义指标），无需修改代码。

---

资源分享

下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】