OLAP查询预测：事前治理慢查询与资源调度的实战指南

每次大促后看监控报表，数据平台负责人最头疼的事情不是查询跑不动，而是查询根本没排上队。几十个分析师同时提交复杂OLAP查询，资源被几个跑了一小时的“野查询”占满，真正要紧的看板SQL在后面干等。这种场景我遇到过太多次了，事后加资源、杀进程都只是救火，真正能解决问题的思路，是想办法提前判断“这条查询到底要跑多久、吃多少资源”，让调度系统像交通管制一样，在查询进入执行引擎之前就完成分流。这就是OLAP中的查询预测技术要干的事。

查询预测不是什么新概念，传统数据库的优化器早就在做基数估计和代价估算，本质上也是一种预测。但在大数据OLAP场景下，数据量级从GB到了TB甚至PB，查询复杂度、并发度、资源隔离都比单机数据库复杂得多，预测的难度和收益也都大了好几个量级。这篇文章我想从实际落地的角度，把查询预测拆开讲清楚：预测什么、用什么技术路线、特征怎么设计、模型怎么训练、落地时会踩哪些坑。内容偏实战，适合数据平台工程师、数仓架构师，以及被慢查询折磨过的分析团队负责人。

1. 查询预测到底在解决什么问题

1.1 慢查询治理的“事后”困境

绝大多数平台的慢查询治理，走的都是“事后响应”路线：查询跑挂了，引擎日志报了超时，监控告警响起来，值班同学手动 kill 或者调资源。这套流程的问题是，慢查询已经消耗了集群资源，影响了其他查询，损失已经造成了。哪怕事后把这条 SQL 优化好了，下一次换个写法又来一条，你永远在补窟窿。

“事前预测”则完全不同。如果能在查询提交后、执行前，用几十毫秒的时间估算出它的大致执行时间和资源消耗，平台就可以提前做很多事情：把它放到低优先级队列、限制并发数、拒绝执行、提示用户修改 SQL、或者把它路由到资源更充足的集群。这一切都发生在查询真正消耗资源之前，效果完全是另一回事。

1.2 预测的对象到底是什么

很多刚开始做查询预测的同学，会把问题简化成“预测 SQL 执行时间”这一个目标。但真实场景下，单靠执行时间预测远远不够，至少需要覆盖三个维度：

• 执行时间（Latency）：这条查询跑完大概要多久。用于排队优先级、超时判定、用户反馈预估。
• 资源消耗（Resource Usage）：扫描多少行、读取多少分区、shuffle 多少数据、峰值内存多少。用于资源配额管理、集群水位控制。
• 返回行数（Result Size)：最终返回给客户端多少行数据。这在数据大屏、交互式分析场景很重要，返回几行和返回几百万行，用户体验完全不同。

这三个目标其实是关联的。执行时间往往是资源消耗和数据规模共同作用的结果，但影响权重取决于查询类型。比如大宽表 join 类查询，shuffle 量决定一切；高过滤率查询，扫描行数反而没那么关键。所以实用的预测系统，一般会同时预测多个目标，而不是只做一个回归模型。

1.3 谁能从查询预测中真正受益

查询预测不是所有平台都需要，但它一旦落地，收益最明显的集中在三类场景。

第一类是高并发多租户平台。多个业务线共用一个集群，查询提交频率高，互相抢资源。预测值可以用来做排队优先级，让“预计2秒跑完”的小查询插队，让“预计1小时”的大查询在低峰期执行。

第二类是数据大屏和实时分析场景。大屏背后的 SQL 通常有严格的响应时间要求，比如10秒内出结果。如果预测模型发现某条大屏 SQL 最近几小时的估算执行时间从 5 秒涨到了 20 秒，就可以提前告警，而不是等大屏白屏了才去排查。

第三类是计算成本治理场景。在云上跑 OLAP，资源即成本。查询预测可以辅助做成本预估和计费系统——多跑了一次 10 亿行的全表扫描，花费就要算到对应业务头上。这个需求在网约车、电商、广告这类数据量大的行业尤其突出。

2. 预测技术路线怎么选

2.1 三条差异明显的技术路线

