Question

我通过Spark读取的数据是高度偏斜的Hive表，具有以下统计信息。

（MIN，25TH，MEDIAN，75TH，MAX） ：

1506.0 B / 0 232.4 KB / 27288 247.3 KB / 29025 371.0 KB / 42669 269.0 MB / 27197137

我相信当我执行一些Window Funcs和Pivots时，这会在工作中引起下游问题。

我尝试探索此参数以限制分区大小，但是没有任何变化，并且分区在读取时仍然偏斜。

spark.conf.set("spark.sql.files.maxPartitionBytes")

此外，当我使用Hive表作为源缓存此DF时，它需要花费几分钟，甚至很可能也是由于偏斜而导致Spark UI中出现一些GC。

此spark.sql.files.maxPartitionBytes是否适用于Hive表或仅适用于文件？

处理偏斜的Hive源的最佳方法是什么？

像是写障碍物到镶木地板或Salting的东西是否适合此问题？

我想避免在阅读时.repartition()，因为它会为已经有数据的过山车增加另一层。

谢谢

================================================ ===

经过进一步研究，似乎Window Function也在引起数据偏斜，这就是Spark Job挂起的地方。

我正在通过双time series执行一些Window Function填充（向前填充，然后向后填充以填充所有null传感器读数），并尝试按照本文尝试进行{{1 }}方法均匀分布...但是下面的代码生成所有salt值，因此null方法不起作用。

不确定我为什么要在salt之后得到skews，因为通过Window检查后，我要划分的每个度量项都具有大致相同的记录量，因此为什么{需要{1}}吗？

.groupBy()

盐站=> https://medium.com/appsflyer/salting-your-spark-to-scale-e6f1c87dd18

salt

Answer 1

Hive based solution :

您可以使用配置单元配置启用偏斜联接优化。适用的设置是：

set hive.optimize.skewjoin=true;
set hive.skewjoin.key=500000;
set hive.skewjoin.mapjoin.map.tasks=10000;
set hive.skewjoin.mapjoin.min.split=33554432;

请参阅有关数据砖的提示：

偏斜hints在这种情况下可能有效

Answer 2

在单个分区足够大而无法容纳在单个执行程序的内存中的情况下，盐分可能会有所帮助。即使所有密钥也均等分布（可能会发生这种情况），也会发生这种情况。

您必须在用于创建Window的partitionBy子句中包含salt列。

window = Window.partitionBy('measure', 'salt')\
               .orderBy('measure', 'date')\
               .rowsBetween(Window.unboundedPreceding, 0)

同样，您必须创建另一个窗口，该窗口将对中间结果进行操作

window1 = Window.partitionBy('measure')\
                   .orderBy('measure', 'date')\
                   .rowsBetween(Window.unboundedPreceding, 0)

倾斜的窗口功能和配置单元源分区？

2 个答案: