大數(shù)據(jù)環(huán)境下Spark性能優(yōu)化分析研究與應(yīng)用

黃志 蘇傳程 蘇曉紅

(廣西壯族自治區(qū)氣象信息中心，南寧 530022)

引言

CIMISS(China Integrated Meteorological Information Sharing System) 作為國省統(tǒng)一數(shù)據(jù)環(huán)境，是目前開展氣象數(shù)據(jù)服務(wù)的核心基礎(chǔ)數(shù)據(jù)支撐平臺(tái)。CIMISS的存儲(chǔ)架構(gòu)采用ORACLE關(guān)系型數(shù)據(jù)庫，目前數(shù)據(jù)量已達(dá)到億數(shù)量級(jí)，由于關(guān)系型數(shù)據(jù)庫存儲(chǔ)壓縮比不高，使得存儲(chǔ)空間日趨緊張，數(shù)據(jù)庫管理維護(hù)任務(wù)繁瑣而艱巨[1-3]。MUSIC(Meteorological Unified Service Interface Community：氣象數(shù)據(jù)統(tǒng)一服務(wù)接口)接口對于短時(shí)間序列的數(shù)據(jù)查詢與統(tǒng)計(jì)時(shí)效較快，隨著用戶對地面氣象觀測數(shù)據(jù)的小時(shí)、日值需求不斷增加，對于超過10年以上的長時(shí)間序列、多站點(diǎn)和多氣象要素的查詢處理響應(yīng)支撐能力明顯不足，嚴(yán)重影響了此類數(shù)據(jù)服務(wù)業(yè)務(wù)的開展。

中國氣象局和北京市氣象信息中心使用HBase數(shù)據(jù)存儲(chǔ)架構(gòu)和相關(guān)大數(shù)據(jù)技術(shù)，將實(shí)時(shí)計(jì)算框架和分布式數(shù)據(jù)庫系統(tǒng)相結(jié)合，實(shí)現(xiàn)了海量自動(dòng)站分鐘數(shù)據(jù)快速入庫處理，各類要素查詢和統(tǒng)計(jì)處理均能達(dá)到毫秒級(jí)響應(yīng)，滿足了大規(guī)模自動(dòng)站分鐘數(shù)據(jù)在業(yè)務(wù)應(yīng)用中對存儲(chǔ)和查詢的性能需求。HBase 是一個(gè)高可靠性、高性能、面向列的分布式數(shù)據(jù)庫，適合處理實(shí)時(shí)隨機(jī)讀寫超大規(guī)模的數(shù)據(jù)，但是HBase表的設(shè)計(jì)模式和復(fù)雜的散列化使用方法，對于使用頻率集中在少數(shù)列、數(shù)據(jù)很少更新、格式固定的海量歷史數(shù)據(jù)，其存儲(chǔ)和管理的模式過于復(fù)雜，增加了設(shè)計(jì)和維護(hù)的難度，具有很大的改進(jìn)空間[4-7]。研究表明Hadoop大數(shù)據(jù)相關(guān)技術(shù)通過自定義格式構(gòu)建TXT大文本數(shù)據(jù)集，完成HDFS轉(zhuǎn)換存儲(chǔ)，在大數(shù)據(jù)環(huán)境下對于海量數(shù)據(jù)的查詢處理，Spark并行處理TXT大文本的方式明顯優(yōu)于CIMISS關(guān)系型數(shù)據(jù)庫處理的方式[8-9]。

本文在前期Hadoop相關(guān)大數(shù)據(jù)研究應(yīng)用的基礎(chǔ)上[8]，以歷史地面氣象記錄月報(bào)表為數(shù)據(jù)源，重新設(shè)計(jì)數(shù)據(jù)ETL流程，重構(gòu)基于Parquet列式的存儲(chǔ)特性的HDFS數(shù)據(jù)集，嵌入Spark的Broadcast廣播變量，優(yōu)化Spark并行度執(zhí)行參數(shù)，實(shí)現(xiàn)Hadoop集群各工作節(jié)點(diǎn)的物理資源利用率最大化，并提升SparkSql的關(guān)聯(lián)查詢效率。

