轉載本文需注明出處：微信公眾號EAWorld，違者必究。

引言：

Spark是在借鑒了MapReduce之上發(fā)展而來的，繼承了其分布式并行計算的優(yōu)點并改進了MapReduce明顯的缺陷。Spark主要包含了Spark Core、Spark SQL、Spark Streaming、MLLib和GraphX等組件。

本文主要分析了 Spark RDD 以及 RDD 作為開發(fā)的不足之處，介紹了 SparkSQL 對已有的常見數(shù)據(jù)系統(tǒng)的操作方法，以及重點介紹了普元在眾多數(shù)據(jù)開發(fā)項目中總結的基于 SparkSQL Flow 開發(fā)框架。

目錄：

一、Spark RDD

二、基于Spark RDD數(shù)據(jù)開發(fā)的不足

三、SparkSQL

四、SparkSQL Flow

一、Spark RDD

RDD（Resilient Distributed Dataset）叫做彈性分布式數(shù)據(jù)集，是Spark中最基本的數(shù)據(jù)抽象，它代表一個不可變、可分區(qū)、元素可并行計算的集合。

RDD具有數(shù)據(jù)流模型的特點：自動容錯、位置感知性調(diào)度和可伸縮性。

／／Scala 在內(nèi)存中使用列表創(chuàng)建

val lines ＝ List（“A”， “B”， “C”， “D” …）val rdd：RDD ＝ sc．parallelize（lines）；

可左右滑動查看代碼

／／以文本文件創(chuàng)建

val rdd：RDD［String］ ＝ sc．textFile（“hdfs：／／path／filename”）

可左右滑動查看代碼

Spark RDD Partition 分區(qū)劃分

新版本的 Hadoop 已經(jīng)把 BlockSize 改為 128M，也就是說每個分區(qū)處理的數(shù)據(jù)量更大。

Spark 讀取文件分區(qū)的核心原理

本質(zhì)上，Spark 是利用了 Hadoop 的底層對數(shù)據(jù)進行分區(qū)的 API（InputFormat）：

public abstract class InputFormat＜K，V＞｛  public abstract List＜InputSplit＞ getSplits（JobContextcontext                               ） throwsIOException，InterruptedException；    public abstract RecordReader＜K，V＞ createRecordReader（InputSplitsplit，                                         TaskAttemptContextcontext                                        ）throwsIOException，InterruptedException；｝

可左右滑動查看代碼

Spark 任務提交后通過對輸入進行 Split，在 RDD 構造階段，只是判斷是否可 Split（如果參數(shù)異常一定在此階段報出異常），并且 Split 后每個 InputSplit 都是一個分區(qū)。只有在Action 算子提交后，才真正用 getSplits 返回的 InputSplit 通過 createRecordReader 獲得每個 Partition 的連接。

然后通過 RecordReader 的 next（） 遍歷分區(qū)內(nèi)的數(shù)據(jù)。

Spark RDD 轉換函數(shù)和提交函數(shù)

Spark RDD 的眾多函數(shù)可分為兩大類Transformation 與 Action。Transformation 與 Action 的區(qū)別在于，對 RDD 進行 Transformation 并不會觸發(fā)計算：Transformation 方法所產(chǎn)生的 RDD 對象只會記錄住該 RDD 所依賴的 RDD 以及計算產(chǎn)生該 RDD 的數(shù)據(jù)的方式；只有在用戶進行 Action 操作時，Spark 才會調(diào)度 RDD 計算任務，依次為各個 RDD 計算數(shù)據(jù)。這就是 Spark RDD 內(nèi)函數(shù)的“懶加載”特性。

二、基于Spark RDD數(shù)據(jù)開發(fā)的不足

由于MapReduce的shuffle過程需寫磁盤，比較影響性能；而Spark利用RDD技術，計算在內(nèi)存中流式進行。另外 MapReduce計算框架（API）比較局限， 使用需要關注的參數(shù)眾多，而Spark則是中間結果自動推斷，通過對數(shù)據(jù)集上鏈式執(zhí)行函數(shù)具備一定的靈活性。

即使 SparkRDD 相對于 MapReduce 提高很大的便利性，但在使用上仍然有許多問題。體現(xiàn)在一下幾個方面：

RDD 函數(shù)眾多，開發(fā)者不容易掌握，部分函數(shù)使用不當 shuffle時造成數(shù)據(jù)傾斜影響性能；

RDD 關注點仍然是Spark太底層的 API，基于 Spark RDD的開發(fā)是基于特定語言（Scala，Python，Java）的函數(shù)開發(fā)，無法以數(shù)據(jù)的視界來開發(fā)數(shù)據(jù)；

對 RDD 轉換算子函數(shù)內(nèi)部分常量、變量、廣播變量使用不當，會造成不可控的異常；

對多種數(shù)據(jù)開發(fā)，需各自開發(fā)RDD的轉換，樣板代碼較多，無法有效重利用；

其它在運行期可能發(fā)生的異常。如：對象無法序列化等運行期才能發(fā)現(xiàn)的異常。