备案站点的批处理与 ETL 数据管道运维

批处理故障最麻烦的地方：发现得晚

在线接口出错，用户立刻能感知、监控立刻能报警。批处理任务不一样：它凌晨两点跑，跑挂了、跑漏了、跑出了错误数据，往往要等到第二天早上业务方打开报表发现数字不对，才会有人去查。批处理运维的核心难题不是"任务会不会失败"，而是"失败了能多快被发现、能不能干净地重跑"。

关键要点

• 任务之间有依赖关系时，一个上游失败要让下游明确停下，而不是拿着空数据或旧数据继续跑。
• 全量和增量各有代价：全量简单可靠但耗时随数据量增长，增量快但要处理迟到数据和状态漂移。
• 断点续跑的前提是任务幂等，否则重跑等于重复处理，这一点和实时任务是同一个道理。
• 数据质量校验要卡在管道里，而不是等下游用错了数据才发现。

任务依赖：DAG 和失败传播

多数批处理场景是一条任务链：抽数 → 清洗 → 聚合 → 生成报表，下游任务依赖上游任务的产出。这类依赖关系天然是一张有向无环图（DAG），需要明确回答两个问题：

问题	处理方式
上游任务失败，下游要不要跑？	默认不跑，除非下游有能力优雅处理缺失数据
上游任务跑慢了，下游等多久？	设置超时窗口，超时后升级告警而不是无限等待

最容易踩的坑是失败传播不彻底：上游任务失败了，但只是记了一条日志、进程正常退出（退出码 0），调度系统认为任务成功，下游照常拿着不完整的数据继续跑。任务失败必须用非零退出码或明确的失败状态标记，让调度层能感知并阻断下游，这和普通服务异常处理需要冒泡而不是被吞掉是同一个原则，日志里的错误记录方式见 日志规范与集中检索。

全量 vs 增量：不是非此即彼

方式	优点	代价
全量重算	逻辑简单，天然幂等，出错易排查	耗时随数据量线性增长，资源消耗大
增量处理	快，资源占用小	要处理迟到数据、状态漂移、边界重复

增量处理的隐藏成本在于"迟到数据"：上游系统的数据可能因为网络延迟、事务提交时间差等原因，在批处理窗口关闭后才姗姗来迟。纯增量管道如果不做二次修正，这部分数据就永久丢失了。稳妥的做法是增量为主，定期全量校验——比如每天做增量，每周或每月做一次全量重算对齐，用全量结果去发现增量过程中悄悄产生的偏差。

断点续跑：幂等是硬要求

批处理任务动辄跑几十分钟到几小时，中途失败（资源不足、依赖抖动、机器重启）是常态。没有断点续跑能力的任务，一次失败就要从头开始，浪费的不仅是时间，还可能因为部分写入而产生脏数据。

断点续跑要做到位，需要：

• 记录处理进度：按分区、按时间范围、按主键区间记录已完成的部分，重跑时跳过已完成的部分。
• 写入幂等：同一分区重复写入要能覆盖而不是追加，做法和实时任务的去重思路一致，见 消息队列与异步任务运维 中关于幂等的讨论同样适用于批处理。
• 中间结果可回滚：任务失败时，已产生的部分中间结果不能污染下游，通常做法是先写到临时区域，全部完成后再原子切换到正式表。

数据质量校验：卡在管道里，而不是等业务发现

批处理最怕的不是任务跑挂了（跑挂了至少能被感知），而是任务"成功"了，但产出的数据是错的——上游一个字段类型变了、一批记录莫名丢失、聚合逻辑因为边界条件算错了，管道全程绿灯，直到业务方拿着错误数字做决策才暴露。

实用的质量卡点：

• 行数与量级校验：本次产出的行数、总量和历史同期对比，偏离阈值就告警而不是直接产出。
• 空值率与关键字段校验：核心字段的空值率、唯一性突然异常，往往说明上游数据源出了问题。
• 业务规则校验：金额类字段不能为负、状态枚举不能出现未定义值，这类规则要写进管道而不是只靠人工抽查。

校验失败时，管道应该默认阻断下游而不是降级放行——错误数据流到报表和决策链路的代价，远高于晚一天出报表。

批处理窗口与在线业务的资源争抢

批处理任务通常安排在业务低峰期跑，但"低峰"不代表"空闲"——如果批处理任务和在线业务共用同一个数据库或存储，一次大规模扫描或写入照样能把在线业务的响应时间拖慢，慢查询与索引层面的影响见 慢查询定位与索引优化，磁盘 IO 层面的争抢见 磁盘 IO 与文件系统运维。

缓解手段：

• 读写分离：批处理尽量走只读副本，不与在线写入路径抢锁，见 数据库运维与高可用。
• 限速与分批：批量抽取和写入都要限速分批，避免瞬时打满 IO，方法和大表数据清理是同一个思路，见 数据生命周期与归档清理。
• 资源隔离：条件允许时把批处理负载调度到独立的计算资源上，避免和在线服务竞争 CPU 和内存，容量规划见 容量规划与弹性伸缩。

调度层面要盯的指标

指标	意义
任务完成时间趋势	逐渐变长说明数据量增长已经逼近处理能力上限
失败率与重试次数	突增通常指向上游数据源或依赖资源出了问题
依赖等待时长	长期等待说明上游任务的调度时间需要提前
数据质量校验通过率	持续下降是管道健康度恶化的早期信号

这些指标要接入统一的监控告警，而不是只在任务失败时才有人关注，见 备案网站监控告警体系，故障发生后的复盘方法见 故障响应、复盘与 SLO 实践。

常见坑

• 上游失败下游照跑：拿着空数据或旧数据继续处理，错误逐级放大。
• 纯增量不做全量校验：迟到数据和边界重复长期悄悄累积偏差。
• 任务不幂等：断点续跑变成重复处理，数据翻倍或对不上。
• 质量校验只做抽查不做卡点：错误数据已经流到业务方手里才被发现。
• 批处理和在线业务抢同一份资源：低峰期不等于资源空闲，照样拖慢线上。

常见问题

批处理任务失败了，应该立刻重跑还是先排查？

先确认失败原因是瞬时的（网络抖动、资源不足）还是数据本身的问题。瞬时故障可以直接重跑；如果是数据格式或业务逻辑问题，重跑只会得到同样的错误结果，必须先修复根因。

全量校验的频率怎么定？

取决于增量管道出偏差的速度和业务对数据准确性的敏感度。多数场景每周或每月做一次全量校验即可发现问题；对账、结算类强一致性要求的场景，建议提高到每天。

数据质量校验规则应该由谁来定？

技术侧负责实现校验机制，具体的业务规则阈值（比如行数波动多少算异常）应该和业务方共同确认。纯技术视角定的阈值经常和业务实际波动规律对不上，导致误报或漏报。

批处理任务能不能和实时任务共用同一套调度系统？

技术上可以，但要注意资源隔离和优先级设置，避免批处理的大负载挤占实时任务的执行窗口。多数团队会用同一套调度平台管理两类任务，但会按队列或资源池做物理隔离。

资料来源

主流批处理与工作流编排框架（如 Airflow、DolphinScheduler）公开文档中关于任务依赖、重试与数据质量校验的说明，以及通用数据管道工程实践资料。本文为通用运维说明，仅供参考，具体方案请结合数据规模与业务时效性要求设计。