在Apache Superset与MySQL间部署Presto能否加速查询？

结论先说：盲目加Presto不能包治百病，能不能解决问题完全取决于你当前超时的根因，以及后续的配套优化是否做到位，很多场景下加了Presto反而会更慢。

哪些场景下Presto确实能解决超时问题 #

• 超时根因是MySQL单节点计算能力扛不住复杂查询：如果Superset上跑的是大范围多维度聚合、多表大表关联、去重计数、漏斗/留存类复杂计算，MySQL单实例CPU、内存打满跑不动，Presto作为分布式MPP引擎，会把计算任务拆分到多个工作节点并行处理，这类计算密集型查询通常能获得数倍到数十倍的性能提升，原来跑几十分钟超时的查询，优化到位的话几十秒就能返回。
• 有跨源关联分析需求：如果你的日志表在MySQL，维度数据在其他存储，之前需要做额外的数据同步、临时表导入才能在MySQL里完成关联查询，Presto支持联邦查询，可以直接跨源关联计算，省掉中间同步的链路成本，间接减少慢查询问题。
• 配置了正确的谓词下推：Presto的MySQL连接器默认会把过滤条件、列裁剪下推到MySQL侧执行，不会无脑拉取全表数据到Presto层计算，不会额外给MySQL增加不必要的负载。

哪些场景下加Presto完全没用，甚至会加重问题 #

• 完全不做数仓建模，所有查询直接扫无分区、无索引的原始日志大表：Presto性能再强，扫描几亿到几十亿行无裁剪的原始数据一样会慢；如果连接器配置错误，没开谓词下推，还会全量拉取MySQL的大表数据，直接打满MySQL的网络带宽，比直连MySQL查询慢好几倍。
• 超时的查询都是简单点查、小范围明细查询：比如查单个用户的几条操作记录、查最近5分钟的少量日志，这类场景MySQL走索引可以毫秒级返回，Presto反而要额外做分布式任务调度、跨节点通信，额外开销会让查询延迟变高。
• Presto部署配置拉胯：比如只部署1个Presto工作节点、内存配置不足、没开查询缓存、连接器参数全用默认值，这种情况下Presto的计算能力可能还不如你现有的MySQL实例，根本起不到加速作用。

实际落地的实操建议 #

• 先做根因排查，不要上来就堆组件：先把MySQL慢查询日志里Superset触发的超时SQL捞出来，看是全表扫描没走索引、是复杂聚合算不动、是MySQL配置太低还是锁冲突导致的慢，对症下药。
• 如果确定上Presto，不要裸接原始日志表：
  • 先给MySQL侧的日志表按日期、核心业务维度做分区，常用过滤字段建好索引，保证Presto下推的过滤条件能在MySQL侧先裁掉90%以上的无效数据
  • 把Superset上高频查询的固定维度指标提前做成预聚合表，按小时/天粒度聚合好，不管是存在MySQL还是Presto的专属存储里，都比每次查询扫原始明细表快一个数量级
  • Presto集群至少配3个以上工作节点，根据查询数据量配足内存，打开MySQL连接器的全量谓词下推配置，开启高频查询的结果缓存
• 做查询路由，不要所有请求都走Presto：简单点查、小范围明细查询仍然保留直连MySQL的数据源，只有复杂聚合、跨源查询走Presto，最大化利用两个引擎的优势。

内容的提问来源于stack exchange，提问作者Công Anh