OLAP资源隔离与调度策略：从失控到可控的实战指南

干过大数据的同学应该都有这种体会：白天业务线正在跑例行报表，几条即席分析查询冲进来，集群 CPU 瞬间打满，内存持续告警，紧接着是一串 Executor Lost、Container OOM 的报错。到了晚上，离线任务和实时宽表构建挤在一起，调度队列堆成山，谁先跑谁后跑完全看命。这就是典型的 OLAP 资源隔离和调度策略没有做好的现场。

我最早接触这个主题是在维护一套十几台节点的 OLAP 集群时，那时候团队里对“资源”的理解还是“机器内存够大就行”。直到一次事故——一个分析师提交了一个没有过滤条件的 join，直接把整个节点搞到 Full GC，影响了所有在跑的报表任务，才逼着我系统性地去研究资源隔离和调度策略。这篇内容我想结合自己在几个主流引擎上的实践，把 OLAP 场景下的资源隔离怎么做、调度策略怎么定、有哪些坑必须绕开，完整梳理一遍。无论你是在校准备大数据方向面试，还是刚接手集群运维，都应该能从里面拿到一套可以直接落地的思路。

1. 为什么OLAP必须谈资源隔离

1.1 我看到的OLAP资源失控现场

OLAP 场景和传统离线数仓最大的区别在于：查询是临时的、突发的、不可预测的。Flink 跑实时任务，资源占用相对固定，用多少并行度、多少内存，启动时就能算清楚。但 OLAP 不是，同样一张宽表，按分区查可能几百毫秒返回，不带分区条件可能就是几分钟甚至直接卡死。

更麻烦的是，OLAP 集群往往同时服务多个角色：运营看板、财务对账、数据产品 API、分析师即席查询、甚至算法团队的特征抽取。每类角色对稳定性、延迟、吞吐的要求完全不同。运营看板要求 99% 的查询在 3 秒内返回，分析师即席查询可以接受 30 秒，但要求能跑特别复杂的 join；算法抽特征则希望把机器压满。如果所有查询共用一个资源池，没人能保证 SLA。

我印象很深的一次事故是这样：某天下午，一个同事跑“某季度全量用户行为分析”，SQL 里三个大表直接不加条件做 join，产生的中间结果集把 NodeManager 的可用内存全部吃掉，随后整个节点开始疯狂 Full GC。当时集群上有二十多个正在运行的报表任务，全部卡在等待资源上。由于我们当时用的是 FIFO 调度，新任务永远排在后面，整个集群的服务能力直接降为零。这个过程从查询提交到恢复用时将近四十分钟，影响到的业务方超过十个。

这类事故的核心原因只有一个：没有隔离。任何一条不可控查询都可能污染整个集群。

1.2 不隔离的典型故障链

隔离缺失的场景下，故障传导路径几乎是固定的：

1. 单条查询申请大量内存，触发 YARN 或容器级别的内存超额使用。
2. 操作系统开始 swap，节点 IO 被打满。
3. 该节点上其他任务的执行速度急剧下降，GC 频繁。
4. 任务超时或心跳中断，触发重试；重试进一步放大资源压力。
5. 调度器看到资源不足，把新任务积压在队列里，队列堆长之后触发超时和失败。

这条链路里，最容易被忽略的是第二步。很多人以为内存隔离只影响内存，实际上内存打满之后最先崩溃的是磁盘 IO，因为系统在疯狂 swap。这会让所有共享同一块物理磁盘的任务全部降速。你检查监控时如果只看 CPU 和内存，大概率看不到根因。

所以做 OLAP 资源管理，先想清楚一个原则：资源上限必须可以“硬限制”，不能依赖“自觉”。任何一个跑在集群上的任务，都应该在启动时就知道自己最多能用多少内存、多少 CPU、最多保持多少并发。超过上限的，要么拒绝、要么排队、要么降级，而不是让它去抢别人的资源。

2. 资源隔离到底在隔离什么

2.1 CPU与并发隔离

CPU 隔离是个容易让人误解的概念。容器化环境下，cgroup 的 cpu.shares 控制的是 CPU 时间片的权重，不是绝对上限。举个例子：两个容器权重分别是 1024 和 1024，当只有一个容器的任务需要 CPU 时，它可以占满所有核；只有两个容器同时竞争时，才会按权重分配。

这在 OLAP 场景里导致了两个经典问题：

