Spark随笔 —— RDD 与 DataSet

前言

本篇文章进对 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 了