Athena 在某些查询中忽略 LIMIT

Athena ignore LIMIT in some queries

我有一个 table 有很多分区(我们正在努力减少)

当我查询时:

SELECT * FROM mytable LIMIT 10

我得到:

"HIVE_EXCEEDED_PARTITION_LIMIT: Query over table 'mytable' can potentially read more than 1000000 partitions"

为什么查询的“LIMIT 10”部分不足以让 Athena return 在不读取超过 1 或 3 个分区的情况下得到结果?

回答: 在查询计划阶段,Athena 会尝试列出回答查询可能需要的所有分区。 由于 Athena 不知道哪些分区实际包含数据(不是空分区),它会将所有分区添加到列表中。

如果我没记错的话,Limit 仅适用于显示操作。所以查询仍然会读取所有内容,但只显示 10 条记录。 尝试使用 where 条件限制数据,应该可以解决问题

我认为 Athena 的工作人员尝试读取最大数量的分区(相对于 table 的分区大小)以获取随机数据块并在查询完成时停止(在您的情况下,是极限的规格)。

在你的情况下,由于涉及的分区太多,它甚至没有开始执行上述过程。因此,如果 Athena 没有计划您的随机数据选择查询,您必须明确计划并交给执行引擎。

类似于:

select * from mytable 
where (
   partition_column in (
      select partition_column from mytable limit cast(10 * rand() as integer)
   )
)
limit 100

A​​thena 计划一个查询然后执行它。在计划期间,它会列出分区和这些分区中的所有文件。但是,它对文件、它们包含多少条记录等一无所知

当您说 LIMIT 10 时,您是在告诉 Athena 您希望结果中最多有 10 条记录,并且由于您没有任何分组或排序,所以您需要 10 条任意记录。

但是,在计划阶段,Athena 无法知道哪些分区中有文件,以及需要读取多少文件才能找到 10 条记录。如果不列出分区位置,它就不知道它们不全是空的,如果不读取文件,它就不知道它们也不全是空的。

因此 Athena 首先必须获取分区列表,然后列出每个分区在 S3 上的位置,即使您说您只想要 10 个任意记录。

在这种情况下,由于分区太多,Athena 短路并表示您可能不是要 运行 这种查询。如果 table 的分区较少,Athena 将执行查询,每个工作人员将尽可能少地读取到 return 10 条记录,然后停止——但每个工作人员将产生 10 条记录,因为工作人员不能假设其他工作人员会 return 任何记录。最后coordinator会从所有worker的所有结果中挑出10条记录到return作为最终结果。