Amazon Athena：ODBC查询速度较Grafana慢约10倍（同数据）

问题背景 #

我正在用Amazon Athena查询一个3MB左右的Parquet数据湖，遇到两种场景的性能差异：

• Grafana仪表板：用Athena插件查询S3上的Parquet数据，所有面板查询总耗时2-3秒，主要开销在Grafana与Athena的交互环节（仪表板为OBD2+GPS车辆数据可视化面板）。
• Windows 10 64位 Excel：用v2版Athena ODBC驱动，通过数据透视表连接Athena，复刻了和Grafana几乎一致的报表，SQL完全相同。但刷新相同数量的查询耗时20-30秒，是Grafana的10倍。查看Athena最近查询记录，无论哪种方式发起，Athena端实际查询耗时均约0.5秒（支持多查询并行），因此性能瓶颈在Excel/ODBC的处理环节（Excel报表为复刻的透视表形式）。

我已按标准指南配置ODBC驱动，查询逻辑简单，但无法理解如此大的速度差异。想知道这种ODBC集成的性能表现是否正常，以及如何优化。

共用示例SQL（Athena端耗时约0.5秒） #

SELECT FROM_UNIXTIME(FLOOR(TO_UNIXTIME(t)/2)*2) as Time,
 AVG(latitude) as latitude, AVG(longitude) as longitude 
FROM tbl_3ba199e2_can2_gnsspos 
WHERE date_created 
BETWEEN '2020/10/29' AND '2020/10/29' AND  t 
BETWEEN TIMESTAMP '2020-10-29 15:00:00' AND 
TIMESTAMP '2020-10-29 15:20:00' 
GROUP BY  FROM_UNIXTIME(FLOOR(TO_UNIXTIME(t)/2)*2) 
ORDER BY Time

单独运行该查询时，Grafana中耗时<0.5秒，Excel中刷新单个连接需约5秒，即使在空白工作簿中通过ODBC高级窗口执行并加载到透视表，耗时仍约5秒。

可能的性能瓶颈与优化建议 #

1. ODBC驱动与Excel的处理机制差异 #

Grafana的Athena插件基于REST API直接交互，结果返回后直接用于可视化，无需复杂的格式转换；而ODBC驱动需要在Excel和Athena之间做数据类型映射、内存转换，Excel对时间戳、数值等类型的兼容性校验会额外消耗时间。此外，Excel数据透视表在加载数据时会自动构建索引、同步数据模型，这部分逻辑也会增加耗时。

2. ODBC驱动配置优化 #

检查并调整ODBC驱动的关键配置项：

• 开启Use Resultset Streaming（如果驱动支持），避免一次性拉取全量数据到本地
• 调整Fetch Size参数，设置合适的批量拉取行数（比如1000行），减少网络交互次数
• 禁用不必要的元数据预查询：部分ODBC驱动会自动查询表的列类型、统计信息，可在配置中关闭这类冗余操作

3. Excel连接与加载策略优化 #

• 复用ODBC连接：Excel默认可能每次刷新都重建连接，而连接建立时的AWS SigV4签名、握手流程会消耗时间。在Excel连接属性中设置“保留连接”，避免重复建立会话。
• 跳过透视表直接加载测试：先将查询结果加载到普通工作表，再基于工作表创建透视表。如果耗时降低，说明瓶颈在透视表的模型构建环节。
• 使用Power Query作为中间层：Power Query对数据源的处理更高效，支持缓存、增量刷新，还能在加载到透视表前先完成数据清洗和聚合，减少Excel端的处理压力。

4. 其他排查方向 #

• 升级到最新版Athena ODBC驱动：AWS会定期修复性能相关bug，新版本可能优化了数据传输和转换逻辑。
• 检查网络延迟：确认Excel所在机器到Athena所在AWS区域的网络链路是否存在额外代理或防火墙开销，虽然Grafana正常，但不同工具的网络栈可能有差异。

内容的提问来源于stack exchange，提问作者mfcss