如何验证这些更改？一份用于dbt项目的模型验证指南

拉取请求评论模板是数据项目最佳实践的重要组成部分。PR评论是你工作检查过程中的尽职记录，记录了你在检查工作时所做的努力和关注点。

PR评论模版在软件工程中极为常见，现在也开始在数据项目中流行起来，但采用的步伐较为缓慢。还有很多团队尚未采用正式的PR评论模版，但如果数据对业务至关重要，那么采用正式的PR评论模版是必不可少的。

PR评论有效是因为你遵循一套预设的步骤，这些步骤能帮你更好地思考你完成的工作，并确保你正确地进行了测试，以此保证你的工作得到了正确的验证。

PR评论检查表通常侧重于代码，这在软件项目中是有道理的，因为软件本质上就是代码。因此，清单大部分内容都与编码标准和使用有关。

对于数据项目而言，代码就是你的SQL语言，并且会有SQL必须遵循的标准以及验证方法（详见此处）。但数据项目本身也包含数据（这么说来，我现在真是语出惊人），因此，如果你仅检查SQL，实际上只审查了项目的一半。

有一些数据项目拉取请求的模板。dbt有一个模板，我自己还制作了一个版本版本，增加了一些内容和改进。你可以在公共dbt项目中找到遵循最佳实践的拉取请求评论示例示例。

在这些 PR 评论里提到的检查表包括以下内容：

• 这是什么样的改动
• 项目是否构建成功了
• 你是否遵循了风格指南呢
• 你是否记录了新的东西
• 等等之类的

你得自力更生了

所有数据项目的PR评论模板都存在一个共同的缺点。其中有一个部分叫做：

• 验证模型，或者
• 这如何验证的

然后你就得自己来。那你在这里应该做什么呢？你需要验证这些数据，但怎么验证呢？

数据影响验证清单

我们需要一个清单来检查如何进行数据影响验证。这将帮助我们：

• 数据影响验证。

• 出现 意外 影响情况
• 验证 预期 中的变化

制定一套具体的步骤来检查所有可能的数据工作类型（从重构到修复bug）确实很难，但每个PR请求都应该遵循一些步骤。

问题的一半在于能否看到影响。就算你知道要找什么，你又怎么验证它呢？

想象你在上游对订单暂存区进行了逻辑变更，你知道订单数据仓库在下游，这对业务报告至关重要。除了检查你修改的模型的代码外，你还需要检查下游的订单模型。如果你能追踪到这些关键模型，发现没有数据变化，你就可以确定没有意外的干扰传递到下游。

从最宽泛的角度开始，逐步细化，检查数据影响的一般检查表可以这样：

核实受影响的范围

• 检查哪些模型已被修改，这是正确的吗？
• 是否有意外地修改了我们工作范围之外的模型？

检查修改后模型中的数据

• 您的意图和期望下，数据是否正确？

查找下游潜在受影响的资源

• 我所做的更改会对这数据的使用产生任何影响吗？还有，我的更改之后是否存在关键的下游模型？

你大概知道哪些模型是关键的，最好是这些已经由团队定义好了。

检查critical models是否有结构上的影响

• 架构变更
• 行数变化

对关键模型进行全面检查

• 数据分析
• 数据对齐

做一些数据抽样检查或进行一些数据抽查

• 查询结果，
• dev和prod环境的行比较

让我们把它加到实际的检查表里，看看会是什么样子

这些检查可能看起来很简单，但这正是重点所在。每次提交PR时都要注意，所以这点要特别强调一下。注意，这里的“PR”指的是“拉取请求”。

你的检查清单可能有所不同，但这可以给你一个大致的参考。重点是，每个拉取请求(PR)的作者都需要包含这些内容。不论是自己还是同事，这将帮助你验证你的工作，并且也有助于拉取请求(PR)的审查者进行适当的审查。

数据项目不会变得更简单了，变更通常分散在多个拉取请求中，而且需要把数据检查清单保存在数据审计轨迹中。我们需要具备以下功能：

• 保存检查清单
• 复制检查项
• 在多个 PR 中引用这些检查
• 一种协作数据检查的方法

最后一个有意思的，因为它真正为协作PR审核打开了大门。如果多个团队成员能够互相审查对方的检查，就可以将PR审查从一个单向静态过程转变为一个团队协作的过程。

你在提交工作前会检查哪些PR？

Recce（/rɪˈkɛ/） 自带了一份专门用于验证数据建模更改的数据验证清单。

• 工作期间维护一个检查列表
• 将检查结果附在您的PR评论中提交
• 在CI中自动化检查流程

数据验证检查清单用于进行DataRecce.io中的代码拉取请求审查。

了解更多详情并开始使用它吧。Recce。