[Feature] speed up warm up cancel (by manual or by failure)

[freemandealer]

Search before asking

• I had searched in the issues and found no similar issues.

Description

任务描述

file cache 预热的时候，如果某个 be 节点在过程中发生错误，或者用户手动发出 cancel SQL，需要等一段时间才能完全关闭这次预热。这是因为 cancel 信号的传递需要时间，这个时间的源头是因为我们的预热分成 batch，be 节点一次预热一批数据（warm up task）。当这批完成以后才会知道自己是否需要预热下一批数据。我们现在需要一个机制，能够在 fe 收到 cancel 请求（发生错误或者用户手动提交）时，及时打断 be 节点正在执行的 warm up task。

背景知识

之前有录过一个串讲视频，就不文字详细介绍了，请看视频 https://www.bilibili.com/video/BV16c2ZYHEzm

关注的主要源文件

BE侧：
be/src/cloud/cloud_warm_up_manager.cpp

FE侧：
fe/fe-core/src/main/java/org/apache/doris/analysis/CancelCloudWarmUpStmt.java
fe/fe-core/src/main/java/org/apache/doris/cloud/CacheHotspotManager.java

方案

基本思路是在 be RPC层 (be/src/service/backend_service.cpp) 增加一个 cancel warm up 的接口，在新增的接口中调用 cloud_warm_up_manager 的 cancel逻辑（需要自行实现）， 然后 FE 调用这个 rpc 就能快速关闭 be 上的 warm up task。

Use case

No response

Related issues

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[0AyanamiRei]

please assign to me，:)

[freemandealer]

除了新增 RPC 接口之外，我们可以考虑利用现有的 clear job 接口 (关键词 TWarmUpTabletsRequestType.CLEAR_JOB)。现有 clear job 的逻辑粒度也比较大，一个 tablet 预热结束才会检查，如果 tablet 很大 cancel 时间依旧很长。我们可以在每个 segment 文件下载好就检查一次。

[0AyanamiRei]

除了新增 RPC 接口之外，我们可以考虑利用现有的 clear job 接口 (关键词 TWarmUpTabletsRequestType.CLEAR_JOB)。现有 clear job 的逻辑粒度也比较大，一个 tablet 预热结束才会检查，如果 tablet 很大 cancel 时间依旧很长。我们可以在每个 segment 文件下载好就检查一次。

疑问: 一个 tablet 预热结束才会检查，handle_jobs中进行wait->timed_wait(time)之前的应该都是cpu操作，负责把一个job划分成不同任务往线程池提交。我认为能够进行检查的间隙应该很短，大部分时间都在等待远端数据的load，这个时间内不能进行检查。

关于利用clear job接口，我的想法是：如果BE收到clear job, 此时download任务正在进行, BE可以依赖这样一个事实 "cur_job == _pending_job_metas.front()" 并且直到cur_job的所有预热任务完成为止都不会pop_front，clear job可以按照handle_jobs的划分方式依次通知进行download的线程在每个task结束就进行回调，这样就可以实现快速cancel了