大火花分区尺寸的缺点
我读到过，太多的小分区会因为开销而损害性能，例如，向执行器发送大量任务。
使用最大的分区的缺点是什么？例如，为什么我会看到100s的MB范围内的建议？
- 如果丢失了一个分区，则需要进行大量的重新计算。对于许多较小的分区，您可能会更经常地丢失分区，但在运行时中的差异会更小。
- 如果在大分区上执行的少数任务中有一个任务的计算时间比其他任务长，这将使其他核心未被利用，但使用较小的分区，可以更好地在集群中分配这些核心。
这些问题有意义吗？还有其他问题吗？谢了！
共有1个答案
这两个潜在的问题是正确的。
为了更好地使用集群，应该定义足够大的分区来计算一个HDFS块（一般为128/256 MB)，但要避免超过它，以便更好地分配，从而允许性能的水平伸缩（最大化CPU使用）。
-
我通过指定分区的数量从文本文件创建RDD（Spark 1.6）。但它给我的分区数与指定的分区数不同。 案例1 案例2 案例3 案例4 文件/home/pvikash/data/test的内容。txt是： 这是一个测试文件。将用于rdd分区 基于以上案例，我有几个问题。 对于案例2，显式指定的分区数为0，但实际分区数为1（即使默认最小分区为2），为什么实际分区数为1？ 对于案例3，为什么在指定数量的
-
谁能给我解释一下吗？ 然而，另一方面是，对于不能保证产生已知分区的转换，输出RDD将没有分区器集。例如，如果对哈希分区的键/值对RDD调用map（），则传递给map（）的函数在理论上可以更改每个元素的键，因此结果将不会有分区器。Spark不会分析函数以检查它们是否保留密钥。相反，它提供了另外两个操作，mapValues（）和flatMap Values（），它们保证每个元组的键保持不变。 Mate
-
我有一个spark工作，处理大量数据并将结果写入S3。在处理过程中，我可能有超过5000个分区。在写入S3之前，我想减少分区的数量，因为每个分区都是作为一个文件写入的。 在其他一些情况下，处理过程中可能只有50个分区。如果我想合并而不是因为性能原因重新分区，会发生什么。 从文档来看，它说只有当输出分区的数量少于输入时才应该使用coalesce，但是如果不是，它似乎不会导致错误吗？它会导致数据不正确
-
这个问题与这个主题有关： Spark 2.2 Scala 数据帧从字符串数组中选择，捕获错误 我需要区分缺少列的记录（这在我的用例中不是错误）和具有不适用于列类型的垃圾值的记录。 在执行selectExpr之后，这两种情况在结果数据帧中都显示为null。我正在寻找一种快速的方法，将缺少列的记录包含在好的结果中，同时将具有垃圾值的记录放入坏桶中。不好的可能包括像一个值为空字符串的int字段，或者“a
-
[新加入Spark]语言-Scala 根据文档，RangePartitioner对元素进行排序并将其划分为块，然后将块分发到不同的机器。下面的例子说明了它是如何工作的。 假设我们有一个数据框，有两列，一列（比如“a”）的连续值从1到1000。还有另一个数据帧具有相同的模式，但对应的列只有4个值30、250、500、900。（可以是任意值，从1到1000中随机选择） 如果我使用RangePartit
-
我很想知道相互独立的最大位图宽度和高度是多少。我确实发现最大尺寸是32768x32768，但这只是一个完美的正方形吗？32768x32768=1073741824是我可以玩的像素总数吗？我可以在宽度和高度之间重新排列这些像素，只要总数不超过？ 如果我这样做，我不会有任何错误： 将位图变暗为位图=新位图（450100000） 即使我无法在保存后打开图像（我不需要这样做），我仍然能够使用位图，但我相信