AWS Glue/Athena：如果在查询中不使用分区，它们是否有助于查询性能？

Question

我们有一个用例如下：

s3://bucket/projectx/deviceid/tbl_message/tripid/xyz.parquet

然后，我们使用 AWS Athena 和 Athena Grafana 插件来实现数据的仪表板可视化。总体来说效果很好。
不幸的是，新的行程不会自动添加到此设置中，因为 Athena 无法看到新的分区。这样做的缺点是，刷新仪表板的用户可以看到单次行程中的新数据，但看不到新的行程信息。

有几种方法可以解决这个问题：

AWS Glue 可以设置为运行爬虫程序，例如每 1 小时一次以部分解决此问题。但对于这个用例来说，它的成本过高。
Lambda 函数可以与 Athena 集成，在处理每个日志文件时运行
```
MSCK REPAIR TABLE tbl_message
```
- 但这会增加 Lambda 和 Athena 之间相当烦人的交叉依赖，我们希望避免这种情况。
Grafana 中的查询可以运行与 2) 中相同的命令 - 但这会产生奇怪的行为，用户加载仪表板最初不会看到新的行程 - 但如果他稍后点击刷新，那么行程就会出现。

以上解决方案都不是理想的。因此，我们考虑更改写入的 S3 路径，如下所示：

s3://bucket/projectx/deviceid/tbl_message/tripid_xyz.parquet

这意味着新行程的数据确实会自动显示，因为我们消除了数据分区。这似乎是最干净、最简单的解决方案 - 但这也意味着 S3 上的单个

tbl_message

文件夹中可以有几 GB 的数据。

请注意，无论如何设置，我们都不会在任何 Athena 查询中显式使用

tripid

分区层，因为我们的用户将纯粹根据时间而不是行程进行查询。

因此我们的问题是：

在我们的 Athena 查询不利用

tripid

分区层的情况下，按照建议删除它是否有任何真正的缺点（性能方面） - 或者实际上会是相同的吗？

Answer 1

您应该继续使用分区来减少数据扫描。

Partition projection

可以帮助您动态识别新分区。

分区投影的缺点：

关于第二个问题，你可以这样做，如果你的TRIPID随着时间的推移而增长，你可以设置分区范围来减少动态分区计算时间