关于spark分区

我想重点介绍数据处理不同层上的Spark分区的主题。

在物理级别上，，分为三个阶段。 它们是input，shuffle和output。

例如，在input和output处，您可以控制分区的大小，但是在output处，我也可以通过合并或重新分区来控制文件数或任务数。 使用shuffle，您可以控制将在网络中移动的数据数量。

在输入阶段进行分区

首先，根据输入数据集的大小确定分区数。

Spark可以很好地处理输入。在如何将数据放置在HDFS或Cassandra等数据存储中以及Spark在读取时如何拆分数据之间存在明确的匹配。

让我们想象一下，输入数据集的大小约为HDFS上未压缩文本文件的30 GB（约30000 MB），该文件正在10个节点上分发。

当Spark从HDFS读取文件时，它将为单个输入拆分创建一个分区。输入拆分由用于读取此文件的Hadoop设置。如果您在HDFS上存储了30GB的未压缩文本文件，则使用默认的HDFS块大小设置（128MB）和默认（128MB），它将存储在240个块中，这意味着您从该文件读取的数据帧将具有240个分区.InputFormatspark.files.maxPartitionBytes,这等于Spark默认的分区数spark.default.parallelism

如果您的数据无法拆分，Spark将使用默认数量的分区。作业启动时，分区数等于所有执行程序节点上的内核总数。

shuffle分区

任何Spark管道中最痛苦的地方是wide transformation，需要来自其他分区的信息并触发shuffle。不幸的是，您无论如何都无法摆脱这种转变，但是您可以减少shuffle对性能的影响。

shuffle分区是在数据混洗中用于wide transformation的分区。但是，对于wide transformation，shuffle分区的数量设置为200。无论您的数据是大还是小，或者如果集群配置中有20个执行程序，它仍然是200，都是如此。是的，是的，这就是我们看到的在分区部分，那是神秘的数字。

因此，控制由shuffle导致的并行性的参数是一个称为参数的参数。默认值为200的原因是来自真实经验，这是一个非常好的默认值。但实际上，该值通常总是不好的。spark.sql.shuffle.partitions

当处理少量数据时，通常应减少shuffle分区的数量，否则最终将导致许多分区，每个分区中的条目数量很少，这会导致所有执行程序的利用率不足，并增加了数据处理时间。通过网络从执行者转移到执行者。

另一方面，当您有太多的数据和分区太少时，这会导致执行器中要处理的任务减少，但会增加每个执行器的负担，并经常导致内存错误。 另外，如果将分区的大小增加到大于执行程序中可用内存的大小，则会导致磁盘溢出。 溢出是您可能能够做的最慢的事情。 从本质上讲，在磁盘溢出期间，如果Spark操作无法将其部分RAM放入磁盘中，则Spark作业可以在任何大小的数据上正常运行。 尽管它不会破坏您的管道，但由于磁盘I / O的额外开销和垃圾收集的增加，它也使效率极低。

因此，当使用Spark.spark.sql.shuffle.partitions时，它是配置最频繁的参数之一

output分区

保存在适当的选择条件的数据可以显著加快在未来处理流水线所需的数据的读出和检索。

首先，在某些情况下，可以在发现DataSource的分区之后使用分区修剪，这会限制Spark在查询时读取的文件和分区的数量。在某些情况下（例如AWS s3），它甚至避免了不必要的分区发现。 Spark 3.0中的动态分区修剪的概念也很有价值。但是有时候，这些优化可能会使情况变得更糟，例如对文件系统进行递归扫描以获取元数据以了解初始查询的分区可能需要很长时间（如果分区数量很多）。同样，所有表元数据必须具体化到驱动程序进程的内存中，并且可能显着增加其内存负担。

其次，将DataFrame保存到磁盘时，请特别注意分区大小。在写入期间，Spark将为每个任务生成一个文件（即每个分区一个文件），并且在读取时将读取任务中的至少一个文件。这里的问题是，如果保存DataFrame的集群设置具有大的的内存，因此可以毫无问题地处理大型分区，而较小的集群可能会在读取保存的DataFrame时遇到问题。

例如，您有一个大型集群和一个较小的(更具成本效益的服务集群)。在这种情况下，解决方案将是在写入之前将DataFrame重新分区为更多分区，以使下一个集群不会阻塞。

结论

如果你想增加分区数,用repartition().
如果你想减少分区数,用coalesce(),可以尽量避免shuffle

引用
https://luminousmen.com/post/spark-partitions