1 業(yè)務(wù)系統(tǒng)現(xiàn)狀分析

目前CIMISS系統(tǒng)采用行式存儲(chǔ)的關(guān)系型數(shù)據(jù)庫架構(gòu)，以使用頻率最高的地面觀測小時(shí)值、日值數(shù)據(jù)庫表為例，其表字段有150～300個(gè)左右，存儲(chǔ)的站點(diǎn)數(shù)2900多個(gè)，累計(jì)數(shù)據(jù)量已達(dá)到億數(shù)量級(jí)。用戶在實(shí)際使用中查詢最多的是降水、溫度、風(fēng)、相對濕度等幾個(gè)常用要素列，數(shù)據(jù)庫每次運(yùn)行需要把一整行中所有列讀取后，再從中提取出目標(biāo)列，這種處理模式直接導(dǎo)致大數(shù)據(jù)量查詢效率低下，很多數(shù)據(jù)產(chǎn)品的統(tǒng)計(jì)處理只能通過二次處理去獲取。此外，數(shù)據(jù)缺失、數(shù)據(jù)異常的問題較嚴(yán)重，直接影響了月、年值的數(shù)據(jù)統(tǒng)計(jì)，由于關(guān)系型數(shù)據(jù)庫對于海量數(shù)據(jù)修改需要耗費(fèi)大量的人力和時(shí)間，導(dǎo)致此類數(shù)據(jù)的完整性、準(zhǔn)確性問題一直得不到很好的解決[10-11]。

2 Spark集群執(zhí)行參數(shù)優(yōu)化分析與設(shè)計(jì)

如何提高Spark的并行處理效率是本文首要研究的內(nèi)容。以本文的Hadoop集群為例，因?yàn)楸炯盒枰渲弥鞣?wù)器接收 Http 請求，需要固定的IP地址在應(yīng)用服務(wù)過程進(jìn)行交互、調(diào)試以及app的相關(guān)的輸出信息，所以Spark集群采用yarn-client運(yùn)行模式；如果采用 Yarn-Cluster 模式，Yarn 會(huì)隨機(jī)選擇一個(gè)NodeManager 啟動(dòng)Driver 端程序，服務(wù)器的IP地址將是隨機(jī)的，此外集群設(shè)計(jì)3個(gè)driver作為driver 端的負(fù)載均衡。圖1為yarn-client模式下Spark集群的執(zhí)行流程[12]。

Spark作業(yè)中各個(gè)stage的task數(shù)量代表了Spark作業(yè)在各個(gè)階段stage的并行度，合理設(shè)置并行度可以充分利用集群物理資源，使得每個(gè)task處理的數(shù)據(jù)量處于最優(yōu)值， 進(jìn)而提升運(yùn)行處理速度。

基于現(xiàn)有Hadoop集群的物理資源，如果Spark集群的處理并行度未能與之相匹配，不僅會(huì)造成資源的浪費(fèi)，也使得Spark集群整體處理效率未能達(dá)到最優(yōu)。

本文所描述的Hadoop的大數(shù)據(jù)集群包含兩種不同型號(hào)的8臺(tái)虛擬服務(wù)器，包括了1臺(tái)NameNode和7臺(tái)DataNode，表1已列出7臺(tái)DataNode的CPU的core總數(shù)和內(nèi)存總量。實(shí)際部署中每個(gè)節(jié)點(diǎn)需要預(yù)留資源給非Yarn部分的管理服務(wù)使用，比如NameNode在Spark應(yīng)用中需要做數(shù)據(jù)歸約操作，需要把各個(gè)節(jié)點(diǎn)上的數(shù)據(jù)聚合到客戶端，需要的JVM應(yīng)用的內(nèi)存較大，而Driver的內(nèi)存大小與jvm的內(nèi)存大小相關(guān)，在Yarn-client模式下Driver的內(nèi)存就是非Yarn所管理支配的內(nèi)存。在不影響系統(tǒng)以及其他應(yīng)用程序的正常運(yùn)行情況下，系統(tǒng)需要預(yù)留物理資源給系統(tǒng)以及其他應(yīng)用程序，所以本文約定給每個(gè)節(jié)點(diǎn)預(yù)留約20%～25%的內(nèi)存、2個(gè)CPU給非yarn部分的管理服務(wù)使用，例如對于16核CPU和32 GB內(nèi)存的服務(wù)器，集群只分配14個(gè)CPU和24 GB內(nèi)存給該節(jié)點(diǎn)供yarn管理調(diào)度使用。

表1 大數(shù)據(jù)集群資源配置清單

從表1可知，整個(gè)集群可利用的CPU資源為56+42=98個(gè)，內(nèi)存為96 GB+39 GB=135 GB，其中CPU 總個(gè)數(shù)影響Spark的Job 中的 Task 的并行度，CPU 越多可同時(shí)執(zhí)行的 Task 就越多，計(jì)算處理就越快；在內(nèi)存分配方面，內(nèi)存分配過小，會(huì)引起 Task 計(jì)算任務(wù)頻繁GC從而影響執(zhí)行效率甚至導(dǎo)致宕機(jī)，內(nèi)存分配過大，則會(huì)形成冗余浪費(fèi)。

整個(gè)Spark集群中設(shè)定的Executor進(jìn)程個(gè)數(shù)是與CPU和內(nèi)存的組合分配方案匹配的。因?yàn)镈ataNote 1～4的內(nèi)存和CPU比例為2∶1而DataNote 5～7的內(nèi)存和CPU比例是1∶1，整個(gè)集群物理機(jī)上的資源比例不一致，假設(shè)1個(gè)Executor進(jìn)程以1個(gè)CPU為基準(zhǔn)配置，如果Task 作業(yè)需要的內(nèi)存≤1 GB，那么每臺(tái)機(jī)器上的CPU可以完全利用，但會(huì)造成內(nèi)存浪費(fèi)，DataNode 1～4尤為嚴(yán)重；如果 Task 作業(yè)需要的內(nèi)存在1～2 GB之間，DataNode 1～4的CPU基本完全利用，DataNode 5～7的CPU和內(nèi)存會(huì)出現(xiàn)冗余；如果Task 需要的內(nèi)存>2 GB，那么全部節(jié)點(diǎn)的CPU和內(nèi)存都存在冗余，資源浪費(fèi)情況最嚴(yán)重。所以本集群從CPU或內(nèi)存資源利用率最大化的角度出發(fā)，得出的資源最優(yōu)配置方案如表2所示，此方案的Spark集群的executor配置為：2核心數(shù)+2900 M+384 M(堆外內(nèi)存)，方案可以將兩種型號(hào)服務(wù)器即DataNode 1～4的CPU、DataNode 5～7的內(nèi)存都分別利用完，使得executor個(gè)數(shù)與整體資源利用率達(dá)到最優(yōu)匹配。

表2 Spark計(jì)算資源分配方案

對于Spark處理過程中需要采集的文件分區(qū)數(shù)(partition)，本文分為加載數(shù)據(jù)和處理數(shù)據(jù)的兩個(gè)分區(qū)進(jìn)行描述，加載數(shù)據(jù)由HDFS進(jìn)行分區(qū)，每個(gè)block對應(yīng)一個(gè)分區(qū)，不同文件之間不能合并，例如對于日值數(shù)據(jù)而言，每次全站統(tǒng)計(jì)需要加載2700多個(gè)站的parquert文件，分區(qū)數(shù)為2700+，每個(gè)文件都是獨(dú)立加載提取數(shù)據(jù)并分別獲取結(jié)果；本文涉及的處理任務(wù)為數(shù)據(jù)基礎(chǔ)查詢，處理過程沒有涉及數(shù)據(jù)聚合操作，所以不會(huì)產(chǎn)生數(shù)據(jù)傾斜。本文設(shè)置Spark.default.Parallelism的task的參數(shù)值為300(之前使用Spark默認(rèn)設(shè)置的參數(shù)一般為幾十個(gè)task，task過少會(huì)導(dǎo)致資源的浪費(fèi)，不能最大限度發(fā)揮Spark集群的處理效率)，是CPU核心總數(shù)的2～3倍左右，一個(gè)job的task數(shù)等于分區(qū)數(shù)，所以本文的Spark的task總?cè)蝿?wù)數(shù)最大為2700+，實(shí)際任務(wù)數(shù)據(jù)會(huì)根據(jù)每個(gè)節(jié)點(diǎn)實(shí)際的Executor資源情況進(jìn)行重新分配，所以總?cè)蝿?wù)數(shù)會(huì)遠(yuǎn)小于2700。根據(jù)當(dāng)前Spark集群的配置方案，提交集群初始化命令行如下[12]：

