什么时候在Spark2.0中使用rdd？

Question

使用新的SparkSQL API，似乎我们不再需要RDD了。由于RDD很昂贵，我们似乎应该避免它。有人可以解释什么时候是在Spark2中使用RDD的好时机吗？

Answer 1

  

似乎我们不再需要RDD了

RDD API更通用，实际上SQL API是在RDD API之上构建的，带有一堆扩展。

  

由于RDD很昂贵，我们似乎应该避免它。

RDD API本身并不昂贵。它只是不提供与SQL API相同的优化。您仍然可以在RDD之上构建高性能应用程序（例如，检查org.apache.spark.ml）。

  

有人可以解释什么时候在Spark2中使用RDD的好时机吗？

这是基于意见的，但如果您需要端到端类型的安全性或者对没有内置编码器的类型进行大量工作，RDD API是一种自然的选择。

当执行顺序很重要时，您可能更喜欢RDD（您可以使用SQL创建自己的计划程序规则，但需要更多努力）或者您需要低级别控制（如用户定义的Partitioners）。

Answer 2

TLDR：仅在需要对数据的物理分布进行细粒度控制时才应使用RDD。

这可能与Spark 2.0无关，可能与Spark 2.2及更高版本有关。我在Spark: The Definitive Guide中发现了这一点，并且发现本书的这一部分有助于确定是否使用RDD：

  

现代Spark中基本上没有实例，您应该为此   使用RDD而不是结构化的API来处理一些操作   非常原始的未处理和非结构化数据（第44页）。

如果您确定绝对需要使用RDD，则可以参考p。本书中“何时使用RDD”一节中的212。摘录：

  

通常，除非您有一个RDD，否则不应手动创建RDD。   非常非常具体的原因。他们是低得多的水平   提供很多功能但缺乏很多功能的API   结构化API中提供的优化。对于广大   在大多数用例中，DataFrames将会更高效，更稳定，   比RDD更具表现力。

     

为什么要使用RDD的最可能原因是因为您   需要对数据的物理分布进行细粒度控制   （数据的自定义分区）。 （第212页）