坏数据排查核心是“隔离+验证+定位”三步闭环：通过异常日志、最后成功记录、数据库错误定位触发点；用分段切片与二分法锁定单条问题数据；加轻量级守门员校验拦截非法输入；并从下游异常反推上游污染源。
排查坏数据导致批处理任务崩溃，核心是“隔离+验证+定位”三步闭环。坏数据本身不报错，但会在特定逻辑分支（如空值参与计算、非法字符触发正则异常、超长字段截断后破坏JSON结构）中引发隐性失败，最终让整个批处理中途退出或结果错乱。
快速识别坏数据触发点
先看任务崩溃时的直接线索：
- 日志末尾是否出现 NullPointerException、NumberFormatException、JsonParseException、StringIndexOutOfBoundsException 等明确指向数据内容的异常？这类堆栈通常带行号或字段名，是第一突破口；
- 崩溃前最后一条成功处理的日志，是否对应某条记录的ID、时间戳或业务单号？把它单独拎出来重放，大概率复现问题；
- 如果用的是SQL批量插入/更新，检查数据库错误日志里是否有 “Data too long for column”、“Incorrect datetime value”、“Out of range value” 等提示，说明源头数据格式越界。
用最小集做数据切片验证
不要全量重跑，而是把输入数据分段切片，逐段验证：
- 将原始数据按主键/时间戳等有序字段分成10份（如0–999、1000–1999…），每次只喂一份进批处理；
- 找到最先崩溃的那一份后，再二分法缩小范围（如在500–999里再拆成500–749、750–999）；
- 最终锁定到单条记录后，导出该行原始数据（含不可见字符），用文本编辑器查看是否有BOM头、\r\n混用、零宽空格等肉眼难辨问题。
加轻量级数据守门员校验
在批处理入口加一层预检逻辑，不执行业务逻辑，只做基础合规性扫描：
- 对关键字段强制非空、长度≤N、匹配正则（如手机号 /^[1-9]\d{10}$/）、日期可解析；
- 对JSON字段用 json.loads(data, strict=False) 尝试解析（Python）或 JSON_VALID()（MySQL 5.7+）；
- 记录所有校验失败的行及具体原因，生成“坏数据报告”，而不是让任务直接崩掉。
从下游反推上游污染源
如果批处理输出了中间表或文件，而后续环节报错，可逆向追踪：
- 查输出表中异常值（如金额为NULL却参与SUM、状态码不在枚举范围内）；
- 用 WHERE 字段 IS NULL OR 字段 NOT IN (‘A’,‘B’,‘C’) 快速捞出可疑行；
- 根据这些行的业务ID回溯上游原始数据源，比对字段值差异，常能发现ETL过程中的转换丢失或默认值覆盖问题。
坏数据排查不靠运气，靠可控切片和前置校验。真正耗时的不是找哪条数据坏了，而是确认它为什么被当成合法数据放行了——这往往暴露的是数据接入规范或清洗规则的盲区。