MYMSpark_HOME/bin/Spark-submit

--master yarn

--executor-memory 2900M

--num-executors 40

--executor-cores 2

--driver-memory 4G

--conf Spark.default.parallelism=300

--conf Spark.storage.memoryFraction=0.6

--conf Spark.shuffle.memoryFraction=0.2

/home/applications/MeteoDataArchives/MeteoDataArchives.jar &

3 基于Parquet的數(shù)據(jù)ETL流程設(shè)計(jì)

Apache Parquet是Hadoop生態(tài)系統(tǒng)中常用的面向分析型業(yè)務(wù)的列式存儲(chǔ)格式，由Twitter和Cloudera合作開發(fā)，Spark處理框架默認(rèn)數(shù)據(jù)存儲(chǔ)格式為Parquet，所以兩者具有很好的兼容性。

根據(jù)用戶對CIMISS系統(tǒng)數(shù)據(jù)查詢的使用場景進(jìn)行分析，比如查詢多站點(diǎn)長時(shí)間序列日值，95%以上的查詢需求集中在日值表200多個(gè)字段中的降水、溫度、相對濕度等幾個(gè)字段，所以采用列式存儲(chǔ)是很好的存儲(chǔ)方式。為了提升數(shù)據(jù)的完整性、可用性，本文使用A文件(歷史地面氣象記錄月報(bào)表)作為數(shù)據(jù)源，該文件是經(jīng)過人工審核的數(shù)據(jù)文件(每個(gè)站每月一個(gè)A文件，包含了當(dāng)月70多個(gè)氣象要素的日統(tǒng)計(jì)值、20多個(gè)小時(shí)觀測值等數(shù)據(jù))，具有較高的準(zhǔn)確性和完整性，數(shù)據(jù)穩(wěn)定后續(xù)很少再做修改和刪除，規(guī)避了Parquet格式數(shù)據(jù)文件在更新、刪除操作上的劣勢。

以日值為例，本文對A文件所轄的77個(gè)日氣象統(tǒng)計(jì)要素，增加站號(hào)、時(shí)間2個(gè)字段共79個(gè)字段，以此作為Parquet文件的schema設(shè)計(jì)格式(表3)，此格式的79個(gè)字段雖然比CIMISS的日值表所包含的200多個(gè)字段少了一半，但其所涵蓋的主要?dú)庀蠼y(tǒng)計(jì)要素已能滿足日常95%以上的數(shù)據(jù)需求(小時(shí)值等應(yīng)用情況類似)。

表3 日值schema表字段格式說明

數(shù)據(jù)ETL(Extract-Load-Transform)處理是本文數(shù)據(jù)環(huán)境集成的第一步，目的是將A文件中的分散、零亂、標(biāo)準(zhǔn)不統(tǒng)一的數(shù)據(jù)按自定義格式整合到一起，也是構(gòu)建Parquet格式數(shù)據(jù)集的關(guān)鍵環(huán)節(jié)。同樣以日值數(shù)據(jù)為例，此過程是歸集本省全部站點(diǎn)建站至今所有A文件并按站點(diǎn)進(jìn)行歸類，按站點(diǎn)逐個(gè)文件對其中包含的77個(gè)氣象要素日值按日抽取后進(jìn)行數(shù)據(jù)初級(jí)質(zhì)控，剔除歷史錯(cuò)誤極值，對特殊字符進(jìn)行數(shù)字化轉(zhuǎn)換等，以保證后續(xù)列式數(shù)據(jù)的同質(zhì)性，完成77個(gè)要素的數(shù)據(jù)抽取清洗之后，將對應(yīng)站號(hào)、日期和77個(gè)要素日值按日逐行拼接，合并為長時(shí)間序列的行格式的大文本TXT文件(每個(gè)站點(diǎn)對應(yīng)一個(gè)日值合并文件)，以充分提高HDFS存儲(chǔ)塊的利用率(HDFS的存儲(chǔ)塊默認(rèn)大小為128 M)，最終轉(zhuǎn)換生成Parquet格式的列式數(shù)據(jù)文件并完成HDFS存儲(chǔ)轉(zhuǎn)換(存儲(chǔ)路徑通過文件夾和文件名區(qū)分)。上述的數(shù)據(jù)抽取、清洗、格式轉(zhuǎn)換和存儲(chǔ)處理流程就是本文的數(shù)據(jù)的ETL處理流程，因?yàn)镾park框架已對Parquet格式的讀寫轉(zhuǎn)換進(jìn)行了封裝，一般情況下采用默認(rèn)的參數(shù)設(shè)置就能完成Parquet格式文件的讀寫處理。圖2為日值數(shù)據(jù)的ETL處理流程[13-15]。

