# 长任务批处理控制台 ## 长任务批处理 Doctor 诊断流程样例 ### 场景 一个商品域会话打标任务正在跑，raw 里已经有成功结果，但并发从 64 开始触发 Ark 429。此时不要直接重启全量任务，而是先跑 doctor 判断是否可断点续跑。 ### 输入 - raw：`projects/xxx/raw/*.jsonl` - 日志：`projects/xxx/run.log` - 参数：`provider=ark`，`concurrency=64`，`resume_mode=only-errors` ### 执行 ```bash python3 /Users/bytedance/Documents/job-bu/data-analysis-workspace/tools/batch_job_doctor.py \ --raw-glob 'projects/xxx/raw/*.jsonl' \ --log projects/xxx/run.log \ --provider ark \ --job-name 商品会话标签 ``` ### 诊断输出 | 检查项 | 结果 | 判断 | |---|---:|---| | 总任务数 | 45,341 | 正常 | | 已成功 | 7,354 | raw 可保留 | | 当前未解决错误 | 0 | 可继续 | | 最近吞吐 | 200 条/分钟 | 稳定 | | 429 命中 | 曾在 64 并发出现 | 建议降并发 | | ETA | 约 190 分钟 | 可接受 | ### 建议动作 1. 停掉高并发父进程，保留 raw。 2. 使用 `--only-errors` 或 resume manifest 继续跑。 3. 并发从 64 降到 32；如果 429 仍增长，再降到 16。 4. 合并前运行错误分类器，避免把 `sessid=...429` 这种普通字段误判为 provider 429。 ### 成功信号 - `ok` 数持续增加，`provider_429` 不再增长。 - doctor 生成的 retry 清单为空或逐步收敛。 - 合并脚本没有把正常 session id、文本内容中的 `429` 当成失败。 ### 失败信号 - 429 占比持续上升，吞吐下降但错误增长。 - raw 中 ok/error schema 混杂，doctor 无法判断断点。 - retry 后同一批 case 被反复标成 `parse_error`，需要先修解析或错误识别规则。