数据任务零行输出算成功吗？空跑和真实零业务怎么区分？
本文目录
面试怎么回答
我不会只凭退出码或输出行数判断成功。先确认本批范围和输入是否完整，再解释记录经过过滤、关联和隔离后为何为零。正常无业务可以发布明确的空结果，上游未到齐应等待，异常空跑要阻断。覆盖写不能一律保留旧数据，也不能无条件清空；应按数据合同验证预期分区、行数和状态，并让下游区分真实零、未知和陈旧值。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
凌晨任务返回成功，输出却是零行。此时直接放行，可能把一张正常报表清空；一律拦截，又会把真正没有业务的日期天天报成故障。零行本身没有告诉我们原因，判断要回到这批数据的约定。
零行只是结果，不是原因；要用输入完整性、过滤去向和预期产出来判断空批次是否可以发布。
退出码只能回答程序有没有报错
日期传错、租户范围为空、过滤条件过严，SQL 都可能正常执行并返回零行。程序成功不等于业务产物完整，反过来没有记录也不必然意味着故障。
先确认这张表应该表达什么。订单明细在无交易日可以为空；每日状态快照可能即使没有新增交易也应产出存量状态；全局汇总即使没有输入，也可能返回一行 NULL 或零值。
因此“输出至少一行”不是适用于所有表的质量规则。行数阈值应该依赖表的粒度、业务周期和产出约定。
第一层证据：输入是否真正完整？
批次范围要显式记录，比如业务日期、租户、分片清单与规则版本。调度日期、数据日期和源端时区如果不一致，零行可能只是读错了范围。
上游完成证据也不能只有任务状态。文件批次可以有预期文件清单和完成标记；接口分页要确认所有页已拉取；多分片任务要核对分片是否齐全。
这些是可选的工程设计，不要求所有系统采用同一种清单格式。但“还没到齐”和“到齐后确实没有业务”，必须能被区分，否则下游只能猜。
第二层证据：输入去了哪里？
如果输入非零、输出为零，应沿处理步骤记录过滤、隔离、关联未命中和输出数量，解释数据为何消失。
只在行保持的一进一出步骤，且各去向互斥完备时，才可以用输入等于各去向之和做简单守恒。经过聚合、展开或一对多关联后，要改用相应粒度和业务键核对，不能强行要求行数相等。
异常隔离不等于业务正常为空。如果所有记录都因为解析错误进了隔离区，主表零行只是故障的一个结果，不应该被包装成“今天没有业务”。
一个典型场景：零行覆盖了正常分区
比如任务日期参数错位，读到一个尚无数据的范围，却把结果覆盖到本来有效的目标日期。退出码为零，调度继续运行，报表金额突然消失。
最初怀疑源端业务骤降，检查后发现是源范围与目标范围不一致。旧测试只使用非空日期，验收也只看任务成功，因此没有覆盖空输入和错日期组合。
修复应先记录输入范围与目标范围，再对空输出执行专门判定。发布前验证目标分区清单，阻断无法解释的空覆盖，并保存必要的恢复依据。
不能简单改成“零行就保留旧分区”。如果业务确认当天确实为零，保留旧数据会让昨天的内容继续冒充今天；修复必须按原因分类。
三种空批次，应该有三种处理
正常零业务：输入已完整，规则确认本批可以为空，发布明确的空结果或相应零值，并记录完成范围。
输入待到齐：暂不作最终结论，保留等待状态和期限。超时后按影响升级，而不是让等待永远显示成功。
异常空跑：输入或变换证据不满足要求，阻断正式发布，报告失败节点与原因，并让下游知道当前结果不可用或仍是旧版本。
这三种分类是建议的数据合同设计，不是某个调度平台已经内置的状态名。平台只支持成功失败时，也可以在批次元数据和发布门禁中表达。
覆盖、追加和增量状态表，各自不同
覆盖写要确认预期目标集合，真实空结果是否需要清掉旧内容，以及实际引擎对零输出覆盖的行为。不能未经测试就推断空查询一定清空或一定保留。
追加写的零输出可能完全正常，但仍需记录该批已经完成，否则下游可能持续等待不存在的文件。
增量状态表则可能没有本次变更，但存量状态并不为零。把“本批新增零条”翻译成“当前总量为零”，属于指标含义错误，不是写入方式问题。
最后看下游如何表达未知
看板应区分真实零、尚未更新和沿用旧版本。把异常缺数统一 COALESCE 成零，只会让数据问题变成错误业务结论。
重跑验收也要包含真实空批次、输入缺片、全部隔离、错误参数与覆盖残留。只有先定义空结果的含义，才谈得上给它一个正确的成功状态。
如果让我总结，零行不是免责理由，也不是天然事故。真正可靠的任务，既能解释为什么有这些数据，也能解释为什么这一批没有数据。