圖2 日值數(shù)據(jù)的ETL處理流程

經(jīng)過ETL處理后生成的Parquet文件是由一個(gè)header和一個(gè)或多個(gè)block塊組成，以一個(gè)footer結(jié)尾。header中只包含一個(gè)4個(gè)字節(jié)的魔術(shù)字“PAR1”用來識(shí)別整個(gè)Parquet文件格式，文件中所有的metadata(元數(shù)據(jù))都存在于footer中，footer中的metadata包含了格式的版本信息、schema信息、block中的metadata信息，footer中倒數(shù)第2個(gè)字段是一個(gè)以4個(gè)字節(jié)長度的footer的metadata，最后一個(gè)字段則是與header中包含一樣的“PAR1”。

Parquet文件中的每個(gè)block以Row Group的形式存儲(chǔ)，因此文件中的數(shù)據(jù)被劃分為一個(gè)或多個(gè)Row Group，這些Row Group是由一個(gè)或多個(gè)Column Chunks組成的列數(shù)據(jù)，每個(gè)Column Chunks的數(shù)據(jù)以Page的作為最小單元進(jìn)行組織，每個(gè)Page只包含特定列的值，因?yàn)榍拔脑跀?shù)據(jù)ETL過程中的數(shù)據(jù)清洗環(huán)節(jié)已將特殊字符經(jīng)過數(shù)字轉(zhuǎn)換，使得每個(gè)page保持了同質(zhì)性從而具有很好的壓縮特性。圖3為本文日值Parquet文件的Header、Data Block和Footer格式描述。

圖3 日值Parquet文件的Header、Data Block和Footer格式

表4是包含相同的數(shù)據(jù)內(nèi)容的TXT格式與Parquet格式的文件數(shù)據(jù)容量對比情況，通過對表4進(jìn)行分析發(fā)現(xiàn)，小時(shí)值的單個(gè)文件數(shù)據(jù)量最大，壓縮率也最大(超過95%)，說明單個(gè)文件數(shù)據(jù)量越大壓縮率就越大，證明Parquet格式的數(shù)據(jù)壓縮性能非常出色，可以為Hadoop集群節(jié)省大量的存儲(chǔ)空間，使用Parquet格式數(shù)據(jù)可以彌補(bǔ)Spark在數(shù)據(jù)壓縮處理上不足，對后續(xù)提升Spark的處理性能有很好的促進(jìn)作用。

表4 格式轉(zhuǎn)換前后存儲(chǔ)占用情況

4 SparkSql嵌入Broadcast處理流程設(shè)計(jì)

利用Parquet格式轉(zhuǎn)換提高了數(shù)據(jù)文件壓縮和存儲(chǔ)效率，Spark從1.6版本開始對操作Parquet進(jìn)行了優(yōu)化，提升了其掃描吞吐量，數(shù)據(jù)文件的查找速度提高了1倍以上，采用Parquet有利于Spark的調(diào)度和執(zhí)行。

