数据团队关键核心资产是给消费者提供可信赖的数据。如果提供了不被信任的数据，那么支持决策智能依赖于猜测和直觉。原始数据从不同来源被摄取智数据仓库，数据产品团队有责任定义转换逻辑，将源数据整合到有意义的数据产品中，用于报告和分析。敏捷数据产品团队在将数据用于分析和决策制定之前，使用自动化的数据质量测试来检查他们提供数据的有效性。
在这篇博文中，我们将介绍如何使用dbt通过不同类型的测试探测数仓中存储的数据。我们假设您对如何设置dbt有基本的了解，并且您有一个正在工作的项目。如果没有，请查看这篇关于如何在dbt中设置项目的博客文章。
通常数据质量保证是通过在DW上采用SQL查询的测试规范来执行的。有不同类型的测试规范，例如内部和外部一致性检查、KPI验证或访问验证。我们还可以在结构级别上探测传入数据，例如，交付数据的模式是否与已知结构相对应。
dbt提供了多种测试实现方式，可以使用" dbt test "命令执行测试用例。下面我们分别进行说明。
单一测试模型
我们先来谈谈单一测试模型，我们需要定义返回记录的SQL语句，这些记录没有通过某个条件。它们在项目的tests目录中(dbt默认为“tests”)定义sql文件。例如，我们检查交易数据的税率是否为正数百分比值:
SELECT order_id
FROM {{ ref( ‘inb_transaction’) }}
WHERETaxPercent < 0
此测试将返回所有具有负税率的交易，便于用户进一步检查非期望测试结果。
顾名思义，单一测试意味着单个测试。如果您发现反复编写类似的单一测试是重复工作，那么是时候切换到通用测试了。一般来说，通用测试是接受参数的参数化查询。它们可以作为属性添加到.yml文件中的现有模型上。
通用测试
DBT附带了四个“开箱即用”的通用测试:unique、not_null、accepted_values和relationships。例如，你希望验证源表和目标表之间数据一致性。下面是一个检查order_id的例子:
version 2:models:- raw_transactionscolumns:- order_idtests:- relationships:to: ref('inb_transactions')field: order_id
第三方测试
除了dbt-core自带的4个测试之外，还有像dbt_expectations这样的包，它们扩展了dbt的测试功能。例如我们添加dbt_expectations测试用于检查shipping_date是否只包含date类型的值。
version 2:models:- raw_transactionscolumns:- order_idtests:- relationships:to: ref('inb_transactions')field: order_id- shipping_datetests:- dbt_expectations.expect_column_values_to_be_of_type:column_type: date
知名dbt-utils包中也提供一些非常好用的测试方法，读者可阅读我的系列博文。
自定义宏测试
第三种选择是使用宏自定义宏测试。例如，我们可以将计算结果与来自不同分析的已知值进行比较。
在下面的示例代码中，我们计算去年的总营业额，并将其与年度报告中公布的值进行比较。这是典型的数据库回归测试，确保即使在进行了一些修改之后，数据库的完整性仍然保持不变。
{% test trx_sum_test(model, column_name, test_value, test_year) %}
WITH temp AS (SELECTSUM({{ column_name }}) AS trx_sumFROM{{ model }}WHEREEXTRACT(YEAR from RefDateTime) = {{ test_year }}
)
SELECT*
FROMtemp
WHEREtrx_sum != {{ test_value }}
{% endtest %}
然后将此测试添加到其他测试中:
version 2:models:- raw_transactionscolumns:- order_idtests:- relationships:to: ref('inb_transactions')field: order_id- shipping_datetests:- dbt_expectations.expect_column_values_to_be_of_type:column_type: date- TransactionAmounttests:- trx_sum_test:test_value: 1000000test_year: 2021
测试分组
dbt 另一个有用的特性是使用tag标记对测试进行分组。请看示例：
version 2:models:- raw_transactionscolumns:- order_idtests:- relationships:to: ref('inb_transactions')field: order_idtags: ["test_group1"]- shipping_datetests:- dbt_expectations.expect_column_values_to_be_of_type:column_type: datetags: ["test_group1"]- TransactionAmounttests:- trx_sum_test:test_value: 1000000test_year: 2021tags: ["test_group2"]
使用这些标记，可以在运行时选择要运行的特定测试。
示例 : dbt test——select tag:test_group1
总结
确保数据符合质量标准可能非常耗时，因为需要运行很多且计算成本高的测试。为了避免延迟向最终用户交付数据的工期，最好定义所谓的“冒烟测试”。这些测试很快，并且在使数据可访问之前运行，从而及时发现数据中可能存在的问题。更多细粒度的测试(可能需要一些时间才能完成)可以在加载之后进行，使用这种方法可以在上线时间和数据质量之间进行合理的权衡。
利用dbt的测试能力和特性，我们就拥有了数据质量保障工具。让我们及时发现数据质量问题，并确保在数据发布使用之前解决这些问题，最终基于可信的数据驱动决策。期待您的真诚反馈，更多内容请阅读数据分析工程专栏。
)
)
)
