一个被退回三次的清洗脚本

星空数据技术组的老陈做数据清洗有年头了，经手的业务数据整合项目不少。前阵子他接手一个零售企业的门店销售数据整理任务，本以为轻车熟路，结果脚本交上去被项目组退回来三次。第一次是门店编码字段混入了空格和全角字符，导致关联匹配大面积失败；第二次是退货金额列里出现了负数与文本“无”并存的情况，汇总时直接报错；第三次更隐蔽，同一商品在不同区域的分类名称不一致，清洗后仍然对不上业务口径。老陈后来在星空内部复盘时说，这三次返工没有一次是技术难题，全是“以为对方知道”造成的。

字段命名背后的沟通断层

老陈的第一个教训来自字段命名。业务方提供的原始表里有一列叫“金额”，财务同事默认是含税金额，运营同事理解为实收金额，而门店上报时又混入了促销折扣后的净额。星空数据技术在承接这类业务数据整合时，通常会先做字段语义梳理，但这次老陈跳过了确认环节，直接按字面意思处理。返工后他补了一张字段说明表，把每个字段的来源、计算逻辑、责任岗位列清楚，再让业务方逐项签字确认。这一步看似繁琐，却让后续的清洗规则有了明确依据。星空在多个数据管理系统建设项目中都强调，字段命名不是技术细节，而是跨部门协作的契约。

空值与异常值的处理不能靠猜

第二次返工暴露的是空值处理问题。退货金额列里既有空单元格，也有填“无”的，还有填“0”的，老陈的脚本统一按空值置零处理，结果把“未发生退货”和“退货金额为零”混为一谈，影响了门店退货率的统计。星空数据技术团队后来调整了策略：先对异常值做分布盘点，把文本型占位符、零值、真空值分三类标记，再与业务方确认各自的业务含义。老陈在星空内部技术分享时提到，数据清洗里最怕的不是脏数据本身，而是清洗人员替业务方做假设。星空在数据标准落地方法中建议，空值处理规则应当写入数据标准文档，而不是停留在脚本注释里。

分类口径统一需要有人拍板

第三次返工最让老陈触动。同一款商品在华东区叫“家庭装”，在华南区叫“实惠装”，编码相同但名称不同，清洗后按名称汇总就裂成了两条记录。老陈起初想用编码去重，但业务方反馈编码本身也有历史遗留的重复问题。最后是星空项目组拉着区域运营负责人开了一次口径确认会，明确以商品主数据编码为准，名称统一取总部标准库，历史差异做映射表留存。老陈事后总结，数据清洗做到深处，技术手段只占三成，剩下七成是推动业务方把口径说清楚、定下来。星空数据技术在服务企业客户时，逐渐把这类口径确认会作为数据整理项目的标准动作，而不是等到返工再补救。

  • 字段说明表要落到岗位责任人，不能只写技术备注。
  • 空值、零值、文本占位符要分开标记，逐类确认业务含义。
  • 分类名称不一致时，优先追溯主数据标准，再建映射关系。
  • 清洗规则变更要同步更新数据标准文档，避免下次换人重犯。

老陈的故事在星空数据技术组里不算特殊，但每次聊起来都有人点头。数据清洗的返工往往不是因为工具不够好，而是因为协作链条上少了一次确认、少了一张说明表、少了一个拍板的人。星空在数据技术栏目里持续记录这类来自一线的观察，也是希望更多做报表开发和数据管理的同行少走几步弯路。