前言

本篇文章进对 RDD 和 DataSet 进行对比和总结。
当然因为随笔，所以想到哪写到哪...
哎~，最近变懒了，都不想动脑子了！！！

• RDD 和 DataSet 有什么关系？
  随着 Spark 版本的不断迭代，已经在慢慢弱化 RDD的概念，
  但是其实作为一个Spark 开发的程序员，
  RDD却是你绝对绕不过去的一个知识点，
  而 DataSet 某种意义上来说其实是 RDD 更高等级的抽象，
  RDD 慢慢已经变成底层的东西了，
  如果有一天，不是程序员也能随心编写Spark了，
  RDD可能就真的不为一般Spark使用者所知了。

• RDD用的好好的，干嘛又整个新的 DS 出来？
  技术是在不断前进的，DS相比RDD确实具有许多它不可比拟的优势。

  1. 更加简单易用，未来很可能只需要简单的培训就可以使用Spark，
     而不需要专业的程序员 或者说 大数据工程师 才能用。好吧~全民分析，全民编程！
  2. 将RDD进行更高一级的抽象，当然也就更利于维护和升级。
  3. 对于很大部分场景，DS在满足业务需求的同时有着更好的性能。

• 那么RDD 是不是可以完全不用了？
  其实不然，上面说了，大部分场景 DS 适用，
  而这里的大部分场景其实是说一些结构化 或者 半结构化数据的，
  对于一些非结构化数据处理起来就无能为力了。
  所以RDD更适合程序员来处理复杂的数据。
  并且RDD 也有：

  1. 编译时类型安全
  2. 面向对象的编程风格

  等优点，当然这些优点都是对于程序员来说的....

这里扯点有的没的，感觉现在编程写代码真的比几年前要简单太多了，
很多东西慢慢都不需要自己去造了，轮子都给你，你转的起来就可以了。
这也导致，很多程序员其实都在慢慢退化，因为不用思考太多，
就能把工作做好了，或者说只要思考下，有没有轮子有没有轮子...
然后就发现一切都有前人在铺路....
我们需要做的就是 CV 操作，就能实现以前想都不敢想的功能，
这到底是好呢？还是不好呢？
也许仁者见仁智者见智，不一样的角度，可能都有不一样的答案吧！！！
好了，我们继续。

• 既然RDD能处理各种各样的数据，那么我不用DS可以吗？
  对，DS能处理的，RDD都能处理，RDD能处理的，DS不一定能处理，
  但是你也可以想想，
  给你一百台机器，你为什么不自己搭个分布式处理引擎呢？
  也许这就是答案吧？
  当然这里我们也说下RDD的一个问题，
  那就是在产生 Shuffle 的时候会频繁的 序列化 和 反序列化。
  当然这里我们说的是 SortShuffle，
  溢写磁盘需要序列化，
  归并小文件到大文件因为需要排序，所以要先 反序列化 成对象，
  反序列化的对象还要存储到磁盘，又要 序列化一次。
  这样就会产生很大的内存开销，也容易造成 GC。

• 既然我们要用DS，那么DS有什么优势呢？
  首先 DS 比 RDD 多了一个对象 Schema。

  1. 因为具有 Schema，所以他的类型其实就没有那么多乱七八糟的类型了，
     因为类型的数据他都可以记录在 Schema 里面，
     数据还是那个数据，做到了 结构体 和 数据 分离，
     这样就提供了一个统一的序列化方式，
     相比RDD是通过对象的序列化方式具有更好的性能 和 更少的开销。
     也因为其没有了 类型 这个东西，序列化的过程，自然也省略掉了这部分开销。
  2. Sortshuffle 排序的过程不再需要调度对象的 Compare 方法了,
     而是直接基于字节码排序，这样就省略掉了一次 序列化 和 反序列化的 开销。
  3. 因为有 Schema，所以其支持单独某列的访问了，
     而不是RDD那种每次都必须加载完整一条数据。
  4. DS 的序列化数据现在是储存在 堆外内存的了，
     堆外内存相比JVM内存，具有更快的传输效率
  5. DS 可以使用SQL，可以使用SQL....

  以上这些我想，已经基本可以让你迫不及待的开始将RDD 迁移到 DS 上来吧。
  当然，DS也有一些不太友好的地方：

  1. 编译时类型不安全
  2. 不再是面向对象的编程风格了

  哎~~，想想也是泪，越来越感觉 大数据处理将不再是程序员的专利了！！！

• 最后扯一句 DF
  DF 即 DataFrame，这是一个特殊的 DS，
  当 DS 类型为 DS[Row] 的时候，就是 DF了，
  不过，DF 也在慢慢弱化，
  不过他没有RDD那么幸运，
  也许未来的某天，我们就真见不到 DF 了

BBBB了这么多.....也挺辛苦的.....
能不能麻烦路过的大佬点个赞~~~~