与SQL相比，sparkR运行缓慢。

Question

我的数据集为~8GB，有大约1000万行(大约10列)，并希望证明SparkR的性能优于SQL。相反，我认为与SQL相比，SparkR的性能非常差。

我的代码只是从运行的S3加载文件，其中我的分组通常由1-15行组成--所以1千万行除以15行就会产生很多组。我是否强制进行过多的洗牌、序列化/反序列化？这就是为什么事情进展这么慢吗？

为了说明我的build_transition函数不是性能瓶颈，我创建了一个名为build_transition2的简单版本，如下所示，它返回虚拟信息，每个组的执行时间应该是常量。

我的溶液配方有什么基本的或明显的吗？

build_transition2 <- function(key, x) {

  patient_id <- integer()
  seq_val <- integer()

  patient_id <- append(patient_id, as.integer(1234))
  seq_val <- append(seq_val, as.integer(5678))

  y <- data.frame(patient_id, 
                  seq_val,
                  stringsAsFactors = FALSE
                  )
}


dat_spark <- read.df("s3n://my-awss3/data/myfile.csv", "csv", header = "true", inferSchema = "true", na.strings = "NA")


schema <- structType(structField("patient_ID","integer"),
                     structField("sequence","integer")
                     )


result <- gapply(dat_spark, "patient_encrypted_id", build_transition2, schema)

Answer 1

并希望证明SparkR可以优于SQL的观点。

但事实并非如此。由客人语言引起的间接间接的开销：

• 内部催化剂格式
• 外部Java类型
• 向R发送数据
• ……
• 将数据发送回JVM
• 转换为催化剂格式

是巨大的。

在此基础上，gapply基本上是一个按键分组的例子--这是我们通常避免在星火中的一个例子。

如果业务逻辑不能使用标准的gapply函数表示，则应该使用总体的SQL。这绝对不是一种在正常情况下优化代码的方法(在某些情况下，代码可能会更快一些，但通常，任何特殊的逻辑(如果需要的话)都将更多地受益于使用Scala、联合新议程、聚合器或reduceGroups /mapGroups执行本地JVM )。