补数据最危险的做法，是改一个业务日期参数，然后把它当普通调度实例再跑一遍。页面上只有一个绿色的“成功”，实际发生的事情可能是：旧分区被覆盖了一半、下游提前启动、失败重试又写出一份重复数据，最后谁也说不清当前结果来自哪版代码。
我更愿意把补数据看成一类独立运行，而不是正常调度的快捷入口。它至少要回答四个时间：处理哪段业务数据、何时提出请求、何时真正执行、哪一刻把结果发布给下游。再加一个独立的 run_id，这件事才有可追踪的起点。
邓明瑞 / 纯粹
邓明瑞 / 纯粹
补数据最危险的做法，是改一个业务日期参数，然后把它当普通调度实例再跑一遍。页面上只有一个绿色的“成功”，实际发生的事情可能是：旧分区被覆盖了一半、下游提前启动、失败重试又写出一份重复数据，最后谁也说不清当前结果来自哪版代码。
我更愿意把补数据看成一类独立运行，而不是正常调度的快捷入口。它至少要回答四个时间：处理哪段业务数据、何时提出请求、何时真正执行、哪一刻把结果发布给下游。再加一个独立的 run_id，这件事才有可追踪的起点。
