SQL联邦查询中Athena、Presto、Trino和原生FDW性能哪个更好

SQL联邦查询允许用户在不需要提前做数据迁移的情况下，直接跨多个异构数据源执行查询，是当前数据湖和数据仓库架构中非常常用的能力。不同的联邦查询实现方案底层架构差异较大，性能表现也有明显区别。

核心方案架构差异

首先我们需要了解几类方案的基本架构，这是性能差异的核心来源：

• Athena：是AWS托管的Presto服务，底层基于Presto引擎，原生对接S3数据湖，同时支持对接其他AWS数据源，查询计算资源由AWS托管，按查询扫描的数据量计费。
• Presto：开源的分布式SQL查询引擎，本身不存储数据，通过连接器对接各类数据源，采用内存计算模式，适合交互式查询场景。
• Trino：是Presto的原生分支，对引擎做了大量优化，支持更复杂的查询场景，同时提升了连接器生态的稳定性和性能。
• 原生FDW：指PostgreSQL、MySQL等数据库自带的外部数据包装器，运行在数据库进程内部，通过插件形式对接外部数据源，查询逻辑由数据库自身优化器处理。

性能对比维度与测试场景

本次测试选择三类典型场景，对比不同方案的性能表现：

测试环境说明

所有测试均使用相同规模的数据集：本地MySQL存储1000万行业务数据，S3存储1TB Parquet格式的日志数据，查询节点配置统一为8核32G内存。

场景一：小数据量跨源聚合查询

查询需求：关联MySQL的用户表和S3的日志表，统计每个用户的近7天访问次数，结果集大小约1万行。

各方案查询耗时如下：

这个场景下Trino性能最优，原因是其对小批量跨源关联的逻辑优化更完善，而原生FDW需要将外部数据拉取到本地数据库做关联，网络传输和本地计算开销都更大。

场景二：大数据量全量扫描查询

查询需求：扫描S3的1TB日志数据，统计不同地区的访问量，不涉及其他数据源。

各方案查询耗时如下：

原生FDW基本无法支撑这类大数据量扫描场景，容易出现内存溢出或者查询超时，而Trino对大规模数据扫描的并行度优化更好，吞吐量更高。

场景三：高并发简单查询

查询需求：同时发起20个并发请求，每个请求查询MySQL中的单表数据，不涉及跨源关联。

各方案平均响应时间如下：

高并发简单查询场景下，原生FDW性能反而更好，因为其不需要额外的分布式调度开销，直接走数据库自身的查询链路，而Athena因为是托管服务，冷启动开销较大，高并发下延迟明显升高。

选型建议

根据测试结果，不同场景的选型可以参考以下规则：

• 如果需要托管服务、不想维护集群，且查询以中大型数据量为主，优先选择Athena，适合AWS生态的用户。
• 如果自建数据平台，需要支持复杂的跨源查询和大规模数据处理，优先选择Trino，性能和生态都更成熟。
• 如果查询场景以数据库内部的小数据量跨源查询为主，不需要处理大数据量，原生FDW是更简单的选择，不需要额外部署引擎。
• Presto的适用场景和Trino类似，但整体性能和生态维护活跃度不如Trino，新选型建议优先选Trino。

性能优化示例

以Trino为例，优化联邦查询性能的核心配置如下：

# 调整连接器的数据抓取大小，减少网络请求次数
connector.name=mysql
mysql.split-size=100000

# 调整查询最大内存，避免大查询被杀死
query.max-memory=8GB
query.max-memory-per-node=2GB

# 开启动态过滤，提升跨源关联性能
enable-dynamic-filtering=true

如果是使用PostgreSQL FDW，可以通过以下方式优化性能：

-- 创建外部表时指定合适的行数预估，帮助优化器生成更好的执行计划
CREATE FOREIGN TABLE remote_users (
    id int,
    name text
)
SERVER remote_mysql
OPTIONS (
    table_name 'users',
    row_count '10000000'
);

-- 对常用的过滤字段创建外部表的约束，减少拉取的数据量
ALTER FOREIGN TABLE remote_users ADD CONSTRAINT id_pk CONSTRAINT id_pk PRIMARY KEY (id);

SQL_federated_queryPrestoTrinoAthenaFDW修改时间：2026-06-22 04:15:55