我有两个Spark工作一个是预处理和第二个是过程。流程作业需要为数据中的每个用户计算。我想避免像groupby那样的洗牌，所以我考虑在parquet中将预处理的结果保存为bucket by user，或者按用户重新划分并保存结果。你更喜欢什么？为什么
pobjuy321#
选择 partitionBy 以及 bucketBy 可减少以确定数据基数：低基数->分区高位基数->桶但是，两者都不用于聚合。有用于 predicate 下推，没有更多。因此，当您的目标是避免像groupby那样的无序处理时，它们不会有多大用处，尽管在将来新api可能会改变这种情况。
partitionBy
bucketBy
t9eec4r02#
请读两到三遍来理解这一点。在我的建议中，您应该使用重新分区，因为partitionby有很多混乱。因为它将在hdfs中创建包含所有分区键的文件夹，而且它将数据添加到不同的文件中，这是一个非常昂贵的过程。另外，bucketby属性添加相同的文件，但在文件夹中按其上一个分区的顺序创建文件。另一方面，重新分区将创建存储在文件中的所有数据的哈希表，该哈希表按此处提到的键排序。而数据洗牌只是为了匹配你在重分区属性中提到的文件数量，它更便宜，速度也更快。另外，如果您想对该数据进行分组，则运行时间将与partitionby相同。通过重新分区，您只需减少预处理的运行时间。
2条答案
按热度按时间pobjuy321#
选择
partitionBy以及bucketBy可减少以确定数据基数：低基数->分区
高位基数->桶
但是，两者都不用于聚合。有用于 predicate 下推，没有更多。因此，当您的目标是避免像groupby那样的无序处理时，它们不会有多大用处，尽管在将来新api可能会改变这种情况。
t9eec4r02#
请读两到三遍来理解这一点。
在我的建议中，您应该使用重新分区，因为partitionby有很多混乱。因为它将在hdfs中创建包含所有分区键的文件夹，而且它将数据添加到不同的文件中，这是一个非常昂贵的过程。另外，bucketby属性添加相同的文件，但在文件夹中按其上一个分区的顺序创建文件。
另一方面，重新分区将创建存储在文件中的所有数据的哈希表，该哈希表按此处提到的键排序。而数据洗牌只是为了匹配你在重分区属性中提到的文件数量，它更便宜，速度也更快。另外，如果您想对该数据进行分组，则运行时间将与partitionby相同。通过重新分区，您只需减少预处理的运行时间。