Question

我有一个约8 GB的数据集，具有约1000万行（约10列），并想证明SparkR可以胜过SQL。相反，与SQL相比，我发现SparkR的性能非常差。

我的代码只是简单地从S3加载文件，运行时间隙很大，我的分组通常由1-15行组成-因此，1000万行除以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。

事实并非如此。来宾语言引起的间接开销：

内部Catalyst格式
外部Java类型
将数据发送到R
....
将数据发送回JVM
转换为Catalyst格式

很大。

此外，gapply基本上是按组分组的示例-我们在Spark中normally avoid进行了开发。

仅当无法使用标准SQL函数表示业务逻辑时，才应使用整体gapply。在正常情况下，这绝对不是一种优化代码的方法（在某些情况下可能会更快一些），但是通常，如果需要，任何特殊逻辑都可以从使用Scala UDF，UDAF，Aggregator或reduceGroups / mapGroups）。

与SQL

1 个答案: