Spark隨筆 —— RDD 與 DataSet

• 2019 年 10 月 30 日
• 筆記

前言

本篇文章進對 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 了