訂閱
糾錯
加入自媒體

基于Spark的數(shù)據(jù)分析實踐

2019-06-19 09:55
EAWorld
關注

轉(zhuǎn)載本文需注明出處:微信公眾號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 轉(zhuǎn)換函數(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 轉(zhuǎn)換算子函數(shù)內(nèi)部分常量、變量、廣播變量使用不當,會造成不可控的異常;

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

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

1  2  3  4  下一頁>  
聲明: 本文由入駐維科號的作者撰寫,觀點僅代表作者本人,不代表OFweek立場。如有侵權或其他問題,請聯(lián)系舉報。

發(fā)表評論

0條評論,0人參與

請輸入評論內(nèi)容...

請輸入評論/評論長度6~500個字

您提交的評論過于頻繁,請輸入驗證碼繼續(xù)

暫無評論

暫無評論

人工智能 獵頭職位 更多
掃碼關注公眾號
OFweek人工智能網(wǎng)
獲取更多精彩內(nèi)容
文章糾錯
x
*文字標題:
*糾錯內(nèi)容:
聯(lián)系郵箱:
*驗 證 碼:

粵公網(wǎng)安備 44030502002758號