• 突刺问题：某个查询突然发起了 50 个线程，虽然容器的 CPU 权重不高，但其他任务恰好不需要 CPU 时，它可以瞬时吃满所有核，导致其他任务的“偶发变慢”。
• 权重误判：你以为给项目 A 配了高权重就能高性能，但如果项目 B 的任务持续占着 CPU 不放，高权重也只能在调度周期内获得更多份额，无法硬性阻止 B。

实际操作中，真正的 CPU 隔离要配合两层机制：一是每个查询的并发度限制，比如在 Presto 里限制单个 query 的 split 并行度，在 Spark 里限制单任务的 executor 数量；二是节点的最大并发查询数，这和 CPU 核数是强相关的。我们后来遵循的经验值是：节点并发查询数不超过 vcore 数的 2 到 3 倍，超过的查询排队等待。

2.2 内存隔离

内存是 OLAP 资源隔离中最核心、最难做也是最先崩的一层。

难点在于 OLAP 查询的内存占用是动态变化的。一个 join 操作，build 阶段的内存是线性增长的；一个 order by，内存随输入数据变化；一个 group by，distinct 基数决定了内存占用。你无法用静态配置精确预测。所以主流 OLAP 引擎都采用两层内存保护：

• 单查询内存上限：比如 Presto 里的 query.max-memory-per-node，Doris 里的 exec_mem_limit，超过该限制的查询直接失败，而不是继续拖垮节点。
• 节点总内存池上限：比如 Presto 的 JVM 堆内/堆外配置、Doris 的 MemTable 限制，保证一个节点上所有查询的总内存不会超过物理内存的安全水位。

这两层缺一不可。只有单查询限制，多个查询并发时总内存仍然可能超；只有总池限制，单条大查询可能直接淘汰所有小查询。

内存隔离还有个隐性成本——预留内存。JVM 堆内、堆外、操作系统页缓存、Spark 的 overhead 都需要预留桶位。我们遇到过“内存看着够，一上线就 OOM”的情况，后来排查发现是只算了 JVM 堆，没算堆外内存和 page cache。最终的预留系数，我个人经验是物理内存的 15%~20% 必须留出来，不能全部塞给查询引擎。

2.3 IO与缓存隔离

IO 和缓存隔离是大多数团队忽略的重灾区。OLAP 引擎普遍依赖内存缓存和本地存储加速，比如 ClickHouse 的 MergeTree 数据部分、Doris 的 BE 节点数据文件、Presto 的 spill 临时目录。这些 IO 路径如果不做区分，容易被某类重 IO 查询拖垮。

一个具体的例子：ClickHouse 集群里，如果分析人员跑一个全表 scan 的大查询，同时实时写入任务的 merge 也在进行，两者争抢磁盘 IO，可能导致写入 backlog 堆积。解决方式通常是给不同账户配置不同的max_execution_time、max_threads和存储卷策略，把分析查询限制在低频存储卷，写入走高性能盘。

缓存隔离也有讲究。很多引擎的缓存是全局共享的，比如 Alluxio 和各类本地 cache。我见过的常见做法是按照业务线拆分 cache 目录或缓存集群，避免一个业务的查询把另一个业务的热数据挤出缓存。这个在业务方对查询延迟极度敏感的公司尤其重要。

2.4 从资源隔离到工作负载隔离

隔离做到一定程度，你会发现纯粹按资源类型去分并不够。更合理的方式是按工作负载类型做逻辑分组，再在每个分组内做资源隔离。

工作负载分类的常见维度：

• 读多写少 vs 写多读少：报表查询与实时摄入，负载模式完全不同。
• 长查询 vs 短查询：短查询要求低延迟，长查询追求高吞吐，不能混在一个队列。
• 关键业务 vs 探索分析：关键业务需要保障，探索分析可以容忍失败和排队。
• 同步查询 vs 异步查询：同步查询要快速返回，异步查询可以慢慢跑。

在 Doris 和 StarRocks 里，这个思想对应的是Workload Group；在 Presto 里是Resource Group；在 Spark 里是调度池 + 动态资源分配。你可以按业务线、按查询类型、甚至按用户名划分工作负载组，每个组再设置资源上限、优先级、并发数。

我自己的习惯是：任何新业务接入 OLAP 前，先回答一个问题——它属于哪类工作负载、允许的最大查询时间是多少、最多占集群多少比例资源。答不上来的业务，接入后大概率会出问题。

3. 调度策略：从防崩溃到提效率

3.1 三类主流调度策略

先说调度器层面。YARN 的 Capacity Scheduler 和 Fair Scheduler 是 Hadoop 生态最常见的选择，理解这两个就够用了。

