美团AdHoc统一查询引擎实践总结
美团AdHoc引擎演进历程
- 2017年：引入Presto引擎满足高性能查询场景
- 2018年：对Presto做兼容性改进，支持更多Hive语法函数
- 2019年：引入统一引擎架构，支持自动路由(Presto/Spark)
- 2020-2021年：智能规则迭代、自动改写完善，大规模使用
应用场景与特点
| 应用场景 | 查询使用占比 | 计算引擎特点 |
|---------|------------|-------------|
| 计算引擎 | 查询 | 54% Hive (稳定性高，性能差)
46% Presto (稳定性差，高性能) |
| 分析师群体 | 上万人使用，大部分为运营、业务分析师，少部分数据RD |
多引擎架构痛点
- 引擎间语法、函数不兼容
- 分析师难以判断使用哪个引擎
- 排查问题思路不同
- 引擎迭代升级成本高
统一引擎架构设计
- 架构设计：解析层 + 执行层
- 解析层：用户接口统一，兼容存量SQL语法/函数，智能计算适合引擎
- 执行层：支持Presto/Spark等具体引擎
- 优缺点：
- 优点：降低引擎数，减少维护成本；排查问题、日志统一
- 缺点：与引擎解析存在重叠；仍需维护多个引擎；存量查询解析兼容性需解决；架构设计差异大
- 权衡：采用解析层实现统一引擎目标，但模块依赖执行层面临同样问题
统一引擎整体架构
- 核心问题：兼容存量Presto/Spark语法的SQL
- 解决方案：
- 反射加载
- 引擎预测（结合规则策略和模型预测）
- 分类算法：决策树、逻辑回归等
- 训练集构建：cost+prestocost+spark
- 方言改写
- 语法改写：SQL->AST->方言SQL (如SparkSQL)
- 函数映射：通过映射表解决函数名和参数位置差异
- Presto HiveUDF适配器：支持大量存量SparkUDF
- 异常诊断
- 事前分析：语法检查、优化建议、预估耗时
- 事中分析：查询卡住原因、进度问题、执行完成时间
- 错误归因
效果
- 灰度前智能路由1429TP
- 95%时延0.960.91分钟
- 成功率提升：0%→25%→50%→75%→100%
现状问题
- 用户技术自定义函数
- failover时间长
- 重复解析cost粒度粗
- 语法完全对齐
未来展望
- 完善查询事中分析
- 探索两种计算架构的整合
- 基于列统计信息计算cost
- 逻辑执行计划转换路由
- 基于现有引擎实现另一种计算架构
