考虑到hive和spark的bucketing是完全不同的（都使用不同的bucketing算法，生成的结果文件是不同的（在hive中，buckets的数量=文件的数量，但在spark中不是这样等等），大多数指南都是关于hive而不是spark的，如何确定spark将要处理的表的正确桶数。有几个问题：
一些准则指出，应该根据表的大小计算桶的数量。但是，如果一个表本质上是事务性的，其大小会随着时间的推移而增长，那么如何创建bucket的数量呢？
人们可以通过合并或重新分区来控制输出文件的数量（在hdfs或s3中），因为spark的性能在很大程度上受此影响（少数大文件（至少大于块大小）比许多小文件要好得多）。因此，如果我输出例如每个分区10个文件，并将bucket的数量定义为更高的值（例如100），这是否是正确的方法，它是否会提供预期的bucketing好处？
还建议spark.sql.shuffle.partitions的数量应该等于bucket的数量。是真的吗？
关于桶数的综合视图将非常有用。
1条答案
按热度按时间bpsygsoo1#
一些准则指出，应该根据表的大小计算桶的数量。但是，如果一个表本质上是事务性的，其大小会随着时间的推移而增长，那么如何创建bucket的数量呢？
可能你想分区数据。一般的方法是通过创建日期列。或哈希桶方式（通过主键计算）
在分区内，u将有碎片Parquet文件，这是spark不使用执行器的一个因素
人们可以通过合并或重新分区来控制输出文件的数量（在hdfs或s3中），因为spark的性能在很大程度上受此影响（少数大文件（至少大于块大小）比许多小文件要好得多）。因此，如果我输出例如每个分区10个文件，并将bucket的数量定义为更高的值（例如100），这是否是正确的方法，它是否会提供预期的bucketing好处？
重新划分：通常你不需要这样做。我能想到的唯一一个用例是：雅典娜不能消化一个大行的Parquet文件（当一个Parquet文件中的行超过2米时，我们已经看到了问题）；只有在这种情况下，你想重新划分
colase：如果输出的parquet文件太零碎，那么下游的athena查询/redshift spectrum查询会变得很慢——在这种情况下，您需要执行coalesce以提高读取性能