历史回填怎么不影响当天任务？只换一个调度队列够吗？
面试怎么回答
我会先画出回填与生产共享的资源，再分别约束计算并发、读取速率和下游写入压力。回填按日期或键范围分块，保存进度并支持暂停重试；生产SLA触及阈值时主动降速。发布还要防止旧批次覆盖新版本。换队列只是其中一层，验收要在真实并发负载下看生产延迟与下游稳定性。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
离线队列已经分开，历史回填一启动，当天报表还是晚了。原因可能不在计算资源：两套任务最终都在争同一个存储带宽、同一组数据库连接或同一张写入表。
回填隔离要覆盖计算、存储、网络与下游写入；按生产SLA限速、分块和可暂停，比一次性堆高并发更重要。
队列隔离只覆盖一部分资源
计算资源池可以限制任务占用的CPU、内存或执行槽，但数据通常还要经过共享存储、网络链路、元数据服务和下游系统。
例如回填任务没有抢占生产Executor，却同时扫描大量文件，导致存储读延迟上升；或者把批量写入并发调高，耗尽数据库连接和写入能力。生产任务仍然会排队等待。
所以先画出两类任务的共同依赖，分别标出吞吐限制、连接限制和热点对象。只看调度页面上的资源隔离，容易漏掉真正的瓶颈。
给回填定义明确预算
预算不只有“最多同时跑几个任务”。还可以包括每秒读写量、单批大小、活跃分区数、连接数量和允许执行时段。
具体阈值来自生产基线和压测，而不是抄一个通用百分比。生产任务已经接近截止时间时，回填应该降低速率或暂停；生产压力恢复后，也要逐步恢复，避免反复冲击。
控制信号应优先采用业务结果相关指标，例如关键任务剩余时间、下游写延迟、失败率和积压增长，而不是只看某台机器CPU是否空闲。
分块，是为了能停下来
把几个月历史一次性交给一个巨型任务，失败时难以定位，也难以在高峰到来前干净暂停。按业务日期、分区或稳定键范围划分可验收的小块，更容易控制进度。
每块要记录输入范围、代码与规则版本、写入批次、校验状态和完成标记。暂停之后应能从已确认边界继续，而不是重新扫描全部历史。
重试也要考虑幂等和正式数据保护。输出先进入隔离区或带批次标识的目标，校验通过后再发布；不能把“任务提交成功”直接当成该块业务数据已完成。
分块大小需要权衡。太小会增加调度、文件和元数据开销，太大又降低暂停灵活性。可以用小范围试跑，根据实际耗时与失败成本调整。
计算隔离之后，还有写入竞争
历史回填与当天任务可能更新同一业务键，尤其是迟到修正、状态回算和滚动汇总。旧输入产生的结果若晚提交，可能覆盖刚发布的新结果。
因此发布要带输入版本或业务版本约束，明确哪个结果有资格成为当前结果。仅按任务完成时间取最新，可能让最慢的旧批次获胜。
如果回填只修某几个历史分区，应把影响范围锁定，并核对下游是否会据此重算跨期指标。不能以为日期旧，就一定与今天没有依赖关系。
一个典型场景：队列没抢资源，写库却被打满
假设历史回填新建了独立队列，测试时单独跑很快。正式并发运行后，当天任务大量等待写入响应，团队最初继续给生产队列加计算资源。
真正瓶颈是共享数据库的连接和批量写入压力。旧压测只测回填自身速度，没有同时运行生产链路，因此没有复现竞争条件。
修正后保留计算隔离，同时限制回填写并发，按小块推进，并将生产延迟作为降速信号。恢复测试则验证回填暂停后进度不丢、重试不重复，生产任务也能回到正常完成窗口。
最后评估的是“在不突破生产SLA的条件下，历史多久能补齐”，而不是“回填单跑最快能多快”。这个目标会自然改变资源分配与验收方式。
完成要有可核对的清单
记录计划范围、完成范围、失败范围和未发布范围，避免只报告成功任务数。回填结束后还要复核生产指标是否恢复、隔离数据是否按约定保留，以及哪些临时限制需要解除。
有了清单，下次遇到重算、迁移或补数，也能沿用这套控制方法，而不必每次依靠值班人员盯着大盘手动猜测。