我有一个将日常记录加载到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之前的所有记录，因此其大小较大。我读过这篇文章，它说"如果你的数据严重偏向一个分区值，而大多数查询都使用这个值，那么开销可能会抵消最初的好处。">
所以，我想知道是否应该将2019-00-00.parquet.gzip拆分为具有不同分区的较小的镶木文件。例如，
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', ......
然而，我认为这种分区并没有那么有用，因为它不能反映旧记录是何时存储的。我对所有变通办法都持开放态度。非常感谢。
如果数据的总大小小于几GB，则根本不需要对表进行分区。对小数据集进行分区对性能的伤害远大于帮助。将所有文件都放在同一目录中，未分区表中的深层目录结构也会影响性能。
对于小型数据集，只要没有太多文件(尽量保持在100个以下)，不分区会更好。如果出于某种原因必须有很多小文件，那么分区可能会带来好处，但在这种情况下要进行基准测试。
当数据的大小很小时，比如在您的情况下，在S3上查找文件、打开文件和读取文件的开销将高于实际处理它们的开销。
如果您的数据增长到数百兆字节，您可以开始考虑分区，并以分区大小约为100兆字节到1千兆字节的分区方案为目标。如果你的数据中有时间成分，在你的情况下似乎也有，那么时间是最好的分区方式。首先考虑使用年作为分区键，然后使用月，以此类推。当然，如何对数据进行分区取决于查询模式。