查询预测在技术实现上，主要有三条路线。很多团队会混用，但核心思路各有不同。

第一条是基于执行计划特征的传统回归模型。SQL 提交后，OLAP 引擎先做解析和优化，生成执行计划。从执行计划里提取特征，比如扫描的分区数、预估行数、join 类型、聚合算子数量、shuffle 数据量等，再用回归模型预测执行时间。这条路线和数据库优化器的思路一脉相承，可解释性强，特征相对稳定，是最容易起步的方案。

第二条是基于历史查询日志的时间序列预测。不管具体 SQL 长什么样，只看某类查询在历史上的执行时间变化趋势，用时间序列模型来预测下一次执行的耗时。这里说的“某类查询”通常指按 SQL 模板归类的查询族。这条路线适合周期性明显的业务，比如每天凌晨的离线报表、每周一的周报查询，执行时间往往有规律可循。

第三条是基于查询语义和文本特征的深度模型。把 SQL 文本或执行计划树编码成向量，输入到深度网络里做预测。这条路线的上限最高，能捕捉到复杂模式，但落地成本也最高，需要大量训练数据、GPU资源和特征工程经验。一般团队不建议一开始就上，更多是作为前两条路线的补充。

2.2 我为什么建议从执行计划特征入手

如果是新团队做查询预测，我的建议非常明确：先做执行计划特征 + 树模型这条路。

原因是三点。第一，特征的可获取性强。主流 OLAP 引擎比如 ClickHouse、Doris、StarRocks、Spark SQL，都能通过接口拿到执行计划或者查询的语义信息，不需要额外解析 SQL 文本。第二，模型简单可靠。LightGBM、XGBoost 这类树模型，在千万级样本、几十个特征的场景下就已经能做得很好，不需要 GPU，不需要深度网络，训练和推理开销都很低。第三，可解释性好。树模型可以做特征重要性分析，你能明确知道“扫描分区数量”和“join 数据量”哪个对执行时间影响最大，这在实际排障时非常重要。

而深度模型虽然听起来高大上，但在查询预测这个场景里，最大的问题不是精度不够，而是噪声控制难。执行时间受集群负载、并发竞争、数据倾斜影响极大，同样的 SQL 在不同时间执行，耗时可能相差一倍以上。模型能力再强，标签本身就带着巨大的随机噪声，强行拟合只会过拟合。

2.3 三种路线的适用场景对比

实际生产环境里，我见到的主流方案是“以第一条为主、第二条为辅、第三条待观察”的组合。先把执行计划特征模型跑起来，用时间序列模型去兜底周期性负载，深度模型放到后续迭代规划里，不要一上来就铺开。

3. 特征设计与标签定义：预测模型的地基

3.1 特征不是越多越好，关键看“执行计划说了什么”

查询预测的特征工程，核心问题不是“我能拿到多少特征”，而是“哪些特征真正对执行时间有因果影响”。以 Spark SQL 为例，一个查询从提交到执行完成，可以拆成解析、优化、执行三个阶段。执行计划阶段能拿到的信息，基本决定了这个查询的上限难度。

我从实践中筛出来的高价值特征可以分为四组：

• 扫描特征：扫描的表数量、扫描的分区数、总扫描行数（从元数据估出来的）、平均文件大小。这一组特征决定了 IO 压力的下限。
• 计算特征：聚合算子数量、join 算子数量、join 类型（broadcast 还是 shuffle join）、窗口函数数量、UDF 是否启用、过滤条件下推比例。这一组决定了 CPU 计算量。
• 数据特征：join 涉及的表大小比、数据倾斜程度（按分区行数方差估）、过滤率（where 条件预估的选择率）。这一组最容易被人忽略，但恰恰是预测误差的主要来源。
• 提交特征：查询提交时间点（小时、星期几）、当前集群排队查询数、当前资源组可用 slot 数。这一组捕获的是环境因素，对“同一查询为什么这次比上次慢”特别有帮助。

实际落地时，特征数量控制在 30~50 个左右就够了。太多容易混入噪声，太少又覆盖不了复杂查询的差异。树模型的特征重要性排序能帮你持续做特征筛选。

