先想清楚：规则从哪里来

很多团队做数据清洗，习惯先打开脚本写一堆判断条件，结果规则越堆越多，业务方却说不清哪些数据被改过。开云在数据处理实践中发现，规则的第一来源不是技术人员的直觉，而是业务口径和真实数据形态。具体可以从三个地方收集：一是业务方明确约定的字段含义，比如订单金额是否含运费；二是历史数据中反复出现的异常模式，比如同一客户编号对应多个名称；三是下游报表和分析对字段的硬性要求，比如日期字段必须可排序。

把这三类来源整理成清单后，每条规则都要能回答一个问题：这条规则解决的是什么业务问题。回答不了的规则，大概率是过度清洗。开云建议在规则表里增加“业务说明”一列，哪怕只有一句话，也能在后续复盘时省下大量沟通成本。

规则要分级，不要一刀切

清洗规则按处理力度大致可以分为三类，混在一起写容易出问题。第一类是硬性规则，比如主键不能为空、金额不能为负，违反即拦截或标记，这类规则适合放在数据接入环节。第二类是修正规则，比如去除首尾空格、统一日期格式、把“是/否”映射为布尔值，这类规则可以自动执行，但需要保留修改前后的对照记录。第三类是提示规则，比如某字段缺失率突然升高、某类取值占比异常，这类规则不直接改数据，而是输出质量信号供人工判断。

  • 硬性规则：拦截或打标，保证数据可用底线。
  • 修正规则：自动处理并留痕，保证可回溯。
  • 提示规则：只告警不改动，保留业务判断空间。

开云在为客户搭建数据管理系统时，通常会把三类规则分别配置在不同环节，避免修正规则误伤本应保留的异常值。规则分级之后，执行顺序也有讲究：先做格式统一，再做逻辑校验，最后做跨表一致性检查，顺序乱了容易出现“刚修好又被判为异常”的情况。

落地之后，校验和留痕不能省

规则写完不等于完成，真正的考验在落地之后。开云的做法是每条规则上线前先跑一遍历史数据，统计触发次数和影响范围，触发比例过高的规则要重新审视是否过严。上线后保留规则执行日志，记录哪条规则在哪个批次改了多少条记录，这样当分析结论出现偏差时，能快速定位是不是清洗环节动了手脚。

另外，规则需要定期回看。业务口径会变，数据来源会变，去年合理的规则今年可能已经失效。开云建议把清洗规则纳入数据管理的常规盘点，和指标口径一起维护，而不是写完就锁进脚本里。规则表保持可读、可查、可讨论，数据处理的底子才算真正打牢。