数据质量测试是在使用数据集之前验证数据集的关键特征是否符合预期的过程。
根据Gartner的数据，不良数据平均每年给企业造成1290万美元的损失。事实上，Monte Carlo自己的研究发现，数据工程师每天要花费多达40%的时间来处理不良数据。
这些都是很大的数字。数据质量问题是现代数据团队面临的一些最严峻的挑战，而测试是数据团队在获得可靠数据的过程中所采取的第一步。
不管是错误还是熵，当数据在生产管道中移动时必然会出现异常。在这篇文章中，我们将介绍你现在验证数据所需的 7 项基本数据质量测试；另外，你现在可以应用数据质量测试的一些方法开始构建你的数据质量行动。
01
那么，什么是数据质量测试？
当谈到数据工程时，质量问题是一个不可避免的事实。与所有的软件和数据应用程序一样，ETL/ELT系统有时容易出现故障。
除其他因素外，如果满足以下条件，数据管道是可靠的：
• 数据是最新的、准确的和完整的。
• 数据是唯一的，没有重复的。
• 这个模型是合理的，代表了现实。
• 转换后的数据没有异常。
虽然没有解决数据质量问题的有效方法，但数据质量测试使工程师能够预测特定的已知问题，并编写逻辑来主动检测质量问题，以免影响下游用户。
现在，我们已经对什么是数据质量测试有了一个共同的理解，让我们看看你现在可以运行的一些最常见的数据质量测试，以及如何使用它们来检测数据中的质量问题。
02
NULL值测试
最常见的数据质量问题之一是数据丢失，也称为NULL值。
当字段留空时，无论是有意还是由于管道错误（例如API中断导致的错误），都会出现NULL值。假设你正在按区域查询营销计划对销售额提升的影响，但多条记录中的“区域”字段留空。任何缺少“区域”的行都必然会从报告中排除，从而导致未来在区域营销计划上的支出效率低下。
顾名思义，NULL值测试将在模型运行后验证特定模型的指定列中的值是否缺失。dbt的通用not_null测试是一种很好的用于发现NULL值的开箱即用测试。
演示：tests/test_not_null.sql
{% test not_null(model, column_name) %}
select *
from {{ model }}
where {{ column_name }} is null
{% endtest %}
03
容量测试
数据是否传入？数据是太少了还是太多了？这些都是与进入数据库的数据量相关的数据质量问题。
容量测试是一项必备的质量检查，可用于验证关键表中包含的行数。
缺失的数据
假设你的数据平台处理来自温度传感器的数据，其中一个传感器出现故障，会发生什么呢？你可能会得到一堆疯狂的温度值，或者你可能什么都得不到。
缺失数据会很快使数据模型或仪表盘出现偏差，因此数据质量测试程序必须快速识别数据量是否因缺失数据而发生变化。数据量测试将使您能够识别数据量何时发生变化，从而发现故障点并验证数据的准确性。
数据过多
过多的数据听起来可能不是问题(毕竟它被称为大数据)，但当行按比例填充时，它会降低模型性能并增加计算成本。监控数据量的增加可以通过利用干净的高质量数据来帮助降低成本并保持模型的完整性，从而对下游用户产生影响。
容量SLIs
SLAs(服务水平协议)对现代数据可靠性运动至关重要，而容量SLIs是衡量指定SLA性能的指标。
容量测试可用于通过监控表大小或表增长(相对于以前的测量)来测量SLIs。例如，如果你正在测量绝对表大小，则会在以下情况下触发事件：
• 当前总大小(字节或行)减少到特定的量
• 当前总大小在特定时间内保持不变
04
数字分布测试
我的数据是否在可接受范围内？我的值是否在给定列的范围内？
这些问题都可以用分布检验来回答。用学术术语来说，分布检验就是验证给定表格中的数据是否代表正态分布的群体。从本质上讲，这些数据是否反映了现实？
通过定义给定列的最小值和最大值，可以很容易地在SQL中创建这些规则。
开箱即用分布测试的一个很好的例子是dbt的accepted_values测试，它允许创建者为给定的列定义一系列可接受的分布值。
Great Expectations还提供了一个通用的“单元测试”库，可适用于你的发行版数据质量测试。例如，如何使用Great Expectations单元测试来确保“zip_code列”表示有效的邮政编码：
演示：
expect_column_values_to_be_between( column="zip_code", min_value=1, max_value=99999)不准确的数据
就像缺失的数据可能会描绘出一幅虚假的现实画面一样，不准确的数据同样会对数据模型造成损害。不准确的数据是指由于数据集的不正确表示而产生的分布问题。不准确的数据可能很简单，比如医生错误地输入了病人的体重，或者SDR在收入数字上多加了一个零。
对于医疗保健和金融机构等需要严格监管的行业来说，创建分布式监控来识别不准确的数据尤为重要。
数据多样性
有时，进入表中的新值不符合典型分布。这些值不一定是异常的，但也可能是异常的。当涉及到数据质量时，“可能”通常是我们想要关注的。
将分布测试作为数据质量测试工作的一部分，有助于主动监控新的和唯一的值，从而发现潜在的异常数据，这些数据可能表明未来存在更大的问题。
05
唯一性测试
困扰数据工程师和下游用户的另一个常见质量问题是重复数据。重复数据是指被复制并共享到数据库中另一个数据记录中的任何数据记录。
如果没有适当的数据质量测试，重复数据可能会造成各种各样的破坏，如从垃圾邮件和降低个性化程序到不必要地增加数据库成本和造成声誉损害(例如，重复的社会安全号码或其他用户id)。
出现重复数据的原因多种多样，从松散的数据聚合过程到人工输入错误，但最常见的情况是在系统之间传输数据。
唯一性测试使数据团队能够以编程方式识别重复记录，以便在进入生产仓库之前对原始数据进行清理和规范化。
如果你使用dbt，则可以使用唯一性测试来验证数据是否存在重复记录，但根据你与数据堆栈集成的内容，可以轻松地为各种工具提供开箱即用的唯一性测试。
06
参照完整性测试
参照完整性是指数据库中表之间的父子关系。主键也称为主键和外键，它是跨表连接的根数据，用于创建模型和获得见解。
但是，如果用于主键的数据被更改或删除，会发生什么情况呢？这就是参照完整性测试的用武之地。参照完整性测试在dbt中称为关系测试，它确保子表中反映的任何数据都有相应的父表。
假设你的营销团队正在提取客户ID列表，以便为假期创建个性化活动。你的营销团队如何知道这些客户ID映射到有姓名和地址的真人？参照完整性数据质量测试确保在不跨依赖表共享相同更改的情况下，无法对父键或主键进行任何更改。
07
字符串模式
在当今的分布式世界中，发现各种人因错误导致的数据差异并不罕见。也许潜在客户忘记了电子邮件地址中的某个字符，或者分析师无意中更改了一行而没有意识到。谁知道呢！
由于数据不一致相当常见，因此通过数据质量测试定期对这些记录进行核对非常重要，以确保你的数据保持干净和准确。
使用像RegEx这样的字符串搜索算法是验证列中的字符串是否匹配特定模式的绝佳方法。字符串模式可用于验证各种常见模式，如UUID、电话号码、电子邮件、数字、转义字符、日期等。
08
新鲜度检查
所有的数据都有保质期。当数据定期刷新时，数据会准确描绘数据源。当数据变得陈旧或过时时，它就不再可靠，因此对下游消费者也不再有用。
而且，当你的下游消费者的仪表盘没有被刷新时，你可以随时通知他们。
新鲜度检查通过根据预定义的延迟规则监视数据更新的频率来验证表中数据的质量，例如你期望在任何给定日期加载摄取作业的时间。
可以使用SQL规则手动创建新鲜度测试，也可以在某些ETL工具(如 dbt source freshness 命令)中本地创建。
新鲜度SLIs
与编写SQL规则来验证容量SLIs的方式相同，你可以创建SQL规则来验证数据的新鲜度。在本例中，SLI类似于“数据集刷新后的小时数”。
与你的SLI一样，为SQL规则选择的阈值将取决于批量(或流式)数据的正常节奏以及你在新鲜度SLA中达成的协议。
09
测试是耗时的
现在，你的数据质量测试库中已经有了一些基本的数据质量测试，那么是时候开始了!但请记住，数据可靠性是一段旅程。数据质量测试只是你前进道路上的第一步。
随着公司数据需求的增长，你的手动数据质量测试程序可能难以跟上。即使是最全面的数据质量测试程序也无法解决所有可能的问题。如果数据质量测试可以覆盖你所知道的数据可能发生的情况，我们就需要一种方法来监控和警告我们不知道的可能发生在你的数据上的情况(我们未知的未知数)。
• 容易预测的数据质量问题：对于这些已知的未知问题，自动化数据质量测试和手动阈值设置应该涵盖你的基础。
• 不容易预测的数据质量问题：这些是你未知的未知数。随着数据管道变得越来越复杂，这个数字只会越来越大。
尽管如此，即使有了自动化的数据质量测试，随着数据生态系统的发展和数据的演变，继续更新现有测试和阈值、编写新测试和弃用旧测试和阈值仍然需要很大的提升。随着时间的推移，这个过程变得乏味、耗时，并导致你以后需要偿还更多的技术债务。
这就是利用机器学习来检测数据异常如此强大的原因。它解释了未知的未知因素，并且可以根据你的数据环境进行扩展。
如果数据可靠性已列入你明年的路线图，请考虑超越数据质量测试，采用更加自动化、规模化的数据质量方法。
文章来源：赛希咨询微信公众号