Capacity Scheduler是典型的队列配额制。你把集群总资源按比例分给多个队列，每个队列内部再按 FIFO 或优先级执行。好处是配额隔离，坏处是空转浪费——某个队列没任务时，它的配额别人不能占，除非开启“弹性队列”。

Fair Scheduler是动态公平调度。它不固定配额，而是按任务数动态分配，让所有运行中的任务尽量获得均等资源。好处是利用率高，坏处是单任务的稳定性差，任务数增多时每个任务获得的资源都会下降。传统大数据面试题里喜欢问这两个的区别，本质上就是在考隔离性和弹性之间的权衡。

但我得说一句：在现代 OLAP 引擎中，YARN 调度器的作用更多是资源池管理，真正的查询级调度是由引擎自身完成的。比如 Presto 的 Resource Group、Doris 的 Workload Group、ClickHouse 的处理线程池。底层的 YARN 只解决“谁可以坐在这张桌子上”，引擎才解决“这张桌子上谁先吃哪道菜”。

3.2 优先级、配额与公平性

调度策略设计的核心，是在三个要素之间找平衡：优先级、配额、公平性。

优先级控制的是“谁先获得资源”。最常见的有三种：

• FIFO：先来先服务，实现简单，但长任务会阻塞短任务。
• 公平调度：所有任务按比例摊资源，短任务不会被长任务卡死，但关键任务无法获得比普通任务更多的资源。
• 加权公平/加权轮询：按权重分配资源，高权重任务获得更多时间和资源配额，这是现代 OLAP 引擎的主流方案。

配额控制的是“谁最多能用多少”。优先级决定顺序，配额决定上限，两者结合才能既保证关键任务优先，又防止关键任务过度消耗集群。

公平性不只是任务之间的公平，还包括用户和团队之间的公平。A 团队一次性提交 100 个查询，B 团队只提交 1 个查询，如果完全按任务数量平分，B 团队会被挤死。合理的设计是，先按团队配额分资源，团队内部再按优先级和公平性执行。

我经历过一个反面案例：某团队为了提升任务执行效率，把他们的查询优先级全部设为最高。头一周效果很好，第二周其他团队集体投诉响应变慢。后来的解决方案是，最高优先级每天只有一定的配额，用完自动降级。这就说明：优先级不能脱离配额存在，否则高并发的高优先级任务会挤掉所有其他任务。

3.3 动态调度：弹性与稳定性之间的平衡

动态调度是这几年比较火的方向，核心思路是：不是每个任务都按固定资源规格提交，而是根据任务的实际压力和集群负载动态调整资源分配。

在 Spark 上，动态资源分配可以做到：executor 空闲 60 秒以上自动释放，新任务到来时按需重新申请。配合外部 shuffle service，executor 的增减不会影响正在运行的任务。

Presto 和 Trino 的动态资源组管理则更细腻：可以在运行时调整某个资源组的 CPU 权重和内存上限，起到“限流”的效果。比如大促期间，把高优业务的并发数放宽，同时把非核心查询的内存限制收窄。

弹性调度的核心矛盾是：弹性越强，集群稳定性越差。因为资源释放和申请有延迟，频繁扩缩会导致任务启动等待时间变长，甚至因为资源突然被抢占而执行变慢。我的建议是：先做分级，再做弹性。把任务分成核心、稳定、弹性三档。核心任务固定资源，稳定任务在一定范围内波动，只有弹性档允许大幅扩缩。这样至少能保证核心链路不抖动。

4. 主流OLAP引擎的资源隔离实现对比

4.1 Presto/Trino：资源组与内存限流

Presto/Trino 是 OLAP 引擎中资源隔离设计最成熟的。它提供了Resource Group机制，支持三个维度的限制：

• 并发限制：资源组内同时运行的最大查询数。
• 内存限制：组内所有查询的累计内存上限，超限的新查询排队。
• 调度权重：组之间的 CPU 调度优先级权重。

实际使用中，Resource Group 的配置文件是 JSON 格式，可以通过 orchestrator 动态调整而无需重启集群。这是我们当时为什么选 Presto 作为即席查询引擎的关键原因之一。

Presto 的一个难点是内存的管理模型。它区分 JVM 堆内和堆外内存，query.max-memory-per-node 控制单个查询在单节点上的内存，query.max-total-memory-per-node 还包含了堆外内存。后者经常被忽略，导致查询触发了堆外淘汰。配置时需要留足系统开销。

