amazon-s3 - 用于高效 Athena 查询的 S3 分区(文件大小)

Question

我有一个将每日记录加载到 S3 的管道。然后，我利用 AWS Glue Crawler 创建分区以促进 AWS Athena 查询。但是，与其他相比，有一个大的分区数据。

S3文件夹/文件显示如下:

s3.ObjectSummary(bucket_name='bucket', key='database/table/2019/00/00/2019-00-00.parquet.gzip')   7.8 MB

s3.ObjectSummary(bucket_name='bucket', key='database/table/2019/01/11/2019-01-11.parquet.gzip')  29.8 KB
s3.ObjectSummary(bucket_name='bucket', key='database/table/2019/01/12/2019-01-12.parquet.gzip')  28.5 KB
s3.ObjectSummary(bucket_name='bucket', key='database/table/2019/01/13/2019-01-13.parquet.gzip')  29.0 KB
s3.ObjectSummary(bucket_name='bucket', key='database/table/2019/01/14/2019-01-14.parquet.gzip')  43.3 KB
s3.ObjectSummary(bucket_name='bucket', key='database/table/2019/01/15/2019-01-15.parquet.gzip') 139.9 KB

每行末尾显示文件大小。请注意，2019-00-00.parquet.gzip 包含 2019-01-11 之前的所有记录，因此它的大小很大。我读过this它说“如果您的数据严重偏向一个分区值，并且大多数查询都使用该值，那么开销可能会抵消最初的好处。”

所以，我想知道我是否应该将 2019-00-00.parquet.gzip 拆分成具有不同分区的较小的 parquet 文件。例如，

key='database/table/2019/00/00/2019-00-01.parquet.gzip',
key='database/table/2019/00/00/2019-00-02.parquet.gzip',
key='database/table/2019/00/00/2019-00-03.parquet.gzip', ......

但是，我认为这种分区不是很有用，因为它不能反射(reflect)旧记录的存储时间。我对所有解决方法都持开放态度。谢谢。

Answer 1

如果您的数据总大小小于几千兆字节，则根本不需要对表进行分区。对小数据集进行分区对性能的损害远大于其帮助。将所有文件放在同一目录中，未分区表中的深层目录结构也会影响性能。

对于小型数据集，只要文件不太多(尽量保持在一百以下)，最好不要分区。如果您出于某种原因必须拥有大量小文件，您可能会从分区中获益，但在这种情况下对其进行基准测试。

当数据量较小时(如您的情况)，在 S3 上查找、打开和读取文件的开销将高于实际处理它们的开销。

如果您的数据增长到数百兆字节，您可以开始考虑分区，并着眼于一种分区方案，其中分区的大小约为一百兆字节到一千兆字节。如果您的数据有时间成分(您的情况似乎有)，那么时间是最好的分区依据。首先查看使用年份作为分区键，然后是月份，依此类推。当然，具体如何对数据进行分区取决于查询模式。