Athena 在太多 S3 文件上的性能答案

【问题标题】：Athena performance on too many S3 filesAthena 在太多 S3 文件上的性能
【发布时间】：2019-12-22 07:11:30
【问题描述】：

我计划将数据存储到 S3 中，稍后将在 S3 上执行 SQL 查询。 S3 文件基本上包含 json 记录。我将通过触发 AWS Lambda 执行的 DynamoDB 流获取这些记录，因此很难在该层处理重复，因为 AWS Lambda 保证 atleast once delivery。为了避免处理查询中的重复记录，我想确保以唯一的方式插入记录。

据我所知，实现唯一性的唯一方法是拥有唯一的 S3 密钥。如果我选择这种方法，我将结束每天创建数百万个 S3 文件。每个文件由单个 json 记录组成。

在执行 Athena 查询时创建这么多文件是否会成为一个问题？任何替代方法？

【问题讨论】：

每个流记录都分配了一个序列号。你能用这个持久化在第二个 DynamoDB 表中来实现检查点吗？
嗯...我想在这种情况下我将不得不引入某种事务行为。例如如果写入 s3 成功，则写入另一个 dynamodb 表。如果写入 dynamoDb 表失败，删除 S3 文件？似乎有点不必要的开销。
我同意幂等解决方案更可取，但我没有关于 Athena 查询性能的数据可以分享更多的小文件与更少的大文件。当然，这听起来很容易测试。
是的，它确实会影响查询的性能。例如，如果您有一个包含 100 万条记录的 100 MB 文件，那么 Athena 必须将其列出、打开、读取和关闭一次。考虑以下场景您有 100 万个文件，每个文件都有记录，然后 Athena 必须列出所有文件，打开、读取、关闭数百万次，这会极大地影响查询性能。因此理想的文件大小应该在 128 MB 左右。

标签： amazon-web-services amazon-s3 aws-lambda amazon-athena amazon-dynamodb-streams

【解决方案1】：

我认为您最好在 Athena 本身中处理重复数据删除。对于 Athena 来说，清除一些重复项将是一件容易的事。设置按唯一属性分组的视图，并为非唯一属性使用 ARBITRARY 或 MAX_BY（如果您要订购最新的东西），并针对此视图运行查询以不必担心每个单独查询中的重复数据删除。

您还可以使用 CTAS 运行每日或每周重复数据删除作业，具体取决于数据的新鲜程度（您还可以将预先删除重复数据的历史数据与动态合并的复杂混合数据 -去重数据）。

运行查询时，Athena 会列出 S3 上的对象，这不是可并行化的操作（分区表除外，它可与分区的粒度并行化），并且 S3 的列表限制为 1000 页大小。您真的不想让 Athena 查询超过 1000 个文件的表（或分区）。

【讨论】：

如果我有很多记录（以百万计），使用MAX 不会显着减慢查询速度吗？
不，不显着。这将比拥有数百万个文件快许多数量级。当然，完全不必进行重复数据删除会更快，但我认为 Athena 的延迟并不低，我认为您不会注意到其中的差异。如果它开始成为一个问题，您应该像我的回答一样运行定期重复数据删除作业。

【解决方案2】：

通过 Kinesis Firehose 写入 S3，然后通过 Athena 进行查询。 Firehose 会将您的记录分组到数量相对较少的文件中，这样通过 Athena 查询它们就会很有效。实际上，它甚至会将它们组织到一个文件夹结构中，该文件夹结构通过写入时间戳很好地分区。

【讨论】：