企业官网建设流程全解析

查询路由的工程实现

自适应反馈与成本估算

—— 电力装备制造业数据治理系列 · Vol.2 · 13

1. 引言：查询路由的工程价值

电力装备企业的数据基础设施常常呈现「多引擎并存」状态: 老 Oracle 跑事务, 新 Doris 跑实时分析, Trino 做联邦查询, 客户既有 Hive 跑历史报表。同一条查询在不同引擎上的代价差异可达 10-100 倍——选错引擎可能从「秒级」退化为「小时级」。「查询路由」是 L1 解决这一问题的核心能力。

2. 痛点深扫描

2.1 查询路由的三类典型场景

• **单表大查询**: 100M 行表的 GROUP BY, Doris 5 秒, Oracle 5 分钟, Hive 30 分钟；
• **多表 JOIN**: 5 表 JOIN, Trino 30 秒, Doris 1 分钟, Oracle 10 分钟；
• **实时点查**: 单点查询, Doris 100ms, Trino 500ms, Oracle 50ms（OLTP 优势）。

如果固定用一个引擎, 必然在某些场景表现糟糕. 必须基于查询特征智能选择。

2.2 错误路由的损失

• **性能损失**: 错选引擎导致查询慢 10-100×；
• **资源浪费**: 简单查询路由到大引擎, 浪费集群资源；
• **用户体验**: 用户等待时间长, 失去对系统信任。

3. 解决方案：自适应反馈路由

图 1：查询路由的自适应反馈闭环

3.1 成本估算 (Cardinality + 选择度)

查询路由的第一步是「成本估算」——估算查询在每个候选引擎上的代价。关键依赖:

• **Cardinality 估算**: 估算查询返回行数（详见本卷 Vol.2 第 19 篇）；
• **选择度估算**: 估算 WHERE 谓词的过滤率；
• **引擎特征**: 每个引擎的 JOIN / GROUP BY / Filter 代价模型；
• **数据本地性**: 数据所在引擎的查询代价更低。

3.2 自适应反馈闭环

成本估算不是「一次性」, 而是「持续优化」的:

1. 查询执行后, 记录「估算成本 vs 实际成本」的差异（Q-error）；
2. 差异大的查询作为「训练样本」反馈到模型；
3. 在线学习更新成本模型（小批量、增量、持续）；
4. 下一次类似查询的估算更准确。

4. 实施路径

1. **Phase 1（M1）数据采集**: 收集历史查询日志, 提取 (查询特征, 执行引擎, 实际代价) 训练数据；
2. **Phase 2（M2-M3）静态模型**: 训练基于直方图 + 选择度的传统代价模型；
3. **Phase 3（M3-M4）路由器上线**: 路由器对新查询估算 + 选最优引擎；
4. **Phase 4（M4-M6）反馈闭环**: 启用自适应反馈, 持续优化；
5. **Phase 5（M6+）Learned 模型**: 高级场景引入 MSCN 等 Learned 模型。

5. 价值数据

6. 工程见解与边界

6.1 「路由器」必须轻量

查询路由器自身的延时必须远小于查询执行时长, 否则得不偿失. 工程实践: 路由器决策必须在 < 50ms 内完成。

6.2 局限性

• **新查询模式无样本**: 完全新的查询模式没有历史数据, 估算不准；
• **引擎切换的连接开销**: 每个引擎的连接池预热成本；
• **复杂查询难以路由**: 跨引擎 JOIN 在 L1 路由层难处理。

参考资料

[1]Kipf A, et al. Learned Cardinalities: Estimating Correlated Joins with Deep Learning. CIDR 2019.

[2]Selinger P G, et al. Access Path Selection in a Relational Database. SIGMOD 1979.

[3]Leis V, et al. How Good Are Query Optimizers, Really? VLDB 2015.

[4]Marcus R, et al. Bao: Making Learned Query Optimization Practical. SIGMOD 2021.

[5]Begoli E, et al. Apache Calcite. SIGMOD 2018.