你打开BI报表，等了三十秒，那个聚合查询还在转圈。旁边的同事已经用Excel把数据拉出来做了三张透视表——虽然他那套数据只有十万行，而你这边是十亿行。这就是Presto出现之前，大数据查询的日常。Hive能跑，但慢得像蜗牛；Impala快，可对文件格式和集群配置挑剔得要命。Presto不一样，它像个轻量级的飞毛腿，不依赖MapReduce那套重机制，直接走内存计算，一条SQL甩过去，秒级返回。今天这篇，咱们就把它从安装到调优，从头到尾捋一遍。
先搞清楚Presto到底解决什么问题。它是个分布式SQL查询引擎，名字从“Presto”变成了现在的“Trino”，但核心逻辑没变：把一条SQL拆成多个任务，分发给一堆Worker节点并行执行，汇总结果。它的杀手锏是跨数据源查询——一个查询里可以同时join MySQL里的用户表和HDFS上的日志表，这在以前想都不敢想。而且它不吃数据，不存储数据，纯靠扫描和计算，所以部署起来特别轻。你不需要像Hive那样先跑个MapReduce作业，Presto启动后，直接连上就能查。延迟从分钟级降到秒级，这才是它让人上瘾的地方。
实战第一步，装起来。别被那些官方文档吓着，Presto的部署其实很直白。三台机器起步，一台Coordinator（协调者），两台Worker。你下载对应版本的tar包，解压，改几个配置文件就行。核心是：表示这台机器当老大，表示不要让老大自己也干活，专心调度。然后目录下放各种数据源的连接配置，比如里写上Hive Metastore的地址，里写上MySQL的JDBC连接串。改完直接，日志在里，看到“SERVER STARTED”就算成了。整个过程十五分钟，比你装个Hive快得多。
配置装完，真正考验人的是SQL写法。Presto的语法大体兼容标准SQL，但有几个坑你必须避开。第一，它默认按列式存储读取，所以你在建表时最好用ORC或Parquet格式，别用文本文件硬扛。第二，Presto对join的顺序特别敏感，小表一定要放在左边，大表放右边，它会自动优化成广播join，把小表复制到每个Worker节点上，速度能差出十几倍。第三，别在查询里写，Presto的列裁剪很聪明，你只取哪几列它就会只扫那几列，全字段扫描纯属浪费内存。举个真实例子：我们之前查用户行为日志，原来写，跑了两分钟；改成，直接掉到十二秒。
性能调优是个无底洞，但有几个参数你设对了，效率立刻翻倍。看，这个决定每个Worker节点最多能用多少内存跑一个查询。设小了容易OOM，设大了又会挤占其他任务，一般按节点物理内存的60%到70%来配。控制每个Worker上并行执行task的线程数，默认16，如果你的机器CPU核数多，可以调到32或64。还有一个容易被忽略的：，开启shuffle数据压缩，网络传输量能降三到五倍，特别是跨机房查询时，这个参数简直是救命的。我见过一个客户，开了压缩后，同样的TPC-DS测试，从800秒降到220秒。
跨数据源查询是Presto最让人上头的功能。你可以在一个SQL里同时查MySQL的订单表和Hive的点击流表，关联算转化率。但注意，跨源join时，Presto会把所有数据拉到一个节点上做hash join，所以千万控制数据量。一个实用技巧：先用子查询把两边的数据过滤到最小集，再join，别上来就全表关联。比如先，把七天内的订单拎出来，再去join点击流，效率和稳定性都强很多。我们生产环境里，经常用这个方式做实时看板，延迟基本控制在五秒内。
说说监控和排错。Presto自带一个Web UI，在Coordinator的8080端口，能看到每个查询的DAG图、每个stage耗时、每个task的输入输出行数。你排查慢查询时，第一眼看哪个stage的耗时最长，点进去看是哪个operator慢——是table scan慢，还是join慢，还是聚合慢。如果是scan慢，大概率是文件格式问题或分区裁剪没生效；如果是join慢，检查小表是否broadcast了；如果是聚合慢，看是不是数据倾斜了。还有一个命令，可以实时看当前session的配置值，方便你临时调整参数做对比测试。
Presto不是万能的，它不适合做复杂的ETL，也不适合跑那种需要写回数据的批处理任务。但论即席查询、交互式分析、跨源联邦查询，它绝对是目前开源界最锋利的那把刀。你不需要等半天才看到结果，不需要为了一个小查询去啃Hive的MapReduce，更不需要把数据到处复制来复制去。装好它，调好参数，写对SQL，你会发现十亿行的表，其实也就一瞬间的事。这个极速体验，值得你花一个下午去解锁。
