基于Spark的數(shù)據(jù)分析實(shí)踐
轉(zhuǎn)載本文需注明出處:微信公眾號EAWorld,違者必究。
引言:
Spark是在借鑒了MapReduce之上發(fā)展而來的,繼承了其分布式并行計算的優(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ù)抽象,它代表一個不可變、可分區(qū)、元素可并行計算的集合。
RDD具有數(shù)據(jù)流模型的特點(diǎn):自動容錯、位置感知性調(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ù)進(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;}
可左右滑動查看代碼
Spark 任務(wù)提交后通過對輸入進(jìn)行 Split,在 RDD 構(gòu)造階段,只是判斷是否可 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 進(jìn)行 Transformation 并不會觸發(fā)計算:Transformation 方法所產(chǎn)生的 RDD 對象只會記錄住該 RDD 所依賴的 RDD 以及計算產(chǎn)生該 RDD 的數(shù)據(jù)的方式;只有在用戶進(jìn)行 Action 操作時,Spark 才會調(diào)度 RDD 計算任務(wù),依次為各個 RDD 計算數(shù)據(jù)。這就是 Spark RDD 內(nèi)函數(shù)的“懶加載”特性。
二、基于Spark RDD數(shù)據(jù)開發(fā)的不足
由于MapReduce的shuffle過程需寫磁盤,比較影響性能;而Spark利用RDD技術(shù),計算在內(nèi)存中流式進(jìn)行。另外 MapReduce計算框架(API)比較局限, 使用需要關(guān)注的參數(shù)眾多,而Spark則是中間結(jié)果自動推斷,通過對數(shù)據(jù)集上鏈?zhǔn)綀?zhí)行函數(shù)具備一定的靈活性。
即使 SparkRDD 相對于 MapReduce 提高很大的便利性,但在使用上仍然有許多問題。體現(xiàn)在一下幾個方面:
RDD 函數(shù)眾多,開發(fā)者不容易掌握,部分函數(shù)使用不當(dāng) shuffle時造成數(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),會造成不可控的異常;
對多種數(shù)據(jù)開發(fā),需各自開發(fā)RDD的轉(zhuǎn)換,樣板代碼較多,無法有效重利用;
其它在運(yùn)行期可能發(fā)生的異常。如:對象無法序列化等運(yùn)行期才能發(fā)現(xiàn)的異常。

請輸入評論內(nèi)容...
請輸入評論/評論長度6~500個字
最新活動更多
推薦專題
-
10 月之暗面,絕地反擊
- 1 UALink規(guī)范發(fā)布:挑戰(zhàn)英偉達(dá)AI統(tǒng)治的開始
- 2 北電數(shù)智主辦酒仙橋論壇,探索AI產(chǎn)業(yè)發(fā)展新路徑
- 3 降薪、加班、裁員三重暴擊,“AI四小龍”已折戟兩家
- 4 “AI寒武紀(jì)”爆發(fā)至今,五類新物種登上歷史舞臺
- 5 國產(chǎn)智駕迎戰(zhàn)特斯拉FSD,AI含量差幾何?
- 6 光計算迎來商業(yè)化突破,但落地仍需時間
- 7 東陽光:2024年扭虧、一季度凈利大增,液冷疊加具身智能打開成長空間
- 8 地平線自動駕駛方案解讀
- 9 封殺AI“照騙”,“淘寶們”終于不忍了?
- 10 優(yōu)必選:營收大增主靠小件,虧損繼續(xù)又逢關(guān)稅,能否乘機(jī)器人東風(fēng)翻身?