如何知道哪个计数查询最快？

Question

我一直在探索最近版本的 Spark SQL 2.3.0-SNAPSHOT 中的查询优化，并注意到语义相同查询的不同物理计划。

假设我必须计算以下数据集中的行数：

val q = spark.range(1)

我可以按如下方式计算行数：

1. q.count
2. q.collect.size
3. q.rdd.count
4. q.queryExecution.toRdd.count

我最初的想法是，它几乎是一个恒定的操作（肯定是由于本地数据集），以某种方式已被 Spark SQL 优化并立即给出结果，尤其是。第一个 Spark SQL 完全控制查询执行。

看过查询的物理计划后，我相信最有效的查询将是最后一个：

q.queryExecution.toRdd.count

原因是：

1. 它避免了从 InternalRow 二进制格式反序列化行
2. 查询是代码生成的
3. 只有一个工作有一个阶段

物理计划就是这么简单。

我的推理正确吗？如果是这样，如果我从外部数据源（例如文件、JDBC、Kafka）读取数据集，答案会有所不同吗？

主要问题是要考虑哪些因素来判断查询是否比其他查询更有效（根据此示例）？

---

完整性的其他执行计划。

q.count

q.collect.size

q.rdd.count

Answer 1

我对@9​​87654322@做了一些测试：

1. q.count：~50 毫秒
2. q.collect.size：大约一分钟后我停止了查询……
3. q.rdd.count: ~1100 毫秒
4. q.queryExecution.toRdd.count: ~600 毫秒

一些解释：

选项 1 是迄今为止最快的，因为它同时使用部分聚合和整个阶段代码生成。整个阶段的代码生成让 JVM 变得非常聪明并进行一些剧烈的优化（参见：https://databricks.com/blog/2017/02/16/processing-trillion-rows-per-second-single-machine-can-nested-loop-joins-fast.html）。

选项 2。速度很慢，将驱动程序上的所有内容都具体化，这通常是个坏主意。

选项 3。类似于选项 4，但是这首先将内部行转换为常规行，这非常昂贵。

选项 4. 与不生成整个阶段代码的速度差不多。

Answer 2

格式化的东西很糟糕，哦，好吧

/*note: I'm using spark 1.5.2 so some of these might be different than what you might find in a newer version
 *note: These were all done using a 25 node , 40 core/node and started with --num-executors 64 --executor-cores 1 --executor-memory 4g
 *note: the displayed values are the mean from 10 runs
 *note: the spark-shell was restarted every time I noticed any spikes intra-run
 *
 *million/billion = sc.parallelize(1  to 1000000).toDF("col1")
 *
 *val s0 = sc.parallelize(1  to 1000000000)
 *//had to use this to get around maxInt constraints for Seq
 *billion10 = sc.union(s0,s1,s2,s3,s4,s5,s6,s7,s8,s9).toDF("col1")
 *
 *for parquet files
 *compression=uncompressed
 *written with:    million/billion/billion10.write.parquet
 *read with:    sqlContext.read.parquet
 *
 *for text files
 *written with:    million/billion/billion10.map(x=> x.mkString(",")).saveAsTextFile
 *read with:    sc.textFile.toDF("col1")
 *
 *excluded the collect() because that would have murdered my machine
 *made them all dataframes for consistency
/*


size       type     query         
billion10  text     count              81.594582
                    queryExecution     81.949047
                    rdd.count         119.710021
           Seq      count              18.768544
                    queryExecution     14.257751
                    rdd.count          36.404834
           parquet  count              12.016753
                    queryExecution     24.305452
                    rdd.count          41.932466
billion    text     count              14.120583
                    queryExecution     14.346528
                    rdd.count          22.240026
           Seq      count               2.191781
                    queryExecution      1.655651
                    rdd.count           2.831840
           parquet  count               2.004464
                    queryExecution      5.010546
                    rdd.count           7.815010
million    text     count               0.975095
                    queryExecution      0.113718
                    rdd.count           0.184904
           Seq      count               0.192044
                    queryExecution      0.029069
                    rdd.count           0.036061
           parquet  count               0.963874
                    queryExecution      0.217661
                    rdd.count           0.262279

观察：

• 对于百万条记录，Seq 是最快的，但只有十分之一 秒数很难衡量整个集群的真实速度差异
• 一般而言，将其存储为 TEXT 很慢，这可能是我阅读它的方式，我几乎只使用 Parquet，所以错过一些我很容易错过的东西
• count 和 queryExecution 比 rdd.count 快 每个案例（正如赫尔曼在他的回答中解释的那样）
• count 和 queryExecution 轮流更快，并且在数据类型之间有所不同：
  • 镶木地板的计数更快
  • 对于 Seq，queryExecution 更快
  • 对于文本，它们几乎相同
• 随着尺寸的增加，速度是非线性的

如果有人想要不同的存储类型、计算不同的 dtype、压缩、更多列，请继续评论或给我发消息，我会看看我能做什么