重要的不是数量，而是质量。
在过去的一年里，数据质量已经被广泛讨论。数据合同、数据产品和数据可观察性工具的日益采用无疑表明数据从业者致力于向其消费者提供高质量的数据。我们都喜欢看到这一点！
数据解决方案中的一个基本构建模块是数据测试。这是验证数据质量的最基本和实用的方式之一，并且明确或隐含地嵌入在许多数据解决方案中。
虽然数据团队的效果为数据团队带来了显著的好处，但它也引发了如何最大限度地发挥其潜在价值的问题，因为拥有更多的测试并不一定意味着拥有更高的数据质量。在本文中，我想向您展示一些设计数据测试的方法。希望这些方法能为您提供一些启示。
值得注意的是，建议您结合这些方法，找到最适合您的平衡点。
质量>数量
我是那些喜欢创建测试的人之一，因为它们为我的解决方案增加了信心。作为一名软件工程师，我曾经奉行“测试越多，越好”的信条。我总是对提供简单数据测试创建方法的数据框架感到兴奋。
然而，我低估了拥有过多数据测试的副作用。（甚至有副作用吗？是的！）让我们首先了解数据测试和单元测试（即逻辑测试）之间的区别。简单来说，单元测试旨在验证我们编写的代码逻辑的正确性。我们拥有的单元测试越多，我们对处理边缘情况的能力就越有信心。但是数据测试超越了代码逻辑，它还检查源数据质量、数据管道配置、上游依赖等。指标是无穷无尽的，可能会让人不知所措。很容易创建大量测试以防万一，但它们并不总是带来价值，并可能引入不必要的干扰。例如，面对现实吧，如果数据管道只偶尔被用户使用，不是每个数据管道都需要进行每日新鲜度测试，并且数据管道中的所有阶段都不需要进行相同的测试。重复的数据测试只会导致冗余的警报。
有一次，我迷失在创建数据测试中，并最终得到了许多冗余的测试，导致了错误的警报。我认识到，为了确保数据质量，我们首先需要确保数据测试的质量。数量并不一定与质量相关。
适用性
数据可以被视为一种产品。数据管道可以被视为接收原始数据输入并生成数据产品的数据制造系统。虽然数据消费者不购买数据，但他们可以决定是否使用它，并根据需求和反馈提供要求。
“适用性”这个概念在衡量质量方面得到了广泛应用。它强调了捕捉客户的全部声音的重要性，因为最终是消费者决定产品的成功与否。例如，建造一座大学图书馆时，关键是要考虑到学生和教师，意味着它应该具备涵盖各种兴趣和教育需求的书籍和资源。
当涉及到数据产品时，一个很好的例子是报告数据。为了被认为是有价值的，工程师应该与利益相关者密切合作，了解对准确性、可靠性、完整性、及时性等方面的法规要求，然后相应地创建数据测试。
这种方法是测试创建旅程的一个良好起点，特别是当数据消费者对其需求有清晰的愿景并对数据质量有很好的理解时。它可以让数据工程师的生活变得更轻松。然而，仅仅依靠利益相关者的要求通常是不够的，因为他们从外部视角评估数据，而没有考虑到上游依赖和技术错误。在这种情况下，下一节中的数据质量框架将帮助我们涵盖大多数情况。
数据质量维度
从消费者的角度来看待数据质量无疑是一个有价值的初始步骤。但这可能无法涵盖测试范围的完整性。广泛的文献综述为我们解决了这个问题，提供了一系列与大多数使用情况相关的数据质量维度。建议与数据使用者一起审查该列表，并共同确定哪些维度适用，并相应地创建测试。
| 准确性 | 格式 | 可比性 || 可靠性 | 解释性 | 简洁性 || 及时性 | 内容 | 无偏见 || 相关性 | 效率 | 信息量 || 完整性 | 重要性 | 详细程度 || 货币性 | 充分性 | 数量化 || 一致性 | 可用性 | 范围 || 灵活性 | 有用性 | 可理解性 || 精确度 | 清晰度 | |您可能会发现这个列表太长，想知道如何开始。数据产品或任何信息系统可以从两个角度观察或分析：外部视图和内部视图。
外部视图
外部视图涉及数据的使用以及与组织的关系。它通常被视为一个“黑箱”，具有代表现实世界系统的功能。属于外部视图的维度高度受业务驱动。有时，对这些维度的评估可能是主观的，因此并不总是容易为它们创建自动化测试。但让我们看看一些众所周知的维度：
- 相关性：数据适用于分析的程度。考虑一个旨在推广新产品的市场活动。所有数据属性应直接促成活动的成功，例如客户人口统计数据和购买数据。城市天气或股市价格等数据在这种情况下是无关的数据。另一个例子是详细程度（粒度）。如果业务希望市场数据以日为单位存在，但数据以周为单位提供，那么它就不相关和有用。
- 表达：数据对数据使用者是否可解释以及数据格式是否一致和描述性的程度。在访问数据质量时，通常会忽视表达层的重要性。它包括数据的格式——保持一致和用户友好的格式，以及数据的意义——易于理解。例如，考虑一个预期以CSV文件形式提供的数据，具有描述性的列描述，并且预期值以欧元货币而不是以分为单位。
- 及时性：数据对数据使用者来说是否是最新的。例如，业务需要从销售时点起的销售交易数据，最大延迟不超过1小时。这意味着数据流水线应该经常刷新。
- 准确性：数据是否符合业务规则的程度。数据度量通常与复杂的业务规则相关，例如数据映射、舍入模式等。强烈建议对数据逻辑进行自动化测试，数量越多越好。
在这四个维度中，当涉及到创建数据测试时，及时性和准确性更为直接。通过将时间戳列与当前时间戳进行比较可以实现及时性。通过客户查询可以进行准确性测试。
内部视图
相比之下，内部视图关注的是与特定要求无关的操作。无论手头有哪些使用情况，它们都是必不可少的。内部视图中的维度更多地是技术驱动的，与外部视图中的业务驱动的维度不同。这也意味着数据测试不太依赖于使用者，并且通常可以自动化。以下是一些关键观点：
- 数据源质量：数据源的质量显著影响最终数据的整体质量。数据合同是确保源数据质量的一种很好的方法。作为源数据的数据使用者，我们可以采用类似的方法来监控源数据，就像数据利益相关者在评估数据产品时所做的那样。
- 完整性：信息保留完整性的程度。随着数据管道的复杂性增加，中间阶段可能发生信息丢失的可能性更大。让我们考虑一个存储客户交易数据的金融系统。完整性测试确保所有交易都能成功地在整个生命周期中传递，没有遗漏或遗漏。例如，最终帐户余额应准确反映实际情况，捕捉每笔交易而没有任何遗漏。
- 唯一性：这个维度与完整性测试密切相关。完整性保证了没有遗失，而唯一性确保数据中没有重复。
- 一致性：数据在每天的内部系统中的一致性程度。数据不一致是一个常见的数据问题，通常源自数据孤岛或不一致的度量计算方法。一致性问题的另一个方面发生在数据预计具有稳定增长模式的天之间。任何偏差都应引起进一步调查。
值得注意的是，每个维度都可以与一个或多个数据测试相关联。关键是理解将维度适用于特定的表格或指标。只有这样，采用的测试越多，效果越好。
到目前为止，我们已经讨论了外部视图和内部视图的维度。在未来的数据测试设计中，考虑外部和内部的观点非常重要。通过向合适的人提问正确的问题，我们可以提高效率，减少沟通不畅。
关于数据测试的更多提示
在上一节中，我想分享一些创建数据测试的实用技巧。这些技巧来自我日常的工作，但欢迎在评论中分享更多。
- 错误数据与无数据：在许多数据解决方案中，数据测试通常在模型更新后进行。这意味着在我们意识到问题时，数据已经变得“损坏”。如果您更喜欢“无数据”而不是“错误数据”，您可以首先将表格实例化到临时位置，然后进行测试。只有在测试通过后，流程才会将表格复制到原始目标位置；否则流程将停止。
- 对账测试：对账测试是一种数据验证过程，用于比较两个或多个系统之间的数据的一致性和准确性，通常是源和目标数据集之间的比较。例如，设计了两个流水线来处理交易，值得比较两个系统和源的总交易金额。任何差异的存在可能表明数据流程中存在缺陷。
- 带有余量的测试：我们可能会从利益相关者那里得到这样的说法：“这一列中的0是可以接受的，但应避免出现过多的值。”这意味着他们希望捕捉到与一致模式偏离的情况。许多现代数据监控工具提供异常检测功能，但如果对您来说不是一个选项，您可以开始创建带有余量的测试。例如，不超过总行数的5%应该具有值0。
结论
如常，我希望您能发现本文有用和启发性。关键是避免过多关注您创建的数据测试的数量。在每一列上添加相同的测试没有意义，只会产生很多噪音，降低您的生产力。
在与数据消费者和数据提供者交谈之前，请牢记数据质量框架。聪明地提问，并利用框架激发利益相关者考虑数据的其他角度。干杯！
参考资料
- 将数据质量维度锚定在本体基础上
- 超越准确性：数据质量对数据消费者的意义