4.2 Doris/StarRocks：Workload Group与查询排队

Doris 和 StarRocks 的Workload Group特性才是真正对标的“资源隔离”功能。一个 Workload Group 可以独立配置：

• CPU 权重和 CPU hard limit（开启 enable_workload_group_cpu_hard_limit 后可以硬限制 CPU 使用率）。
• 内存百分比上限。
• 查询并发数上限。
• 查询排队和队列长度。

在 2.x 版本之后，StarRocks 的 Workload Group 还支持了对数据导入和查询的分离。你可以把实时导入放进单独的 group，让导入和查询互不干扰。这对典型的实时数仓场景帮助很大。

Doris 早期版本更依赖用户的 resource tag 来划分节点资源，也就是将不同类型的 BE 节点打标，查询按标签路由到不同节点。这种物理隔离最彻底，但成本高。现在的 Workload Group 是逻辑隔离，结合两者效果更好。

4.3 ClickHouse：用户配额与线程池限制

ClickHouse 的资源隔离策略和传统 MPP 引擎不太一样，它更侧重于用户级配额（Quota）和线程池限制。

每个用户配置文件（users.xml 中 profile）可以设置：

<profiles> <readonly_queries> <max_memory_usage>10000000000</max_memory_usage> <max_execution_time>60</max_execution_time> <max_threads>16</max_threads> <max_result_rows>10000000</max_result_rows> </readonly_queries> </profiles>

注意，ClickHouse 默认情况下没有全局的“查询队列”机制。并发过高时，查询会在处理线程池里排队等待。设置max_threads太高会使单查询占用过多 CPU，太低则浪费硬件。经验值是单机查询并发控制在 vcore 数的 2 倍以内比较安全。

ClickHouse 还支持异步插入和 Kafka 表引擎，这些写入任务需要单独设置线程池和内存限制。我们曾经因为写入 merge 和查询抢占资源导致查询延迟上升，后来通过给 merge 单独配低线程数才解决。

4.4 Spark SQL在OLAP场景下的资源分配

Spark SQL 做 OLAP，通常不像 Presto 那样面向低延迟场景，更多是重 ETL 和明细层加工。它的资源隔离主要靠YARN 队列 + 动态资源分配（dynamicAllocation）。

核心配置：

spark.dynamicAllocation.enabled=true spark.dynamicAllocation.initialExecutors=5 spark.dynamicAllocation.minExecutors=2 spark.dynamicAllocation.maxExecutors=50 spark.shuffle.service.enabled=true

其中，shuffle service 必须开启，否则 executor 动态释放时，未完成的 shuffle 数据无处存放。

Spark 的 FILO 和 FAIR 调度器也很值钱。FAIR 调度模式下，可以按池子配置 maxResources 和权重，实现多团队共享一套 Spark 集群。

我实际用的方式是：把 Spark 集群按业务线划分到多个 YARN 队列，然后在队列内开启 dynamicAllocation，同时设置相对保守的 maxExecutors 峰值上限，避免某个业务把自己跑满而影响其他队列。

4.5 引擎特性对比速查

这张表不是绝对标准，每个产品线版本差异很大。但你可以用这个框架去评估自己使用的引擎：它隔离的粒度是什么？排队机制是什么？运行时能否动态调整？这三个问题的答案，基本决定了一套系统的资源管理思路。

5. 落地一套调度与隔离方案的全过程

5.1 先定义SLO和业务等级

任何资源隔离方案，如果脱离业务目标，都会变成“为了隔离而隔离”。我的落地路径第一步永远是写 SLO，形式很简单：

• P0 业务：例如线上看板、核心报表，目标 P99 延迟 3 秒，月可用性 99.9%，不允许多重失败。
• P1 业务：例如分析师常规查询，目标 P90 延迟 30 秒，不长期阻塞即可。
• P2 业务：例如临时探索、研发联调，要求最低，允许排队和失败。

有了这个分级，你才算有资格去设计资源配额。配额比例通常 P0 占 40%~50%，P1 占 30%~40%，P2 占 10%~20%。不要试图做到物理隔离式的绝对公平，那不是 OLAP 场景的目标。

SLO 定义中容易犯的错误是只写延迟目标，不写吞吐和并发峰值。两个都要有，否则大促期间业务方要求“所有查询 100% 成功”，你整个集群直接停机保护才能满足。后来我们约定豁免条件：单业务并发超过某个阈值时，SLO 自动失效，这比硬扛靠谱。

5.2 配额、优先级与排队的设计

