雅典娜:按比例查询耗尽的资源

Jie*_*eng 5 sql query-optimization amazon-web-services presto amazon-athena

我正在运行类似的查询:

SELECT f.*, p.countryName, p.airportName, a.name AS agentName
FROM (
    SELECT 
        f.outboundlegid, 
        f.inboundlegid,
        f.querydatetime,
        cast(f.agent as bigint) as agent,
        cast(f.querydestinationplace as bigint) as querydestinationplace,
        f.queryoutbounddate,
        f.queryinbounddate,
        f.quoteageinminutes,
        f.price
    FROM flights f
    WHERE querydatetime >= '2018-01-02'
    AND querydatetime <= '2019-01-10'
) f
INNER JOIN (
  SELECT airportId, airportName, countryName
  FROM airports
  WHERE countryName IN ('Philippines', 'Indonesia', 'Malaysia', 'Hong Kong', 'Thailand', 'Vietnam')
) p
ON f.querydestinationplace = p.airportId
INNER JOIN agents a
ON f.agent = a.id
ORDER BY f.outboundlegid, f.inboundlegid, f.agent, querydatetime DESC
Run Code Online (Sandbox Code Playgroud)

它出什么问题了?或如何优化它?它给我

以这个比例查询耗尽的资源

我有一个航班表,我想查询特定国家/地区内的航班

Rob*_*rto 11

自雅典娜成立以来,我一直在面对这个问题,问题在于ORDER BY条款。Athena只是安装了hive和prestodb的EMR集群。您面临的问题是:即使查询分布在X个节点上,排序阶段也必须仅由一个节点(在这种情况下为主节点)完成。因此,最后,您可以订购与主节点内存一样多的数据。

您可以通过减少查询返回的数据量(可能会缩短时间范围)来进行测试。我希望这有帮助 :)

  • 。。排序不必*必须由单个节点完成*。唉,这就是许多并行数据库实现排序的方式。SQL 中的并行排序已经存在了几十年。令我沮丧的是,更现代的系统不使用它们。 (4认同)
  • Presto 分布式排序已经有一段时间了。Athena 是基于一个相当老的 Presto 版本。 (4认同)
  • 好吧,我并不是说这很好,这太神奇了,这就是它在世界其他地方的工作方式。我是说雅典娜的运作方式。我知道这是因为由于我在Athena的经验,所以被告知这是订购的问题。由你们决定是否相信... (2认同)
  • 看起来确实是 order by 导致了问题......当我删除 order by 时,它运行:15 分 53 秒,扫描数据:2.71 GB。我注意到它只有 2.71GB 的数据,为什么 athena 无法处理这么少的数据? (2认同)
  • 根据我的经验,如果桌子很宽,问题通常会变得更糟。数据集可能非常小,但如果有 30 列左右,排序通常是不可能的。 (2认同)