Spark 独立：SparklyR：性能问题

Question

我正在尝试在我的 Spark 服务器上运行来自 SparklyR 库的机器学习算法。

• 1 个集群
• 8 核
• 24G 内存
• Ubuntu 16.04
• Spark 2.2
• 独立配置
• 1 Master/2 Workers
• 每个执行器的内存：4G
• 8 核/工作器
• 4096 Worker 内存

在实践中，我在一个非常小的数据集 (72 x 100) 上测试 ml_decision_tree。 我首先从 R (read.csv) 中的 CSV 文件在本地读取我的原始数据集 (72 x 7350)，执行整形，然后在 Spark 中加载结果 (df_fin)（我直接在 Spark 所在的集群上运行代码已安装）：

df_tbl <- sdf_copy_to(sc,df_fin)

我可以在服务器 UI 中看到我新创建的 RDD；它的“内存大小”为 49.9 KB，“磁盘大小”为空。关于堆内存使用情况，我可以看到：49.9 KB（剩余 2004.6 MB）。

然后，我的应用程序卡在运行 ml_decision_tree。 我的控制台中没有错误消息，我的应用程序状态为“正在运行”，并且以下内容仍写入我的工作日志中：

17/08/23 15:35:32 INFO ShuffleBlockFetcherIterator: Getting 0 non-empty blocks out of 200 blocks
17/08/23 15:35:32 INFO ShuffleBlockFetcherIterator: Started 0 remote fetches in 0 ms
17/08/23 15:35:32 INFO ShuffleBlockFetcherIterator: Getting 26 non-empty blocks out of 200 blocks
17/08/23 15:35:32 INFO ShuffleBlockFetcherIterator: Started 1 remote fetches in 1 ms
17/08/23 15:35:32 INFO Executor: Finished task 1.0 in stage 494.0 (TID 39532). 3082 bytes result sent to driver
17/08/23 15:35:32 INFO Executor: Finished task 0.0 in stage 494.0 (TID 39531). 4073 bytes result sent to driver ...

然后 35 分钟后，在控制台：“*没有行被 'na.omit' 调用丢弃” 意味着事情正在向前发展..

所以它仍然在做一些事情，但我不明白是什么。当我在自己的计算机上的 RShiny 中本地运行相同的代码时，过程完成得非常快（3 或 4 分钟）。最后，我的过程在 +/- 50 分钟后结束，出现以下错误：

错误：java.lang.OutOfMemoryError：超出 GC 开销限制

我猜这个 Java 错误来自垃圾收集器，它使用了我的大部分 CPU 资源，没有可用的大量内存......但它来自哪里？

我想我在对 Spark 的理解中遗漏了一些东西；通常 Spark 应该加快进程，但在我的情况下是最糟糕的。我无法以这种方式处理庞大的数据集。

另外，我想在 Spark 中加载我的原始数据帧 (72 x 7350) 以对其执行机器学习（当我的缓慢问题确实会得到解决时......）。

最好的方法是什么？使用 spark_read_csv 吗？我不使用 HDFS。我认为我没有足够的数据来利用 Hadoop 功能（一些 Tb，而不是更多）。

当我尝试加载原始数据框时，我收到了这个错误：

原因：org.codehaus.janino.JaninoRuntimeException：类 org.apache.spark.sql.catalyst.expressions.GeneratedClass$SpecificUnsafeProjection 的常量池已超过 JVM 限制 0xFFFF

我在 SPARK-18016 上看到 JIRA 比

“我们解决了大量（例如 4000）列的问题。但是，我们知道我们还没有解决大量（例如 12000）列的问题。”

我真的不明白。 Spark 是为大数据设计的，为什么它会因（在我的情况下）7350 colmuns 而失败？

有人可以指导我解决这个问题吗？它来自我的设置吗？我应该添加更多工人吗？

非常感谢！

Answer 1

我真的不明白。 Spark 是为大数据设计的，为什么它会因（在我的情况下）7350 colmuns 而失败？

并非所有“大数据”都是平等的，并且根据数据的形状（宽、长、两者）做出不同的设计选择。大多数时候，系统专注于长而细的数据集。 Spark 就是这种情况。

这里的问题不是数据量而是优化器的复杂性。在 Spark ML 中，这不是什么大问题，因为 Spark 使用 Vector 类型来组合功能，如果这还不够，总是可以使用低级 API。 sparklyr 然而，不幸地决定扩展转换后的功能 - 这是无法正常工作的东西。

72 x 7350

对这样的数据使用 Spark 是没有意义的。如果你能跑：

df_tbl <- sdf_copy_to(sc,df_fin)

表示数据适合内存，不需要分布式处理。