一種基于Spark-SQL大數(shù)據(jù)處理平臺(tái)的后臺(tái)刷新方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及一種大數(shù)據(jù)處理平臺(tái)的后臺(tái)刷新方法，尤其涉及一種基于Spark-SQL大數(shù)據(jù)處理平臺(tái)的后臺(tái)刷新方法。
【背景技術(shù)】
[0002]隨著互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)和物聯(lián)網(wǎng)的發(fā)展，我們迎來(lái)了一個(gè)大數(shù)據(jù)的時(shí)代，對(duì)這些大數(shù)據(jù)的處理和分析已經(jīng)成為一個(gè)非常重要且緊迫的需求。
[0003]隨著技術(shù)的發(fā)展，大數(shù)據(jù)處理平臺(tái)經(jīng)歷了最初的Hadoop和Hbase，以及后來(lái)發(fā)展起來(lái)的基于SQL的Hive、Shark等?；趉ey-value的Hbase等處理平臺(tái)也逐漸興起。而如今SQL-on-Hadoop概念的興起又促使Spark生態(tài)發(fā)展壯大，逐漸成為最熱門(mén)，使用最多，效率最好的一種大數(shù)據(jù)處理平臺(tái)。
[0004]不管采取哪種大數(shù)據(jù)處理平臺(tái)，它們的目的都是處理和分析大數(shù)據(jù)，從中分析和挖掘出有用的數(shù)據(jù)供人們使用O從最基本的原理來(lái)看，無(wú)論是基于Map-Reduce的Hadoop，還是基于Key-Value鍵值對(duì)的Hbase，或者是基于RDD的Spark，它們的總體處理流程都是相同的，都是包含了數(shù)據(jù)導(dǎo)入_>數(shù)據(jù)分析和處理_>數(shù)據(jù)結(jié)果展示三個(gè)主要步驟，其中最重要的兩個(gè)部分為數(shù)據(jù)導(dǎo)入和數(shù)據(jù)分析處理過(guò)程，數(shù)據(jù)導(dǎo)入的速度決定了整個(gè)系統(tǒng)能夠?qū)崟r(shí)處理數(shù)據(jù)速度，影響到整個(gè)系統(tǒng)的處理性能，數(shù)據(jù)導(dǎo)入和分析的過(guò)程則是數(shù)據(jù)處理的核心。
[0005]如圖1所示，Spark大數(shù)據(jù)處理平臺(tái)總體框架是:Spark大數(shù)據(jù)處理平臺(tái)的數(shù)據(jù)導(dǎo)入功能由Spark-SQL實(shí)現(xiàn)，即由Hive on Spark來(lái)實(shí)現(xiàn)的，Hive查詢可以作為Spark的任務(wù)提交至IjSpark集群上進(jìn)行計(jì)算。Hi ve相較于Impala和Shark等對(duì)SQL語(yǔ)法有著更全面的支持和更為廣泛的用戶基礎(chǔ)。數(shù)據(jù)導(dǎo)入通常涉及導(dǎo)入內(nèi)容、存儲(chǔ)格式、導(dǎo)入速度等關(guān)鍵點(diǎn):
[0006]1、導(dǎo)入內(nèi)容
[0007]通常導(dǎo)入內(nèi)容可以為格式化或非格式化的文本文件，以特定的分隔符或文件格式分隔每一條記錄及每一個(gè)字段，數(shù)據(jù)內(nèi)容可以是文件形式傳送，也可以是數(shù)據(jù)流形式傳送，且大小具有不確定性。
[0008]2、存儲(chǔ)格式
[0009]存儲(chǔ)數(shù)據(jù)的格式可以是文本格式，也可以是壓縮格式，以減少磁盤(pán)使用量，目前Spark-SQL支持的壓縮格式有zip、snappy及parquet等等。
[0010]在大數(shù)據(jù)的背景下，導(dǎo)入數(shù)據(jù)可以根據(jù)內(nèi)容進(jìn)行分區(qū)，將數(shù)據(jù)按分區(qū)進(jìn)行存儲(chǔ)，可加快查詢速度。
[0011]3、導(dǎo)入速度
[0012]在大數(shù)據(jù)的背景下，由于數(shù)據(jù)在源源不斷地產(chǎn)生，這就對(duì)數(shù)據(jù)導(dǎo)入速度提出了較高的要求，根據(jù)實(shí)際情況要求導(dǎo)入速度不得低于X條每秒或者xMB每秒，同時(shí)還要求保證不得出現(xiàn)數(shù)據(jù)丟失、數(shù)據(jù)導(dǎo)入錯(cuò)誤、數(shù)據(jù)積壓等情況。
[0013]現(xiàn)有技術(shù)中，基于Spark-SQL數(shù)據(jù)導(dǎo)入與數(shù)據(jù)刷新方案(外部數(shù)據(jù)文件為文本格式)如下:
[0014]當(dāng)發(fā)起查詢時(shí)，可以在條件子句中加入信息，從而限定查詢的數(shù)據(jù)范圍。在Spark大數(shù)據(jù)處理平臺(tái)中，不同的存儲(chǔ)格式有著不同的刷新機(jī)制，主要為如下兩種:
[0015]i)若數(shù)據(jù)最終按文本(TEXTFILE)或優(yōu)化列存儲(chǔ)(ORC)ZIP或SNAPPY進(jìn)行存儲(chǔ)，每次查詢大數(shù)據(jù)表時(shí)，會(huì)先掃描分布式文件系統(tǒng)HDFS上的目錄結(jié)構(gòu)和更新元數(shù)據(jù)庫(kù)，能識(shí)別出HDFS上該表空間的所有更新，包括插入、修改和刪除操作。在目錄結(jié)構(gòu)多、數(shù)據(jù)文件多的情況下，每掃描一次HDF S的時(shí)間都很長(zhǎng)，且隨著時(shí)間的推移而增加。掃描HDF S的時(shí)間包含在了查詢時(shí)間中，掃描完HDFS以后Spark才會(huì)根據(jù)掃描結(jié)果劃分任務(wù)，提交給執(zhí)行器去執(zhí)行，因此掃描時(shí)間的長(zhǎng)短直接影響了查詢時(shí)間的長(zhǎng)短。
[0016]ii)若數(shù)據(jù)最終按PARQUET格式進(jìn)行壓縮存儲(chǔ)，首次查詢數(shù)據(jù)表時(shí)，會(huì)先掃描分布式文件系統(tǒng)HDFS上的目錄結(jié)構(gòu)和更新元數(shù)據(jù)庫(kù)，因此在大數(shù)據(jù)的背景下，首次查詢的時(shí)間會(huì)很長(zhǎng);而非首次查詢不再去掃描HDFS的目錄結(jié)構(gòu)，直接利用首次查詢的掃描結(jié)果，旨在縮短最終的查詢時(shí)間。這種機(jī)制的優(yōu)點(diǎn)在于非首次查詢的速度較快，但也存在著不容忽視的弊端，那就是在首次查詢的掃描以后，任何對(duì)HDFS上該表空間的直接修改都不能識(shí)別，任何插入和刪除操作(HDFS原則上不支持修改操作)都只能通過(guò)Spark-SQL來(lái)完成，在Spark執(zhí)行器資源有限的情況下，讀和寫(xiě)均占用了一定的系統(tǒng)資源，間接導(dǎo)致了數(shù)據(jù)導(dǎo)入速度和查詢速度的下降。另外，當(dāng)HDFS上該表空間的某個(gè)數(shù)據(jù)文件丟失時(shí)，會(huì)導(dǎo)致Spark上對(duì)該表的所有查詢失敗，出現(xiàn)該文件不存在的錯(cuò)誤，只能重啟Spark-SQL進(jìn)程，重新進(jìn)行首次查詢并掃描HDFS0
[0017]綜上所述，現(xiàn)有技術(shù)中存在的問(wèn)題有:
[0018]USpark-SQL首次查詢會(huì)根據(jù)查詢的表掃描其在HDFS分布式文件系統(tǒng)中整個(gè)表空間，并保存該表空間快照，在大數(shù)據(jù)的背景下，首次查詢需要非常長(zhǎng)的時(shí)間，不能滿足時(shí)間要求。在掃描以后對(duì)該表的任何修改，Spark-SQL都不能識(shí)別。
[0019]2、現(xiàn)有技術(shù)基于hive或者Spark-SQL的數(shù)據(jù)導(dǎo)入程序，采用Scala語(yǔ)言編寫(xiě)，運(yùn)行在JVM虛擬機(jī)上，存在效率低、速度慢、容易內(nèi)存溢出等問(wèn)題。Scala是一種純粹的面向?qū)ο缶幊陶Z(yǔ)言，它用Scalac編譯器把源文件編譯成Java的class文件(即在JVM上運(yùn)行的字節(jié)碼)，所以是解釋型語(yǔ)言，查詢及導(dǎo)入效率較低。
[°02°] 3、在Spark大數(shù)據(jù)處理平臺(tái)的Standalone模式下，控制節(jié)點(diǎn)存在資源上的浪費(fèi)?，F(xiàn)有技術(shù)中，Spark大數(shù)據(jù)處理平臺(tái)一般部署為一個(gè)集群，集群由若干臺(tái)機(jī)器組成。在集群運(yùn)行過(guò)程中，通常外部數(shù)據(jù)的導(dǎo)入和對(duì)數(shù)據(jù)的實(shí)時(shí)查詢同步進(jìn)行，因此，集群中機(jī)器的資源將同時(shí)分配給數(shù)據(jù)導(dǎo)入程序和數(shù)據(jù)查詢程序，在1沖突、CPU時(shí)間爭(zhēng)搶以及內(nèi)存的申請(qǐng)方面，兩者必將有或多或少的沖突，嚴(yán)重時(shí)兩者性能將大打折扣。

