Question

我有一个这样的数据框：

df = spark.createDataFrame([(0, ["B","C","D","E"]),(1,["E","A","C"]),(2, ["F","A","E","B"]),(3,["E","G","A"]),(4,["A","C","E","B","D"])], ["id","items"])

它将创建一个数据帧df，如下所示：

+---+-----------------+
|  0|     [B, C, D, E]|
|  1|        [E, A, C]|
|  2|     [F, A, E, B]|
|  3|        [E, G, A]|
|  4|  [A, C, E, B, D]|
+---+-----------------+

我想得到这样的结果：

+---+-----+
|all|count|
+---+-----+
|  F|    1|
|  E|    5|
|  B|    3|
|  D|    2|
|  C|    3|
|  A|    4|
|  G|    1|
+---+-----+

从本质上说，这只是在df["items"]中找到所有不同的元素，并对它们的出现次数进行计数。如果我的数据的大小更易于管理，则可以这样做：

all_items = df.select(explode("items").alias("all")) 
result = all_items.groupby(all_items.all).count().distinct() 
result.show()

但是因为我的数据在每个列表中都有数百万行和数千个元素，所以这不是一种选择。我当时想逐行执行此操作，因此一次只能处理2个列表。因为大多数元素经常在许多行中重复（但是每行中的列表是一个集合），所以这种方法应该可以解决我的问题。但是问题是，我真的不知道如何在Spark中执行此操作，因为我才刚刚开始学习它。有人可以帮忙吗？

Answer 1

观察：

explode不会更改管道中的数据总量。宽（array）和长（exploded）格式所需的空间总量是相同的。此外，后者在Spark中的分布更好，它比长短数据更适合长短数据。所以

df.select(explode("items").alias("item")).groupBy("item").count()

是必经之路。

但是，如果您真的想避免这种情况（无论出于何种原因），可以使用RDD和aggregate。

from collections import Counter

df.rdd.aggregate(
  Counter(), 
  lambda acc, row: acc + Counter(row.items),
  lambda acc1, acc2: acc1 + acc2
)
# Counter({'B': 3, 'C': 3, 'D': 2, 'E': 5, 'A': 4, 'F': 1, 'G': 1})

并非如此，与DataFrame explode不同的是，它将所有数据存储在内存中并且非常渴望。

Answer 2

您需要做的是减小进入爆炸状态的分区的大小。有2个选项可以执行此操作。首先，如果输入数据是可拆分的，则可以减小spark.sql.files.maxPartitionBytes的大小，以便Spark读取较小的拆分。另一种选择是在爆炸之前重新分区。

maxPartitionBytes的{{3}}为128MB，因此Spark将尝试以128MB的块读取数据。如果数据不可拆分，则它将整个文件读入单个分区，在这种情况下，您需要执行repartition。

在您的情况下，由于您正在爆炸，所以说它增加了100倍，每个分区有128MB的空间进入，最终每个分区有12GB +的空间！

您可能需要考虑的另一件事是您的shuffle分区，因为您正在进行聚合。同样，在爆炸之后，您可能需要通过将spark.sql.shuffle.partitions设置为比默认值200高的值来增加聚合的分区。您可以使用Spark UI查看随机播放阶段，并查看每个数据有多少任务正在读取并进行相应调整。

我在刚刚在欧洲Spark Summit上提供的default value中讨论了此建议以及其他调优建议。

python spark替代方法可针对非常大的数据爆炸

2 个答案: