Dataform(BigQuery) SQL断言检查：自定义Python脚本是否合理？

现有脚本方案的有效性与局限性 #

你的方案有一定实用性，但存在不少明显局限：

• SQL语句统计不准确：仅靠分号计数容易出错——比如分号出现在注释、字符串常量里，或是Dataform的JS配置块、变量定义中，这些都不属于SQL执行语句，会被误统计，导致比值计算失真。
• 断言统计精度低：单纯匹配关键词会把注释、字符串里的关键词，甚至含断言关键词的对象名（比如名为assert_total的表）都算进去，无法区分真正有效的断言语句/测试。而且Dataform里的断言形式不止一种，比如assert语句、tests块里的列级测试，你的脚本可能没全覆盖。
• 比值阈值缺乏灵活性：不同类型的SQL脚本需要的断言数量差异很大——基础ETL脚本可能只需少量核心断言，复杂的聚合报表可能需要更多测试，统一的比值标准很难适配所有场景。

更优的解决方案 #

1. 改进现有Python脚本 #

• 放弃分号计数，改用专业的SQL解析库（比如sqlparse，或直接调用sqlfluff的内部AST解析API）遍历语法树，精准识别真正的SQL执行语句。
• 针对Dataform的语法，专门解析其tests块和assert语句节点，过滤掉注释、字符串中的无效匹配，确保统计的是有效断言。

2. 基于SQLFluff扩展自定义规则 #

SQLFluff支持自定义规则开发，你可以利用它的AST解析能力编写规则：

• 遍历Dataform项目的SQL语法树，统计有效断言的数量；
• 结合上下文判断当前脚本的类型（模型、增量表等），设置差异化的断言数量要求；
• 直接把规则集成到现有lint流程中，和其他SQLFluff检查统一执行，不用单独维护脚本。

3. 利用Dataform自身的测试机制 #

Dataform内置完善的测试体系，包括行级测试、列级测试（非空、唯一性检查等），你可以：

• 在Dataform项目配置中，强制要求每个模型必须包含指定数量的测试；
• 在CI/CD流程中执行dataform test命令，直接检查测试覆盖率是否达标，这种方式完全贴合Dataform语法，精度最高。

4. 替代工具（可选） #

如果团队可以调整工具链，dbt的测试体系更成熟，内置大量测试规则，还能通过dbt-lint等工具强制测试覆盖率，但前提是愿意从Dataform迁移到dbt。

内容的提问来源于stack exchange，提问作者Kajal Chopra