基于Spark的數(shù)據(jù)分析實(shí)踐
轉(zhuǎn)載本文需注明出處:微信公眾號EAWorld,違者必究。
引言:
Spark是在借鑒了MapReduce之上發(fā)展而來的,繼承了其分布式并行計(jì)算的優(yōu)點(diǎn)并改進(jìn)了MapReduce明顯的缺陷。Spark主要包含了Spark Core、Spark SQL、Spark Streaming、MLLib和GraphX等組件。
本文主要分析了 Spark RDD 以及 RDD 作為開發(fā)的不足之處,介紹了 SparkSQL 對已有的常見數(shù)據(jù)系統(tǒng)的操作方法,以及重點(diǎn)介紹了普元在眾多數(shù)據(jù)開發(fā)項(xiàng)目中總結(jié)的基于 SparkSQL Flow 開發(fā)框架。
目錄:
一、Spark RDD
二、基于Spark RDD數(shù)據(jù)開發(fā)的不足
三、SparkSQL
四、SparkSQL Flow
一、Spark RDD
RDD(Resilient Distributed Dataset)叫做彈性分布式數(shù)據(jù)集,是Spark中最基本的數(shù)據(jù)抽象,它代表一個(gè)不可變、可分區(qū)、元素可并行計(jì)算的集合。
RDD具有數(shù)據(jù)流模型的特點(diǎn):自動(dòng)容錯(cuò)、位置感知性調(diào)度和可伸縮性。
//Scala 在內(nèi)存中使用列表創(chuàng)建
val lines = List(“A”, “B”, “C”, “D” …)val rdd:RDD = sc.parallelize(lines);
可左右滑動(dòng)查看代碼
//以文本文件創(chuàng)建
val rdd:RDD[String] = sc.textFile(“hdfs://path/filename”)
可左右滑動(dòng)查看代碼
Spark RDD Partition 分區(qū)劃分
新版本的 Hadoop 已經(jīng)把 BlockSize 改為 128M,也就是說每個(gè)分區(qū)處理的數(shù)據(jù)量更大。
Spark 讀取文件分區(qū)的核心原理
本質(zhì)上,Spark 是利用了 Hadoop 的底層對數(shù)據(jù)進(jìn)行分區(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;}
可左右滑動(dòng)查看代碼
Spark 任務(wù)提交后通過對輸入進(jìn)行 Split,在 RDD 構(gòu)造階段,只是判斷是否可 Split(如果參數(shù)異常一定在此階段報(bào)出異常),并且 Split 后每個(gè) InputSplit 都是一個(gè)分區(qū)。只有在Action 算子提交后,才真正用 getSplits 返回的 InputSplit 通過 createRecordReader 獲得每個(gè) Partition 的連接。
然后通過 RecordReader 的 next() 遍歷分區(qū)內(nèi)的數(shù)據(jù)。
Spark RDD 轉(zhuǎn)換函數(shù)和提交函數(shù)
Spark RDD 的眾多函數(shù)可分為兩大類Transformation 與 Action。Transformation 與 Action 的區(qū)別在于,對 RDD 進(jìn)行 Transformation 并不會(huì)觸發(fā)計(jì)算:Transformation 方法所產(chǎn)生的 RDD 對象只會(huì)記錄住該 RDD 所依賴的 RDD 以及計(jì)算產(chǎn)生該 RDD 的數(shù)據(jù)的方式;只有在用戶進(jìn)行 Action 操作時(shí),Spark 才會(huì)調(diào)度 RDD 計(jì)算任務(wù),依次為各個(gè) RDD 計(jì)算數(shù)據(jù)。這就是 Spark RDD 內(nèi)函數(shù)的“懶加載”特性。
二、基于Spark RDD數(shù)據(jù)開發(fā)的不足
由于MapReduce的shuffle過程需寫磁盤,比較影響性能;而Spark利用RDD技術(shù),計(jì)算在內(nèi)存中流式進(jìn)行。另外 MapReduce計(jì)算框架(API)比較局限, 使用需要關(guān)注的參數(shù)眾多,而Spark則是中間結(jié)果自動(dòng)推斷,通過對數(shù)據(jù)集上鏈?zhǔn)綀?zhí)行函數(shù)具備一定的靈活性。
即使 SparkRDD 相對于 MapReduce 提高很大的便利性,但在使用上仍然有許多問題。體現(xiàn)在一下幾個(gè)方面:
RDD 函數(shù)眾多,開發(fā)者不容易掌握,部分函數(shù)使用不當(dāng) shuffle時(shí)造成數(shù)據(jù)傾斜影響性能;
RDD 關(guān)注點(diǎn)仍然是Spark太底層的 API,基于 Spark RDD的開發(fā)是基于特定語言(Scala,Python,Java)的函數(shù)開發(fā),無法以數(shù)據(jù)的視界來開發(fā)數(shù)據(jù);
對 RDD 轉(zhuǎn)換算子函數(shù)內(nèi)部分常量、變量、廣播變量使用不當(dāng),會(huì)造成不可控的異常;
對多種數(shù)據(jù)開發(fā),需各自開發(fā)RDD的轉(zhuǎn)換,樣板代碼較多,無法有效重利用;
其它在運(yùn)行期可能發(fā)生的異常。如:對象無法序列化等運(yùn)行期才能發(fā)現(xiàn)的異常。

發(fā)表評論
請輸入評論內(nèi)容...
請輸入評論/評論長度6~500個(gè)字
最新活動(dòng)更多
-
7月8日立即報(bào)名>> 【在線會(huì)議】英飛凌新一代智能照明方案賦能綠色建筑與工業(yè)互聯(lián)
-
7月22-29日立即報(bào)名>> 【線下論壇】第三屆安富利汽車生態(tài)圈峰會(huì)
-
7.30-8.1火熱報(bào)名中>> 全數(shù)會(huì)2025(第六屆)機(jī)器人及智能工廠展
-
7月31日免費(fèi)預(yù)約>> OFweek 2025具身智能機(jī)器人產(chǎn)業(yè)技術(shù)創(chuàng)新應(yīng)用論壇
-
免費(fèi)參會(huì)立即報(bào)名>> 7月30日- 8月1日 2025全數(shù)會(huì)工業(yè)芯片與傳感儀表展
-
即日-2025.8.1立即下載>> 《2024智能制造產(chǎn)業(yè)高端化、智能化、綠色化發(fā)展藍(lán)皮書》
推薦專題