3.2 标签：预测的“标准答案”怎么定

标签设计看似简单——不就是记录每次查询跑了多久吗？但细节里全是坑。

执行时间标签要注意的是计算口径。是从查询提交开始计算，还是从执行阶段开始计算？是包含排队时间，还是只算实际运行时间？这个口径必须和你的应用场景绑定。如果你用预测值做排队优先级，那就应该排除排队时间，否则高并发时段所有查询的标签都会异常涨高，模型会被带偏。如果你的目标是大屏响应时间保障，那就要包含排队时间，因为用户感知就是从点击开始到结果展示。

资源消耗标签也是一样。内存峰值、shuffle 字节数都有多个采集点，不同采集点差异很大。我建议统一采用引擎日志中 query profile 的统计值，虽然这个值可能和真实物理资源消耗有偏差，但胜在全局一致。预测系统最重要的是口径统一，而不是追求绝对精确。

还需要处理异常标签。查询被 kill、查询超时、集群故障导致的慢查询，这些样本要打标排除，不能让它们污染训练数据。我的做法是加一个 is_valid 字段，靠人工规则加引擎状态码双重判断，过滤掉失败和非正常结束的查询。

3.3 避免数据泄漏：最容易犯的错

数据泄漏是查询预测项目里最常见的错误，而且隐蔽性很强。我见过一个团队做了很久才发现，模型精度高是因为把“实际执行时长”当特征输进去了——当然这是在开玩笑，但类似的问题确实存在。

真正的泄漏风险在执行计划特征和真实执行数据的关联上。比如你用执行计划的“预估扫描行数”作为特征，但这个值如果来自查询结束时更新的统计信息，而不是查询提交时的快照，那它就泄漏了未来信息。正确做法是用解析阶段就能拿到的信息做特征，也就是 SQL 提交那一刻引擎元数据里能查到的分区数、行数估算值。

还有一个容易忽略的点：训练数据的时间切分。查询预测训练和测试数据必须按时间顺序切分，不能随机打乱。因为数据分布和执行环境都随时间漂移，用未来数据训练、过去数据测试看起来精度很高，上线后就崩。这点和常规机器学习项目的做法完全不同，一定要单独强调。

4. 从 0 到 1 搭建查询预测服务的实操记录

4.1 整体架构与数据流

下面直接贴一个可以落地的方案。这套架构我在实际环境中验证过，组件不复杂，但能覆盖绝大多数场景。

整个系统分为四个模块：样本采集模块、特征计算模块、模型训练模块、在线预测服务。

样本采集从 OLAP 引擎的 audit log 和 query profile 入手，抽取每次查询的提交时间、执行计划 JSON、引擎统计信息、最终执行耗时和资源消耗。特征计算模块把执行计划 JSON 解析成扁平特征表，存入样本库。模型训练模块用 LightGBM 定期训练回归模型。在线预测服务加载模型，对外提供 HTTP/RPC 接口，响应要求控制在 50 毫秒以内。

实际部署时，训练是离线的，每天凌晨跑一次增量训练，在线预测服务常驻。查询提交时由网关或 coordinator 同步调用预测接口，拿到预测执行时间、预测扫描行数、置信度三个值，再决定队列和优先级。

4.2 样本表结构设计

样本表是整套系统的核心资产，设计得好，后面做分析、迭代模型都会很顺手。我常用的表结构包含几大块：

CREATE TABLE query_prediction_samples ( query_id STRING, query_text_md5 STRING, sql_template_id STRING, submit_time TIMESTAMP, engine_type STRING, -- spark / doris / clickhouse query_type STRING, -- olap / etl / interactive -- 执行计划特征 scan_table_count INT, scan_partition_count INT, estimated_scan_rows BIGINT, join_count INT, join_type STRING, broadcast_join_flag INT, agg_count INT, window_func_count INT, filter_pushdown_ratio DOUBLE, shuffle_bytes_est BIGINT, max_task_concurrency INT, -- 环境特征 submit_hour INT, submit_dayofweek INT, queueing_query_cnt INT, cluster_cpu_usage DOUBLE, -- 标签 execution_time_ms BIGINT, actual_scan_rows BIGINT, actual_shuffle_bytes BIGINT, peak_memory_mb INT, is_valid INT );