设计资源隔离规则时，我的原则是从内到外：先做引擎级隔离，再做底层资源池隔离，最后接入层控制。

以我们的 Presto 集群为例：

• 先建 Resource Group，给 P0/P1/P2 各建一个组，配置并发上限和内存上限。
• 再在接入层（我们用的是统一的 SQL Gateway）按用户和业务解析出应该进哪个资源组，传递到 Presto 的 session 属性中。
• 最后在 YARN 层面，确保 Presto 工作节点本身只使用该集群配额，避免和 Flink、Hive 混跑。

排队策略我通常选择“低并发 + 短队列”而非“高并发 + 长队列”。原因很简单：高并发会让每个查询都变慢，用户体验更差；短队列可以让多余请求快速失败，业务方就能第一时间知道系统有压力，而不是傻等超时。具体参数需要压测：

• 观察不同并发下查询延迟的拐点。
• 基于拐点的 60%~70% 设置并发上限，预留一些突发空间。
• 队列长度不超过并发上限的 3 倍，超出直接拒绝。

5.3 压测与参数调优

资源隔离方案上线前必须压测，否则你根本不知道参数是不是合理的。压测的核心是复现真实负载，而不是用脚本打满 CPU 看集群什么时候跪。

我常用的做法：

1. 从真实查询日志中抽取过去 30 天的查询分布，按类型、表、延迟、内存占用，保留 1% 的大查询、5% 的中等查询、94% 的小查询。
2. 使用开源的压力工具或自研脚本按比例并发回放。
3. 逐步加压，记录查询延迟、失败率、内存使用率三个指标。
4. 找到失败率和延迟突然抬升的“临界并发数”。
5. 在临界值基础上放宽 20%~30% 冗余，设置为正式并发限制。

压测中最容易出问题的是“典型查询”选取不当。如果你选的都是 10 毫秒返回的简单查询，压出的并发上限会虚高。真实环境里偶尔会有全表扫描的疯狂查询，必须把这类查询也纳入压测样本。

调优的时候，不要一次性改多个参数。我们改参数的习惯是“一次只改一个变量”，改完压测一轮，对比延迟和失败率。否则多个变量同时变化，你根本定位不到问题出在哪。

5.4 监控、告警与复盘

资源隔离方案上线后，监控是第一优先级。至少要覆盖以下指标：

• 引擎层：各资源组的查询数、排队数、失败数、平均延迟、内存使用率、CPU 使用率。
• 任务层：每个查询的资源组归属、等待时间、执行时间、所耗内存。
• 宿主层：节点内存、CPU、IO 等待、磁盘使用率、GC 频率。

告警规则不要只设“查询失败率超过 10%”这种一刀切。更精准的做法是分资源组设置不同的告警阈值：P0 组延迟超过 3 秒即告警，P2 组可以放宽到 60 秒。告警要带上资源组的名字，这才能快速定位是哪个业务线出了问题。

复盘这一环，很多团队直接省略。我强烈建议每周抽时间去翻一遍排队和拒绝的查询日志，看看有没有反复被拒的查询、有没有可以优化的慢 SQL。很多资源问题，根因不全是资源不够，而是有一条极度低效的查询反复提交。把这条 SQL 优化掉，比加十台机器还有用。

6. 常见问题与排查技巧

6.1 配了内存限制却仍然OOM

这是最常见的问题。原因是“内存限制”通常只作用于查询引擎的内存计算，但操作系统层、JVM 堆外、网络缓冲、排序溢出文件都可能产生额外内存。

排查方向：查看容器监控中的 RSS 内存是否持续超过配置值；检查是否开了太多的 concurrent 查询导致叠加超出；确认引擎的 spill 机制是否开启，比如 Presto 的 task-level spill、Doris 的 spill 目录配置。

解决方案通常是三层同时调整：降低单查询内存上限、增加引擎外的预留内存比例、把同一节点的最大并发数降下来。

6.2 查询排队时间长但响应依旧慢

资源组里排队数少的时候，查询提交后仍然慢，这时候大概率不是资源隔离问题，而是某个大查询占用了较多资源导致其他查询被压制。

我用过非常有效的定位方法：在查询管理界面中找到所有正在运行的大查询，逐个看它们所属的资源组和内存使用。假如是 P2 组的全表扫描查询把节点 IO 打满，那 P1 组的查询不可能不慢。治理手段是给 P2 组设置更严格的 CPU 和内存上限，必要时直接按行数限制查询结果集。

