trino 联邦查询能力远超 presto，因其 connector 深度参与优化器，支持谓词/limit/projection 下推；presto connector 接口受限，跨源 join 易退化为本地内存 join 导致 oom。
Trino 和 Presto 的联邦查询能力差异在哪
Trino（原 PrestoSQL）和 Presto（Facebook 维护的 prestodb）现在是两条独立演进路线，联邦查询支持完全不对等。Trino 主动重构了 connector 架构，connector 可以完整参与优化器计划生成，而 Presto 的 ConnectorMetadata 接口限制多，跨源 join 时容易退化成单边拉取 + 内存 hash join，查大表直接 OOM。
实操建议：
- 用
trino-server时优先选 Trino，不是因为“新”，而是SystemConnector、IcebergConnector、JdbcConnector等都默认支持下推谓词、limit、projection；Presto 对 Iceberg 的table_statistics下推基本不生效 - 如果必须用 Presto（比如遗留调度系统强绑定），别碰跨 Hive + MySQL 的复杂 join，改用物化视图或导出中间表，否则
Query exceeded per-node user memory limit是常态 - 检查 connector 是否真正支持 pushdown：执行
EXPLAIN (TYPE DISTRIBUTED) SELECT * FROM hive.default.t1 JOIN mysql.db.t2 ON t1.id = t2.id，看 plan 里有没有RemoteExchange提前出现在 join 下方 —— 有，说明做了远程过滤；没有，就是本地拉全量
Hive Metastore 能不能直接当 Trino 的统一元数据中心
能，但只限于 Hive、Iceberg、Delta Lake 这类本身依赖 HMS 的 catalog。Trino 的 hive connector 会直连 HMS 获取表结构和分区信息，但不会自动识别非 HMS 管理的数据源（比如 S3 上裸 Parquet 目录）。
实操建议：
- 别把
hive-metastore.uri配给所有 connector，只配给hiveconnector；其他数据源（如 PostgreSQL、MongoDB）走各自独立的 connector，靠 Trino 的CROSS JOIN或UNION ALL关联 - HMS 版本要 ≥ 3.1.0，否则 Trino 400+ 无法正确读取 Iceberg 表的
current_snapshot，报错Table is not a valid Iceberg table - 如果用了 AWS Glue Data Catalog，就别再配 HMS，直接用
glueconnector，它和hiveconnector 不兼容共存，混用会导致TableHandle is null
Spark SQL 做联邦查询到底行不行
不行。Spark SQL 本质是批处理引擎，没有原生联邦查询设计。所谓“跨源查询”实际是靠 DataFrameReader 分别读取各源再本地 join，所有数据必须落内存或磁盘，不支持谓词下推到远端数据库，也不支持流式分片扫描。
实操建议：
- 用
spark.sql("SELECT * FROM hive_table JOIN jdbc_table ...")看似可行，但jdbc_table会被整个扫进来，哪怕加了WHERE id = 123，Spark 也不会把条件传给 JDBC 驱动，除非手动写option("pushDownPredicate", "true")并确认驱动支持（PostgreSQL 支持，MySQL 8.0+ 才部分支持） - 想让 Spark “假装”联邦，得自己写
CustomScan或用第三方项目如Delta Sharing，但这就脱离了 Spark SQL 原生能力，维护成本陡增 - 如果已有大量 Spark 作业，又想加联邦能力，更现实的做法是：用 Trino 暴露 JDBC/HTTP 接口，Spark 用
spark.read.format("jdbc").option("url", "jdbc:trino://...")当一个“超级数据源”来读
为什么联邦查询一跑就慢，但 explain 看不出问题
explain 只显示逻辑计划和调度拓扑，不反映 connector 实际执行行为。常见瓶颈在 connector 层没做下推、网络吞吐打满、远端数据库连接池耗尽，这些都不会体现在 plan 里。
实操建议：
- 开
query.max-memory-per-node同时也调高http-client.max-connections-per-route，否则 JdbcConnector 在并发查多个 MySQL 表时，会因连接复用失败降级为串行请求 - 查 Hive + S3 数据时，确认
s3.iam-role权限包含s3:GetObjectVersion，否则 Trino 会反复 list 前缀做分区裁剪，延迟飙升 - 最易忽略的一点：Trino 默认关闭
optimizer.optimize-hash-generation，跨源 join 时 hash 计算全在 CPU，不开这个开关，CPU 利用率可能卡在 30% 却迟迟不出结果
联邦查询真正的复杂点不在语法，而在每个 connector 的“脾气”——有的认 WHERE，有的只吃 PUSHDOWN hint，有的连 LIMIT 都不接。配错一个参数，整条链路就从下推变成搬运工。
