YARN在群组中死亡的火花容器由

我有一个从Hbase中提取的数据集，这是一个长表格的宽表格，即有rowKey,columnQualifier和value列。为了获得一种关键的形式，我需要将rowKey（它是一个字符串UUID）分组到一个集合中，并将一个对象从集合中取出。问题在于，我设法执行的只是组中的元素数量;其他分组由于内存溢出超出YARN容器限制而导致容器被杀。我在内存大小方面做了很多实验，包括开销，分区和不分区等。我甚至进入了大量的分区，即大约10 000个分区，但是这个工作同样死去。我试了DataFrame groupBy和collect_list，以及数据集grouByKey和mapGroups。YARN在群组中死亡的火花容器由

该代码适用于小数据集，但不适用于较大的数据集。该数据集在Parquet文件中大约为500 GB。数据不会因为只有50个元素而成为群组中最大的群体。因此，据我所知，分区应该很容易适应内存，因为每个rowKey的聚合数据并不是很大。数据键和值主要是字符串，并且时间不长。

我正在使用Spark 2.0.2;上面的计算都是Scala。

来源

2017-02-15 Jakub Nowacki

你增加了executors的内存吗？如果是这样，多少？ –

是的，正如我所说，我做了很多实验，包括执行程序的内存和开销，执行程序和内核的数量，分区等等。问题也没有扭曲，这是分组情况下的常见怀疑。 –

你试过'reduceByKey'吗？ –

您可能会遇到可怕的groupByKey洗牌。请阅读关于avoiding groupByKey的Databricks文章，其中详细说明了这两个函数之间的根本区别。

如果你不想读文章做，短故事是这样的：虽然groupByKey和reduceByKey产生相同的结果，groupByKey实例的所有数据的洗牌，而reduceByKey试图通过降低第一减少数据交叉。有点像MapReduce Combiners，如果你熟悉这个概念。

来源

2017-02-19 18:56:55 JamCon

感谢您的建议，但我知道这篇文章以及它的工作原理。在这种情况下，问题是相当有限的，因此，我认为这个“groupBy”不应该那么昂贵。我还没有尝试'reduceByKey'，我会放弃它。尽管如此，如果出现我的问题，我必须使用Map [String，Any]或者使用反射来将单个值打包到一个大对象中，并创建一个sum的概念。有趣的是，同样使用DataFrame函数'collect_list'，这应该是最优的，并且可能避免'groupByKey'引发相同的错误。 –

我已经使用'reduceByKey'方法重建了作业，尽管事实上我连接了地图，但它更加优化。它可以在'Dataset'中使用操作'groupByKey'和'reduceGroups'或'mapGroups'来完成，但它并不是最优的：参见[this post]（http://stackoverflow.com/questions/38383207/rolling-your -own-reducebyke功能于火花数据集） –

YARN在群组中死亡的火花容器由

回答

相关问题