但也要注意，如果所有组都慢，很可能是物理资源真的不够了。判断标准是看节点 CPU 在非查询高峰期的负载，如果 idle 时间低于 20%，建议扩容而不是调参。

6.3 紧急任务抢不到资源

业务方经常要“紧急捞数”，如果资源组的优先级和配额设置太刚性，紧急任务就永远抢不到资源。这种情况不能靠实时调参，因为人的反应速度赶不上查询提交速度。

我们的解决方案是建一个“紧急通道”资源组，这个组的资源配额平时很低甚至为零，但允许通过提交方凭证临时借调资源。每次借调有熔断机制：紧急组的总内存不能超过集群容量的 10%，超过则拒绝部分任务。这样可以保证紧急任务能启动，又不会失控。

另外一个经验：紧急任务发起人必须报备，系统记录提交者、业务、查询影响范围。这样出了事能追溯，也能倒逼业务方思考：是真的紧急，还是平时舍不得排优先级。

6.4 集群资源利用率飘忽不定

资源利用率低，很多人的第一反应是调度策略还不够激进，于是把并发调大，结果利用率上来了，延迟也上来了。这就是没有把 SLO 和调度参数绑定导致的。

利用率波动大时，先看时间维度。OLAP 的业务高峰和低谷通常有明显规律，一天内早上十点和下午两点是高峰，凌晨是低谷。合理做法是配置不同时间段的调度策略。比如 Doris 的 Workload Group 支持通过外部计划任务动态修改配置，白天限制分析查询并发，晚上放开给 ETL 任务。

如果一天内的利用率都低，那问题往往出在工作负载本身不够，而不是调度器不行。这种情况下优先考虑合并小任务、减少冷数据查询次数，甚至考虑缩减集群规模，别为了利用率而强行造负载。

7. 资源隔离与调度之外的思考

资源隔离和调度策略做到最后，你会发现它不只是技术问题，更是组织管理问题。技术方案再先进，如果业务方没有合理的资源使用规范，依然会出问题。我分享几个非技术但非常关键的经验。

第一，资源使用要“可视化”。给业务方提供一个自助查询工具，能看到自己的查询用了多少资源、排队多久、有哪些慢查询。当业务方自己能查的时候，很多“为什么我这么慢”的反馈会减少一大半，因为他们自己就能定位问题。

第二，预算化管理。每个季度和业务团队对齐预算，量化“我们这个季度预计消耗多少查询资源、允许失败率多少”。预算制的效果是，业务方在提交大查询之前会主动评估必要性，而不是无脑全量跑。

第三，定期做资源治理。轮询所有注册到 OLAP 引擎的业务方，下线长时间不用的查询任务和用户权限。旧业务下线后遗留的定时任务，是资源黑洞的常见来源。我们有一次清理掉了二十多个无人认领的定时报表，直接释放了大约 15% 的集群资源。

第四，培养“先看计划再提交查询”的团队习惯。让使用方在上线查询前先看执行计划，确认分区过滤、join 顺序、扫描行数都是合理的。很多资源浪费在第一次提交就注定了，事后怎么调调度策略都是亡羊补牢。

还有一个我自己摸索出来的小技巧：给查询打上版本号或标签。所有接入 OLAP 的查询，在 SQL 前加上描述性注释，比如业务方、目的、期望返回时间。排查问题、做资源审计时，这些注释能帮你迅速定位到责任人，而不是去猜这个查询是谁提交的。

技术层面的资源隔离和调度，本质上是在一个共享系统里为不同需求划定边界，并为这些边界建立合理的仲裁规则。没有一套参数可以通吃所有集群，你必须基于自己的业务特征、团队协作模式、甚至业务方的技术能力来定制方案。但底层的思考框架是稳定可复用的：先定 SLO，再定优先级和配额，再设计排队和拒绝，最后用监控和复盘把方案打磨到稳定。只要这套框架立住了，无论你用的是 Presto、Doris、ClickHouse 还是自研引擎，都能设计出一套适合自己的资源治理方案。

回到开头那个事故。后来我们重建了资源隔离体系，把报表、即席、探索三类查询彻底分池，限制了大查询的内存上限，也把调度策略改成了加权公平。再遇到类似的全表扫描查询，它只会把自己所在的资源组拖垮，核心报表可以稳定不受影响。我到现在都记得那段时间每天盯着监控，看 P0 组的延迟曲线一点点回归稳定时的感觉——那种从“天天救火”到“终于能睡个整觉”的转变，就是资源隔离和调度策略带来的最直观价值。