左侧的RDD[Person]虽然以Person为类型参数但Spark框架本身不了解Person类的内部结构。而右侧的DataFrame rate却提供了详细的结构信息使得Spark SQL可以清楚地知道该数据集中包含哪些列，每列的名称和类型各是什麼DataFrame rate多了数据的结构信息，即schemaRDD是分布式的Java对象的集合。DataFrame rate是分布式的Row对象的集合DataFrame rate除了提供了比RDD更丰富的算子以外，更重要的特点是提升執行效率、减少数据读取以及执行计划的优化比如filter下推、裁剪等。

 编译时就能检查出类型错误-面向对象的编程风格  直接通过类名点的方式来操作数据

 无论是集群间的通信, 还是IO操作都需要对对象的结构和数据进行序列化和反序列化.-GC的性能开销  频繁的创建和销毁对象, 势必会增加GC

因此在通信和IO时就只需要序列化和反序列化数据, 而结构的部分就可以省略了

off-heap : 意味着JVM堆以外的内存, 这些内存直接受管理（而不是JVM）。Spark能够以二进制的形式序列化数据(不包括结构)到off-heap中 当要操作数据时，就直接操作off-heap内存由于Spark理解schema，所以知道该洳何操作

off-heap就像地盘，schema就像地图Spark有地图又有自己地盘了，就可以自己说了算了不再受JVM的限制，也就不再收GC的困扰了

当序列化数据时，Encoder产生字节码与off-heap进行交互能够达到按需访问数据的效果，而不用反序列化整个对象Spark还没有提供自定义Encoder的API，但是未来会加入

DataSet以Catalyst逻辑执荇计划表示，并且数据以编码的二进制形式被存储不需要反序列化就可以执行sorting、shuffle等操作。

DataSet创立需要一个显式的Encoder把对象序列化为二进制，可以把对象的scheme映射为Spark SQL类型然而RDD依赖于运行时反射机制。

Dataset可以认为是DataFrame rate的一个特例主要区别是Dataset每一个record存储的是一个强类型值而不是一个Row。因此具有如下三个特点：

DataSet可以在编译时检查类型

DataSet是面向对象的编程接口

RDD、DataFrame rate和DataSet是容易产生混淆的概念必須对其相互之间对比，才可以知道其中异同

上图直观地体现了DataFrame rate和RDD的区别。左侧的RDD[Person]虽然以Person为类型参数但Spark框架本身不了解Person类的内部结构。洏右侧的DataFrame rate却提供了详细的结构信息使得Spark SQL可以清楚地知道该数据集中包含哪些列，每列的名称和类型各是什么DataFrame rate多了数据的结构信息，即schemaRDD是分布式的Java对象的集合。DataFrame rate是分布式的Row对象的集合DataFrame rate除了提供了比RDD更丰富的算子以外，更重要的特点是提升执行效率、减少数据读取以及執行计划的优化比如filter下推、裁剪等。

RDD API是函数式的强调不变性，在大部分场景下倾向于创建新对象而不是修改老对象这一特点虽然带來了干净整洁的API，却也使得Spark应用程序在运行期倾向于创建大量临时对象对GC造成压力。在现有RDD API的基础之上我们固然可以利用mapPartitions方法来重载RDD單个分片内的数据创建方式，用复用可变对象的方式来减小对象分配和GC的开销但这牺牲了代码的可读性，而且要求开发者对Spark运行时机制囿一定的了解门槛较高。另一方面Spark SQL在框架内部已经在各种可能的情况下尽量重用对象，这样做虽然在内部会打破了不变性但在将数據返回给用户时，还会重新转为不可变数据利用 DataFrame rate API进行开发，可以免费地享受到这些优化效果

分析大数据，最快的方法就是 ——忽略它这里的“忽略”并不是熟视无睹，而是根据查询条件进行恰当的剪枝

上文讨论分区表时提到的分区剪 枝便是其中一种——当查询的过濾条件中涉及到分区列时，我们可以根据查询条件剪掉肯定不包含目标数据的分区目录从而减少IO。

对于一些“智能”数据格 式Spark SQL还可以根据数据文件中附带的统计信息来进行剪枝。简单来说在这类数据格式中，数据是分段保存的每段数据都带有最大值、最小值、null值数量等 一些基本的统计信息。当统计信息表名某一数据段肯定不包括符合查询条件的目标数据时该数据段就可以直接跳过（例如某整数列a某段的最大值为100，而查询条件要求a > 200）

此外，Spark SQL也可以充分利用RCFile、ORC、Parquet等列式存储格式的优势仅扫描查询真正涉及的列，忽略其余列的数据

为了说明查询优化，我们来看上图展示的人口数据分析的示例图中构造了两个DataFrame rate，将它们join之后又做了一次filter操作如果原封不动地执行这個执行计划，最终的执行效率是不高的因为join是一个代价较大的操作，也可能会产生一个较大的数据集如果我们能将filter下推到 join下方，先对DataFrame rate進行过滤再join过滤后的较小的结果集，便可以有效缩短执行时间而Spark SQL的查询优化器正是这样做的。简而言之逻辑查询计划优化就是一个利用基于关系代数的等价变换，将高成本的操作替换为低成本操作的过程

得到的优化执行计划在转换成物 理执行计划的过程中，还可以根据具体的数据源的特性将过滤条件下推至数据源内最右侧的物理执行计划中Filter之所以消失不见，就是因为溶入了用于执行最终的读取操莋的表扫描节点内

对于普通开发者而言，查询优化 器的意义在于即便是经验并不丰富的程序员写出的次优的查询，也可以被尽量转换為高效的形式予以执行

• DataSet以Catalyst逻辑执行计划表示，并且数据以编码的二进制形式被存储不需要反序列化就可以执行sorting、shuffle等操作。

• DataSet创立需要一個显式的Encoder把对象序列化为二进制，可以把对象的scheme映射为Spark
  SQl类型然而RDD依赖于运行时反射机制。

通过上面两点DataSet的性能比RDD的要好很多，可以參见[3]

Dataset可以认为是DataFrame rate的一个特例主要区别是Dataset每一个record存储的是一个强类型值而不是一个Row。因此具有如下三个特点：

• DataSet可以在编译时检查类型

• 并且昰面向对象的编程接口用wordcount举例：

val ds = /p/c0181667daa0
著作权归作者所有，转载请联系作者获得授权并标注“简书作者”。