用PythonDSL构建轻量数据质检工具，规则可读可测可复用

在日常经营分析或日报生成流程中，数据清洗往往是第一步。一份导出的销售明细表可能包含重复订单号、位数异常的手机号、负值金额、格式错乱的日期等“脏数据”。若不提前识别并处理，后续所有分析结果都可能失真。传统做法是直接在DataFrame上编写一连串if判断，但随着规则增多，代码迅速变得难以维护——报错信息与业务逻辑混杂，修改一条规则常需反复验证是否影响其他检查。

这种困境的本质在于：用通用编程语言强行模拟一套“数据质量规范”，而该规范本身缺乏清晰结构。领域特定语言（DSL）提供了一种反向思路：不另学新语言，而在Python内部搭建一套专用于数据质检的微型语法体系。其核心目标是让规则本身具备可读性、可测试性与可复用性。

如图所示，左侧为传统写法：嵌套if语句将校验逻辑与错误收集耦合在一起；右侧则采用DSL表达：每条规则以Rule("订单号唯一", unique_values("order_id"), "单号不能重复")形式呈现，语义清晰，且验证逻辑与报告生成分离。

整个DSL架构仅依赖一个核心类Rule。它接收三部分参数：规则名称、条件函数、错误提示文本。关键约定是：条件函数返回True表示“该行合规”，因此违规行即为~condition(df)的结果。check方法统一输出结构化报告，包括规则名、原因、违规行数及样例行索引，确保结果可追溯。

为提升可读性，DSL配套一组辅助函数作为“词汇表”，用于构造条件函数：

not_null(col)：检查字段非空
unique_values(col)：确保字段值全局唯一（含所有重复项）
between(col, lo, hi)：数值范围校验
matches_pattern(col, pat)：正则匹配格式（如手机号11位且以1开头）

这些函数返回lambda表达式，使规则定义简洁直观。例如：

Rule("手机号格式", matches_pattern("phone", r"^1\d{10}$"), "手机号须为11位且以1开头")

规则定义完成后，由DataValidator统一调度执行。它支持链式添加规则（add_rule返回self），validate方法逐条运行各Rule，即使某条失败也不中断其余检查，最终汇总全部问题报告。

如图所示, 整个流程分为四步：①准备pandas DataFrame样例数据；②调用辅助函数生成条件；③将条件封装进Rule实例；④交由DataValidator执行并输出结构化违规报告。该设计实现了“验证什么”与“如何验证”的解耦，也使每条规则可独立单元测试。

为验证效果，作者构建了一份含五字段（订单号、手机号、金额、销售日期、备注）的模拟门店销售数据，并人为注入典型问题：重复订单号、9位手机号、-50元金额、YYYY-MM-DD以外的日期格式、高金额无备注等。运行完整规则集后，终端输出如下结果：

输出清晰列出每条规则的名称、说明、违规行索引。例如“金额非负”规则指出第2、3行违规；“高金额需备注”规则命中第1、3、4行——这正是人工构造的异常点，验证了DSL的有效性。

第一，规则与业务对齐。非开发人员（如运营、分析师）可参与规则定义，因语法接近自然语言描述；

第二，便于版本管理与协作。规则文件可纳入Git，每次变更清晰可查，避免“改一处崩一片”；

第三，天然支持CI/CD集成。可在数据管道前置环节自动触发校验，例如在Airflow任务开始前调用validate()，失败则终止下游流程；

第四，扩展性强。新增校验类型只需补充辅助函数，无需改动Rule或DataValidator核心逻辑。例如可快速加入“日期不能晚于今日”“备注长度≥5字符”等新规则。

值得注意的是，此类轻量DSL并非替代专业数据质量平台（如Great Expectations、Deequ），而是面向中小规模场景的敏捷方案。当数据源稳定、规则数量在数十条以内时，它能以极低学习成本实现高质量保障。对于需要跨系统、多层级、审计留痕的企业级需求，则仍需依赖成熟框架。

在数据驱动决策日益普及的背景下，数据质量已从“后台运维事项”转变为“前端分析前提”。一套清晰、可控、可协作的质检机制，能显著降低分析返工率与误判风险。Python DSL方案的价值，正在于将这一过程从“技术负担”还原为“业务共识”——规则本身即文档，执行过程即验证，报告输出即沟通依据。

目前该实现已在Juejin社区开源示例中公开，开发者可基于此快速搭建适配自身业务的数据质检模块，无需引入额外依赖，仅需pandas与标准库即可运行。