sql_template_id字段值得多说两句。它是对 SQL 做模板化后生成的 ID，把字面量替换成占位符，比如SELECT * FROM orders WHERE user_id = 123和WHERE user_id = 456属于同一个模板。这个字段在做分群分析、冷启动处理、周期性预测时非常好用。

4.3 模型训练关键参数与效果

特征准备好后，我直接用了 LightGBM 的回归模型，目标值是execution_time_ms的对数。为什么要取对数？因为执行时间分布极度右偏，从几十毫秒到几小时都有，直接用原始值训练，模型会把注意力全放在大查询上。取对数后分布接近正态，模型拟合效果明显提升，预测值再指数还原即可。

训练参数我放在这里，这套参数在千万级样本下效果比较稳定：

import lightgbm as lgb params = { 'objective': 'regression', 'metric': 'rmse', 'learning_rate': 0.05, 'num_leaves': 127, 'max_depth': 7, 'min_child_samples': 100, 'feature_fraction': 0.8, 'bagging_fraction': 0.8, 'bagging_freq': 1, 'lambda_l1': 0.1, 'lambda_l2': 1.0, 'n_estimators': 2000, 'early_stopping_rounds': 50, }

训练过程要注意样本权重调整。如果线上数据中大查询占比很低，模型会对大查询预测不准。我在实践中按查询耗时分桶，每个桶内样本等权采样。这样小查询样本被降权，大查询样本被提权，虽然整体 RMSE 会略微上升，但 P90 以上的预测误差改善非常明显——对大查询的预测准确度，才是查询预测系统的核心价值。

最终的效果，在一套 2000 节点的 Spark 集群上，执行时间预测的误差中位数在 25% 左右，P90 误差控制在 60% 以内。如果只看同一模板类查询的相对排序，准确率还会更高。这个精度用来做排队优先级已经足够，用来做成本预估也基本可用。

4.4 在线预测服务与调度策略对接

在线预测服务的核心逻辑很简单，加载模型文件，拼特征，走推理。但实际工作里，真正的难点在预测结果怎么被消费。

以排队系统为例，网关拿到预测执行时间后，可以按这个思路分配优先级：

• 预测执行时间小于 10 秒：高优先级队列，几乎不排队。
• 预测执行时间在 10 秒到 1 分钟：中优先级队列，限制最大并发数。
• 预测执行时间超过 1 分钟：低优先级队列，在资源富余时才执行。
• 预测执行时间超过 1 小时：直接返回建议，提示用户修改 SQL 或走离线批处理通道。

规则看起来简单，但配合上预测置信度就能做得更精细。模型不只输出预测值，还可以输出置信区间，比如“预测 30 秒，80% 概率落在 20~50 秒之间”。对于置信度低的查询，调度系统宁可保守一点，放低一档优先级，避免它冲击线上稳定性。

这里有一个非常重要的工程经验：预测服务和调度解耦。不要把预测逻辑写进引擎主进程里，而是通过独立服务对外提供能力。这样引擎升级、预测模型迭代、调度策略调整可以各走各的发布流程，互不阻塞。

5. 常见故障与排查技巧实录

5.1 预测值系统性偏低，然后线上查询真的超时了

我遇到过最诡异的问题：模型离线评测准确率不错，上线后却发现预测值整体偏低 30%，尤其是大查询偏得更厉害。

排查到最后发现，问题出在训练数据里“被杀掉的查询”被当成了正常样本。平台有超时机制，超过 30 分钟的大查询会被自动 kill。这些查询的 execution_time_ms 记录的是“被杀前运行的时间”，而不是“正常完成需要的时间”。比如一条本来要跑 50 分钟的查询，跑 30 分钟就被杀了，样本里它的执行时间就是 30 分钟。模型学到的规律是“这类查询大约 30 分钟”，但真实需求是 50 分钟，预测值自然系统性偏低。

解决方案就是在is_valid字段里加状态过滤，把非正常结束的查询全部排除，另外专门建立一个“被 kill 查询表”，用于分析这类查询特征和真实执行时长。

