使用新的SparkSQL API，似乎我们不再需要RDD了。由于RDD很昂贵，因此我们应该避免使用它。有人可以解释什么时候是在Spark2中使用RDD的好时机？
似乎我们不再需要RDD
rdd API更一般，实际上是SQL API，在RDD API的顶部建立了一堆扩展。
由于RDD很昂贵，似乎我们应该避免它。
RDD API本质上并不昂贵。它只是没有提供与SQL API相同的优化。您仍然可以在RDD顶部构建高性能应用程序（例如org.apache.spark.ml）。
有人可以解释什么时候是在Spark2中使用RDD的好时机？
它是基于意见的，但是如果您需要端到端类型的安全性或与没有内置编码器的类型进行很多类型的工作，则RDD API是自然的选择。
当执行顺序很重要时，您可能更喜欢RDD（您可以使用SQL创建自己的计划者规则，但要付出更多的努力），或者您需要低级控制（例如用户定义的Partitioners）。
tldr：如果您需要对数据的物理分布进行细粒度的控制，则应使用RDD。
这可能与Spark 2.0无关，并且可能与Spark 2.2及之后有关。我在Spark中发现了这一点：《权威指南》和《我》一书的这一部分有助于决定是否使用RDD：
基本上没有现代火花中的实例，您应该为此 使用RDD而不是操纵一些结构化的API 非常原始的未加工和非结构化数据（第44页）。
如果您决定绝对需要使用RDD，则可以参考p。212在"何时使用RDD"部分的书中。摘录复制：
通常，除非有一个 这样做的非常非常具体的原因。他们是一个低级的 提供大量功能但也缺乏很多功能的API 结构化API中可用的优化。对于广阔的人 大多数用例中，数据框将更有效，更稳定， 比rdds更具表现力。
最有可能使用RDD的原因是因为您 需要对数据的物理分布进行细粒度控制 （数据自定义分区）。（第212页）