一說大數(shù)據(jù),人們往往想到Hadoop。這固然不錯(cuò),但隨著大數(shù)據(jù)技術(shù)的深入應(yīng)用,多種類型的數(shù)據(jù)應(yīng)用不斷被要求提出,一些Hadoop被關(guān)注的范疇開始被人們注意,相關(guān)技術(shù)也迅速獲得專業(yè)技術(shù)范疇的應(yīng)用。最近半年來的Spark之熱就是典型例子。
Spark是一個(gè)基于RAM計(jì)算的開源碼ComputerCluster運(yùn)算系統(tǒng),目的是更快速地進(jìn)行數(shù)據(jù)分析。Spark早期的核心部分代碼只有3萬行。Spark提供了與HadoopMap/Reduce相似的分散式運(yùn)算框架,但基于RAM和優(yōu)化設(shè)計(jì),因此在交換式數(shù)據(jù)分析和datamining的Workload中表現(xiàn)不錯(cuò)。
進(jìn)入2014年以后,Spark開源碼生態(tài)系統(tǒng)大幅增長,已成為大數(shù)據(jù)范疇最活躍的開源碼項(xiàng)目之一。Spark之所以有如此多的關(guān)注,塬因主要是因?yàn)镾park具有的高性能、高靈活性、與Hadoop生態(tài)系統(tǒng)完美融合等叁方面的特點(diǎn)。
首先,Spark對(duì)分散的數(shù)據(jù)集進(jìn)行抽樣,創(chuàng)新地提出RDD(ResilientDistributedDataset)的概念,所有的統(tǒng)計(jì)分析任務(wù)被翻譯成對(duì)RDD的基本操作組成的有向無環(huán)圖(DAG)。RDD可以被駐留在RAM中,往后的任務(wù)可以直接讀取RAM中的數(shù)據(jù);同時(shí)分析DAG中任務(wù)之間的依賴性可以把相鄰的任務(wù)合并,從而減少了大量不準(zhǔn)確的結(jié)果輸出,極大減少了HarddiskI/O,使復(fù)雜數(shù)據(jù)分析任務(wù)更高效。從這個(gè)推算,如果任務(wù)夠復(fù)雜,Spark比Map/Reduce快一到兩倍。
其次,Spark是一個(gè)靈活的運(yùn)算框架,適合做批次處理、工作流、交互式分析、流量處理等不同類型的應(yīng)用,因此Spark也可以成為一個(gè)用途廣泛的運(yùn)算引擎,并在未來取代Map/Reduce的地位。
最后,Spark可以與Hadoop生態(tài)系統(tǒng)的很多組件互相操作。Spark可以運(yùn)行在新一代資源管理框架YARN上,它還可以讀取已有并存放在Hadoop上的數(shù)據(jù),這是個(gè)非常大的優(yōu)勢。
雖然Spark具有以上叁大優(yōu)點(diǎn),但從目前Spark的發(fā)展和應(yīng)用現(xiàn)狀來看,Spark本身也存在很多缺陷,主要包括以下幾個(gè)方面:
–穩(wěn)定性方面,由于代碼質(zhì)量問題,Spark長時(shí)間運(yùn)行會(huì)經(jīng)常出錯(cuò),在架構(gòu)方面,由于大量數(shù)據(jù)被緩存在RAM中,Java回收垃圾緩慢的情況嚴(yán)重,導(dǎo)致Spark性能不穩(wěn)定,在復(fù)雜場景中SQL的性能甚至不如現(xiàn)有的Map/Reduce。
–不能處理大數(shù)據(jù),單獨(dú)機(jī)器處理數(shù)據(jù)過大,或者由于數(shù)據(jù)出現(xiàn)問題導(dǎo)致中間結(jié)果超過RAM的大小時(shí),常常出現(xiàn)RAM空間不足或無法得出結(jié)果。然而,Map/Reduce運(yùn)算框架可以處理大數(shù)據(jù),在這方面,Spark不如Map/Reduce運(yùn)算框架有效。
–不能支持復(fù)雜的SQL統(tǒng)計(jì);目前Spark支持的SQL語法完整程度還不能應(yīng)用在復(fù)雜數(shù)據(jù)分析中。在可管理性方面,SparkYARN的結(jié)合不完善,這就為使用過程中埋下隱憂,容易出現(xiàn)各種難題。
雖然Spark活躍在Cloudera、MapR、Hortonworks等眾多知名大數(shù)據(jù)公司,但是如果Spark本身的缺陷得不到及時(shí)處理,將會(huì)嚴(yán)重影響Spark的普及和發(fā)展。