通过节点选择进行dbt代码审查中的数据验证

如果你使用 dbt 有一段时间了，你可能知道 节点选择 有多么方便。它可以通过只运行更新项目后的指定资源来省时省算力。例如，非常有用的 state:modified+ 选择器可以让你只运行修改了的资源及其下游依赖，将你的构建范围限制在项目中修改的部分。

在这篇文章里，我将展示如何将相同的节点选择逻辑应用于dbt项目的数据检查中，作为PR审查的一部分来执行。这里说的不是dbt测试，而是用于自动化数据验证的检查，确保你的[关键模型]覆盖，无论你在数据链的哪个环节工作。

更新你的dbt项目中的模型后，你首先想看到的是数据变化的影响，你很可能只关心变化。例如：

• 展示我的dbt项目更新前后的数据不一致，
• 帮我用视觉的方式来调查这些变化

这在大型项目中可能非常棘手，因为一个模型的改动可能会影响到许多后续模型。手动检查太繁重了，你最不想的就是在数据中玩“找不同”的游戏，试图用肉眼看出开发与生产数据间的差异。

只需看一下Mattermost数据仓库的这一部分视图，这包含大约200个模型的项目：

Mattermost数据仓库的lineage 保持原文不变，若需翻译可使用“血缘关系”或“谱系”。

大型 dbt 项目可能很难处理和评估其影响。

在一个大型项目中进行修改后，你该如何检查所有受影响的模型？

• 手动检查这些模型？这可真是不少活儿。
• 设置全项目检查？这会检查很多与问题无关的资源。

在这里，节点选择特别有用。您可以按照条件过滤模型和资源。这里有一个来自Mattermost项目的实际PR示例，只显示modified+模型。

节点选择有助于界定范围并确定数据来源，从而使影响评估更加容易操作

这给你提供了一个更易于管理的谱系图，但每次PR时，受影响的区域会发生变化，因此你需要一种自动为受影响区域内的所有模型执行检查的方法。

你知道如何使用节点选择来选择资源的子集。使用Recce，你可以对这些节点组进行批量数据验证检查，使用与dbt相同的节点选择的语法。

• 不用为每个单独的模型写检查
• 不用为每个PR写检查

以下是一个 Recce 的示例配置，它会完成以下任务：

• 行数差异检查 在 modified+ 表中
• 模式差异检查 在 modified 模型之间

    checks:  
    - name: 行数差异检测  
      description: 检查所有表模型的行数差异情况  
      type: row_count_diff  
      params:  
        select: state:modified+,config.materialized:table  
    - name: 架构差异检测  
      description: 检查已修改模型的架构差异  
      type: schema_diff  
      params:  
        select: state:modified

无需指定任何具体的模型——使用select选项，选择语法允许你匹配所有匹配的资源。

如果任何模型不匹配，Recce 会在您的 PR 评论线程中发布的检查摘要中显示出来。

侦察报告摘要将指出哪些资源的数据存在不一致的地方。

然后你就可以用审查模式启动Recce，查看具体发生了哪些变化，找出问题的真正原因。

节点选择的美妙之处在于，你可以按照自己的意愿选择要检查的模型。

• 只想检查关键模型？只需使用一个 tag。
• 只想检查修改过的模型吗？使用 modified。
• 只想检查物化表？使用 config.materialized:table。

你可以将模型分组归类并给它们打标签，然后对这些模型进行特定检查。不管项目中发生了什么，只要这些模型位于受影响区域内的，就会被检查。

Recce 包含基于节点选择的数据检查功能，其中包括其数据验证套件。现在就可以下载 Recce OSS，Recce Cloud 也即将推出。快来看看！