spark3.0版本可能不太公佈底層的RDD，以後使用dataframe將成爲趨勢，現在大都數公司也多使用dataframe來處理數據
RDD、DataFrame和DataSet是容易產生混淆的概念，必須對其相互之間對比，纔可以知道其中異同。
RDD和DF的區別
上圖直觀地體現了DataFrame和RDD的區別。左側的RDD[Person]雖然以Person爲類型參數，但Spark框架本身不瞭解Person類的內部結構。而右側的DataFrame卻提供了詳細的結構信息，使得Spark SQL可以清楚地知道該數據集中包含哪些列，每列的名稱和類型各是什麼。DataFrame多了數據的結構信息，即schema。RDD是分佈式的Java對象的集合。DataFrame是分佈式的Row對象的集合。DataFrame除了提供了比RDD更豐富的算子以外，更重要的特點是提升執行效率、減少數據讀取以及執行計劃的優化，比如filter下推、裁剪等。
提升執行效率
RDD API是函數式的，強調不變性，在大部分場景下傾向於創建新對象而不是修改老對象。這一特點雖然帶來了乾淨整潔的API，卻也使得Spark應用程序在運行期傾向於創建大量臨時對象，對GC造成壓力。在現有RDD API的基礎之上，我們固然可以利用mapPartitions方法來重載RDD單個分片內的數據創建方式，用複用可變對象的方式來減小對象分配和GC的開銷，但這犧牲了代碼的可讀性，而且要求開發者對Spark運行時機制有一定的瞭解，門檻較高。另一方面，Spark SQL在框架內部已經在各種可能的情況下儘量重用對象，這樣做雖然在內部會打破了不變性，但在將數據返回給用戶時，還會重新轉爲不可變數據。利用 DataFrame API進行開發，可以免費地享受到這些優化效果。
減少數據讀取
分析大數據，最快的方法就是 ——忽略它。這裏的“忽略”並不是熟視無睹，而是根據查詢條件進行恰當的剪枝。
上文討論分區表時提到的分區剪 枝便是其中一種——當查詢的過濾條件中涉及到分區列時，我們可以根據查詢條件剪掉肯定不包含目標數據的分區目錄，從而減少IO。
對於一些“智能”數據格 式，Spark SQL還可以根據數據文件中附帶的統計信息來進行剪枝。簡單來說，在這類數據格式中，數據是分段保存的，每段數據都帶有最大值、最小值、null值數量等 一些基本的統計信息。當統計信息表名某一數據段肯定不包括符合查詢條件的目標數據時，該數據段就可以直接跳過（例如某整數列a某段的最大值爲100，而查詢條件要求a > 200）。
此外，Spark SQL也可以充分利用RCFile、ORC、Parquet等列式存儲格式的優勢，僅掃描查詢真正涉及的列，忽略其餘列的數據。
執行優化
人口數據分析示例
爲了說明查詢優化，我們來看上圖展示的人口數據分析的示例。圖中構造了兩個DataFrame，將它們join之後又做了一次filter操作。如果原封不動地執行這個執行計劃，最終的執行效率是不高的。因爲join是一個代價較大的操作，也可能會產生一個較大的數據集。如果我們能將filter下推到 join下方，先對DataFrame進行過濾，再join過濾後的較小的結果集，便可以有效縮短執行時間。而Spark SQL的查詢優化器正是這樣做的。簡而言之，邏輯查詢計劃優化就是一個利用基於關係代數的等價變換，將高成本的操作替換爲低成本操作的過程。
得到的優化執行計劃在轉換成物 理執行計劃的過程中，還可以根據具體的數據源的特性將過濾條件下推至數據源內。最右側的物理執行計劃中Filter之所以消失不見，就是因爲溶入了用於執行最終的讀取操作的表掃描節點內。
對於普通開發者而言，查詢優化 器的意義在於，即便是經驗並不豐富的程序員寫出的次優的查詢，也可以被儘量轉換爲高效的形式予以執行。