由于在生成Parquet數(shù)據(jù)文件的ETL過程中并沒有將站名、經(jīng)度、緯度等臺(tái)站參數(shù)數(shù)據(jù)列寫入Parquet文件中，一是為了不增加要素列，二是因?yàn)檫@些參數(shù)信息會(huì)隨著臺(tái)站的遷移或臺(tái)站撤銷而發(fā)生變更，假如Parquet文件中寫入上述參數(shù)數(shù)據(jù)，在以經(jīng)緯度為例，如果某站點(diǎn)的經(jīng)緯度參數(shù)發(fā)生變更，則需要對Parquet文件中相應(yīng)列的數(shù)據(jù)進(jìn)行修改和數(shù)據(jù)集重構(gòu)，由于Parquet格式不支持實(shí)時(shí)大批量的數(shù)據(jù)刪除修改操作，所以在實(shí)際的數(shù)據(jù)查詢處理中，可以將所需的臺(tái)站參數(shù)數(shù)據(jù)和經(jīng)過Spark轉(zhuǎn)換后的DataFrame主表，通過站號(hào)進(jìn)行關(guān)聯(lián)查詢獲取最終結(jié)果。

之前的Spark集群在做關(guān)聯(lián)查詢時(shí)，task在處理過程中需要使用臨時(shí)變量(例如參與關(guān)聯(lián)查詢的臺(tái)站參數(shù)信息表)，因此每個(gè)task在處理過程中會(huì)拷貝一份臺(tái)站參數(shù)信息表作為副本，當(dāng)遇到大數(shù)據(jù)量查詢時(shí)會(huì)同時(shí)產(chǎn)生幾百個(gè)task，就需要同時(shí)拷貝幾百份副本，使得集群網(wǎng)絡(luò)IO開銷短時(shí)間內(nèi)劇增，導(dǎo)致集群的處理效率急劇下降。

因此，本文嵌入Spark的Broadcast廣播變量解決臺(tái)站參數(shù)的關(guān)聯(lián)查詢問題。Spark的Broadcast廣播變量是提前將一個(gè)輕量化的只讀變量(數(shù)據(jù)表或文本)緩存在集群每個(gè)節(jié)點(diǎn)的executor進(jìn)程中，避免在執(zhí)行查詢時(shí)才向所有task傳遞變量。本集群在Spark集群初始化時(shí)，通過Spark的Broadcast廣播變量預(yù)先將臺(tái)站參數(shù)數(shù)據(jù)拷貝到每個(gè)executor中，這部分?jǐn)?shù)據(jù)只占用executor中很小一部分的內(nèi)存，卻能有效減少后續(xù)關(guān)聯(lián)查詢處理時(shí)節(jié)點(diǎn)之間的數(shù)據(jù)交互和歸集操作，能將網(wǎng)絡(luò)IO開銷縮減7～8倍，從而提高查詢的處理效率。圖4為Spark-Broadcast關(guān)聯(lián)查詢處理流程[16]。

圖4 基于Parquet的Spark-Broadcast關(guān)聯(lián)查詢處理流程

Broadcast初始化部分代碼如下所示：

SparkSession SparkSession = SparkUtils.getSparkSession(); //獲取Spark會(huì)話

SparkConTXT SparkConTXT = SparkSession.SparkConTXT();

Dataset stationInfoRDD = SparkSession.read().format("jdbc") //加載mysql庫表到Spark中

.option("url"， dataUrl) //jdbc url

.option("user"， username) //數(shù)據(jù)庫用戶名

.option("password"， password) //數(shù)據(jù)庫密碼

.option("dbtable"， "station_info").load();//表名

Broadcast>broadcast=SparkConTXT.broadcast(stationInfoRDD， ClassTagMYM.MODULEMYM.apply(Dataset.class)); //將數(shù)據(jù)庫表廣播到Spark 的各個(gè)Executor中

Dataset sqlRDD = SparkSession.sql(sql); //Spark執(zhí)行SQL查詢將sql查詢結(jié)果和廣播變量(站點(diǎn)信息)關(guān)聯(lián)合并

Datasetjoin=sqlRDD.join(broadcast.getValue()， sqlRDD.col("Station_Id_C").equalTo(broadcast.getValue().col("station_code"))， "left");

Dataset resultRDD = join.drop(dropCol);//去除多余的列