【發(fā)明內(nèi)容】

[0021]本發(fā)明要解決的技術(shù)問(wèn)題是在大數(shù)據(jù)的背景下，避開(kāi)首次查詢掃描分布式文件系統(tǒng)HDFS的步驟，大幅縮短Spark-SQL大數(shù)據(jù)處理平臺(tái)的首次查詢時(shí)間。
[0022]為了解決上述技術(shù)問(wèn)題，本發(fā)明基于Spark-SQL大數(shù)據(jù)處理平臺(tái)的后臺(tái)刷新方法是在Spark-SQL的入口函數(shù)中創(chuàng)建刷新進(jìn)程并設(shè)定定時(shí)刷新機(jī)制，定時(shí)掃描分布式文件系統(tǒng)HDFS的指定表空間文件目錄結(jié)構(gòu)。
[0023]在Spark安裝目錄的conf文件夾下的hive-site.xml中增加配置項(xiàng)，可以自定義配置后臺(tái)刷新進(jìn)程是否開(kāi)啟，刷新間隔大小與要刷新的大數(shù)據(jù)表空間集合。
[0024]若開(kāi)啟后臺(tái)刷新進(jìn)程，則在刷新進(jìn)程首次刷新完成之前，內(nèi)存中尚沒(méi)有指定表空間的目錄結(jié)構(gòu)信息，這時(shí)Spark-SQL若收到查詢語(yǔ)句，則采用原始的首次刷新策略，查詢之前先掃描分布式文件系統(tǒng)HDFS指定表空間的文件目錄結(jié)構(gòu);若刷新進(jìn)程首次刷新完成，則將HDFS上指定表空間的目錄結(jié)構(gòu)信息保存在內(nèi)存中，當(dāng)Spark-SQL接收到查詢語(yǔ)句時(shí)則不再掃描HDFS，直接使用內(nèi)存中該表空間的目錄結(jié)構(gòu)信息，達(dá)到縮短查詢時(shí)間的效果。
[0025]所述刷新間隔是刷新一次所用時(shí)間的十分之一至二分之一，或者，所述刷新間隔是5秒至10秒，可以根據(jù)產(chǎn)品或者用戶需求自定義所述刷新間隔大小。
[0026]將外部數(shù)據(jù)文件進(jìn)行壓縮存儲(chǔ)，所述壓縮格式為ZIP、BZ2、SNAPPY或PARQUET。
[0027]采用Scala編程，修改Spark源碼中關(guān)于Spark-SQL執(zhí)行查詢語(yǔ)句的策略。
[0028]在刷新以前，先依次進(jìn)行創(chuàng)建臨時(shí)表、創(chuàng)建帶分區(qū)信息的大數(shù)據(jù)表、將文