5.2 模板划分过粗，同模板查询执行时间差异巨大

SQL 模板化是把“具体查询”归到“查询族”的重要手段，但粒度把握不好就会出问题。最典型的是把SELECT * FROM orders WHERE dt = '2024-01-01'和SELECT * FROM orders WHERE dt BETWEEN '2024-01-01' AND '2024-01-31'归到同一模板，前者扫描一天分区，后者扫描一个月分区，执行时间差几十倍。

这种场景下，纯靠执行计划特征也能捕捉到分区数量的差异，但如果你用了很多“模板级”的统计特征，比如模板历史平均执行时间，就会被这种粒度问题带偏。我的经验是给模板特征加上“分区数区间”做交叉拆分，比如模板 + 分区规模分桶，组合成一个更细粒度的“查询类”。这样历史统计特征才真正有用。

5.3 冷启动：新 SQL 第一次执行怎么预测

线上系统总会不断出现新 SQL。新查询没有历史记录，模板可能也没见过，模型特征里的“模板历史平均执行时间”是空的，预测精度大打折扣。

冷启动的处理没有银弹，但可以组合使用三个策略。第一是回退到纯执行计划特征模型。训练模型时保留一部分样本，这些样本不带任何模板统计特征，专门用于冷启动预测。第二是相似模板匹配。用执行计划的结构相似度找最相近的模板，借用它的历史统计值做兜底。第三是保守化处理。对冷启动查询，统一在预测值上乘一个 1.5 的系数，宁可高估、不可低估。预测偏高的成本只是排队多等一会，预测偏低的成本是资源被长时间占用，两者的风险完全不对称。

5.4 特征漂移：周一凌晨模型为什么集体失效

查询预测的另一个隐形杀手是特征分布漂移。业务方改了表结构、换了 SQL 写法、数据仓库做了分区策略调整，都会导致执行计划特征分布发生变化。模型在旧分布上训练，遇到新分布自然就失灵了。

我的建议是每天监控特征分布的核心指标，比如“平均扫描分区数”“broadcast join 占比”。一旦发现和训练集分布偏差超过阈值，就触发强制重训练，而不是等每天定时的增量训练任务。这个监控看着不起眼，但它是保证查询预测系统长期可靠的最后一道防线。

6. 查询预测的运营落地经验

6.1 从“预测准”到“有价值”还差一步

很多团队做完查询预测模型后，发现业务方根本不买账。原因是模型再准，如果调度策略不配套，预测值就只能躺在日志里。必须想清楚预测结果到底改变什么决策。

我在项目里最常用的落地路径是三个场景一起推：排队优先级调整、内存/资源组配额预分配、慢查询提前预警。排队优先级是最容易见效的，直接改善用户体感。资源配额预分配适合存算分离架构，提前把计算资源分给预测要执行的查询，避免冷启动的资源争抢。慢查询预警则是给值班同学用的，预测超过阈值提前介入审查SQL，不用等超时告警。

6.2 业务反馈闭环

预测系统要不断变准，不能只靠模型团队自己折腾，必须建立业务反馈闭环。最简单实用的机制是把预测值和实际执行值的差异写到一张单独的对比表，每天更新，并在数据平台上做可视化展示。分析师可以看到自己提交的查询预测耗时和实际耗时，误差大的可以点反馈按钮。

反馈数据积累到一定程度，可以做分业务线、分查询类型的误差分析，找出系统性的偏差来源。比如“某业务线的查询经常被预测偏低”，那可能这个业务线的数据倾斜特征没有建模好，可以针对性补充特征。

根据我个人的体会，查询预测这种偏底层的平台能力，最大的难点从来不是算法，而是工程质量。特征口径的一致性、样本有效性的管理、预测结果和调度策略的联动，这些才是决定项目能否长期跑下去的关键。从最简单的 LightGBM 回归起步，把数据管道和运营闭环搭好，再逐步迭代复杂模型，这条路是最稳的。后面如果要扩展，可以往资源成本预测、跨集群调度、查询推荐这些方向走，但前提是前面的地基已经打得足够扎实。