5 測試結(jié)果

基于優(yōu)化后的Spark集群和嵌入Broadcast廣播變量后的SparkSql處理流程，本文將以客戶端查詢大數(shù)據(jù)量的響應(yīng)時(shí)效快慢為指標(biāo)，對Parquet與TXT兩種格式的處理響應(yīng)時(shí)效進(jìn)行比較，通過從客戶端觸發(fā)查詢事務(wù)，到全部查詢結(jié)果輸出轉(zhuǎn)換為可下載文本的全過程所耗費(fèi)的時(shí)間，可以直觀地對比出這兩種方式的處理效率。

從表5的測試結(jié)果可以看出，當(dāng)查詢站點(diǎn)數(shù)、總數(shù)據(jù)量以及查詢的目標(biāo)列數(shù)較少時(shí)，Parquet與TXT兩種格式查詢耗時(shí)區(qū)別很??；當(dāng)需要查詢的數(shù)據(jù)量呈倍增趨勢時(shí)，以日值查詢?yōu)槔琍arquet格式的查詢耗時(shí)比TXT格式縮減了1倍以上；對于小時(shí)值查詢，Parquet格式的查詢耗時(shí)比TXT格式縮減4～5倍，說明對于單個(gè)數(shù)據(jù)容量越大的文件，Parquet格式比TXT格式查詢效率提高更明顯。從每種格式的查詢耗時(shí)可以看出，Parquet格式的查詢耗時(shí)總體波動(dòng)很小，而TXT格式查詢耗時(shí)總體則波動(dòng)很大。

表5 Parquet與TXT格式查詢時(shí)效比對(建站至今)

從表6的并發(fā)查詢結(jié)果可以得知，Parquet格式在處理100用戶的并發(fā)情況下效率提升更加顯著，非常適用于海量數(shù)據(jù)的查詢處理，這是因?yàn)镻arquet格式文件的同列數(shù)據(jù)類型的同質(zhì)性使其擁有高效的壓縮編碼，所以在Spark解碼時(shí)可以快速跳過不符合條件的數(shù)據(jù)，有效減少冗余數(shù)據(jù)列，只讀取目標(biāo)列，提高了數(shù)據(jù)掃描和并行處理的效率。

表6 100用戶并發(fā)Parquet與TXT格式查詢時(shí)效比對

6 結(jié)論與討論

本文基于原有Hadoop大數(shù)據(jù)架構(gòu)，對Parquet列式存儲(chǔ)技術(shù)、Spark分布式集群的并行處理配置參數(shù)以及關(guān)聯(lián)查詢流程進(jìn)行深入研究與應(yīng)用，實(shí)現(xiàn)了對海量氣象數(shù)據(jù)的高效存儲(chǔ)、查詢和高并發(fā)訪問，彌補(bǔ)了 CIMISS支撐能力的不足。利用 Parquet格式構(gòu)建基于A文件的歷史地面觀測數(shù)據(jù)集，其高可用性可作為 CIMISS和天擎數(shù)據(jù)環(huán)境下此類數(shù)據(jù)的備份，為氣象業(yè)務(wù)提供更可靠的數(shù)據(jù)保障，對提升氣候預(yù)測、評價(jià)和可行性分析等傳統(tǒng)氣象業(yè)務(wù)的綜合應(yīng)用能力具有重要意義。Parquet格式實(shí)現(xiàn)代碼簡捷高效，特別適用于數(shù)據(jù)很少更新、處理時(shí)效要求不高的海量歷史數(shù)據(jù)如海量網(wǎng)站日志的分析處理等應(yīng)用場景，結(jié)合數(shù)據(jù)挖掘和人工智能技術(shù)，可衍生出更多的大數(shù)據(jù)處理模型。

在后續(xù)的工作中,將開展Spark即席查詢的研究與應(yīng)用，拓展更多的統(tǒng)計(jì)處理流程和發(fā)布更多數(shù)據(jù)產(chǎn)品的眾創(chuàng)接口，以滿足用戶更多的數(shù)據(jù)服務(wù)需求，取得更好的數(shù)據(jù)應(yīng)用效益。