彭 貝，劉黎志*，楊 敏，張晨躍

1.智能機(jī)器人湖北省重點(diǎn)實(shí)驗(yàn)室（武漢工程大學(xué)），湖北 武漢430205；

2.武漢工程大學(xué)計(jì)算機(jī)科學(xué)與工程學(xué)院，湖北 武漢430205

大數(shù)據(jù)技術(shù)對環(huán)境監(jiān)測數(shù)據(jù)分析和綜合決策具有重要意義。我國已建成涵蓋國家、省、市、縣4個(gè)層級的環(huán)境質(zhì)量自動監(jiān)測系統(tǒng)，建立了環(huán)境質(zhì)量實(shí)時(shí)發(fā)布系統(tǒng)［1］。根據(jù)全國“互聯(lián)網(wǎng)+監(jiān)管”系統(tǒng)建設(shè)的總體設(shè)計(jì)，在省級設(shè)立一個(gè)數(shù)據(jù)監(jiān)管中心，建立各類監(jiān)管數(shù)據(jù)庫?？h、市級環(huán)境監(jiān)測機(jī)構(gòu)負(fù)責(zé)編制轄區(qū)內(nèi)環(huán)境質(zhì)量報(bào)告，上報(bào)省環(huán)境監(jiān)測中心站。省環(huán)境監(jiān)測中心站匯總分析各地報(bào)告并編制全省環(huán)境質(zhì)量報(bào)告。因此，省級中心站收集了全省范圍內(nèi)各個(gè)自動化監(jiān)測站的數(shù)據(jù)，其中的空氣質(zhì)量監(jiān)測數(shù)據(jù)庫收集記錄了省內(nèi)各站點(diǎn)的SO2，NO2，PM10，CO，O3，PM2.5六類污染物的每小時(shí)監(jiān)測均值及相關(guān)氣象參數(shù)等數(shù)據(jù)［2-3］。隨著時(shí)間的推移，省級中心站存儲的數(shù)據(jù)量越來越大，形成了有著容量大、種類多、產(chǎn)生速度快、價(jià)值高、密度低等特征的大數(shù)據(jù)［4-5］。在對這些大數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析時(shí)，SQL Server等傳統(tǒng)關(guān)系數(shù)據(jù)庫會出現(xiàn)存儲空間不足、數(shù)據(jù)查詢耗時(shí)長等問題，而SQL Server上的分區(qū)視圖優(yōu)化技術(shù)也有其局限性，已無法滿足高效迅速處理這類數(shù)據(jù)的需求［6-7］。為了提高省級中心站數(shù)據(jù)處理速度，提升空氣質(zhì)量數(shù)據(jù)分析評價(jià)工作效率。本文基于Spark分布式集群環(huán)境和Hive數(shù)據(jù)倉庫，提出了一種多維度的分區(qū)存儲策略對省級中心站中的空氣質(zhì)量大數(shù)據(jù)查詢進(jìn)行了優(yōu)化。

1 大數(shù)據(jù)處理平臺

1.1 Spark與Hive

Spark是目前最受歡迎的分布式計(jì)算引擎之一，被廣泛應(yīng)用于大規(guī)模數(shù)據(jù)處理。由于其基于內(nèi)存計(jì)算的特點(diǎn)，Spark計(jì)算速度比同樣以MapReduce為核心的Hadoop要快很多倍。Spark是一個(gè)通用引擎，提供了Spark Core、Spark SQL、Mllib等組件庫可完成包括SQL查詢、文本處理、機(jī)器學(xué)習(xí)等各類運(yùn)算。且支持Java、R、Pathon等多種語言，可以訪問分布式文件系統(tǒng)（hadoop distributed file system，HDFS）、Hive、Hbase等多種數(shù)據(jù)源[8-10]。

Hive是基于Hadoop的分布式數(shù)據(jù)倉庫，用于以結(jié)構(gòu)化的形式管理存儲在HDFS中的數(shù)據(jù)，它提供了類似SQL的語句HiveQL來存儲、查詢、分析數(shù)據(jù)。Hive將用戶的HiveQL語句自動轉(zhuǎn)換為MapReduce任務(wù)執(zhí)行，簡化了用戶操作。Spark與Hive的結(jié)合具有處理數(shù)據(jù)規(guī)模大、速度快、可擴(kuò)展性強(qiáng)等優(yōu)勢[11-13]。

1.2 Spark SQL

Spark SQL是Spark中用于處理結(jié)構(gòu)化數(shù)據(jù)的子模塊。它將SQL查詢與Spark程序結(jié)合，使用戶可以在Spark程序中使用SQL查詢數(shù)據(jù)。它提供了DataFrames作為連接訪問多種數(shù)據(jù)源的統(tǒng)一方式，其數(shù)據(jù)源包括Hive、Avro、Parquet、Orc、Json和Jdbc[14]。其架構(gòu)如圖1所示。

圖1 Spark SQL架構(gòu)圖Fig.1 Schema diagram of Spark SQL

Spark SQL底層使用Spark Core作為執(zhí)行引擎，其本身由ANSI SQL解析器、DataFrame API和Catalyst優(yōu)化器組成，其中ANSI SQL解析器負(fù)責(zé)解析SQL語句。DataFrame對象是Spark SQL在彈性分布式數(shù)據(jù)集（resilient distributed dataset，RDD）的基礎(chǔ)上封裝而成的類似于數(shù)據(jù)表的數(shù)據(jù)結(jié)構(gòu)。Catalyst優(yōu)化器則是整個(gè)查詢過程的優(yōu)化引擎，配合解析器和DataFrame將關(guān)系查詢優(yōu)化解析為Spark可以運(yùn)行的作業(yè)［15］。Spark SQL提供了對關(guān)系數(shù)據(jù)處理的支持，同時(shí)支持內(nèi)部RDD數(shù)據(jù)和外部的多種數(shù)據(jù)源，也兼容Hive中的數(shù)據(jù)類型。還允許擴(kuò)展以支持更加復(fù)雜的分析算法，如機(jī)器學(xué)習(xí)、圖計(jì)算等。

2 數(shù)據(jù)分區(qū)優(yōu)化方法

2.1 SQL Server分區(qū)視圖

分區(qū)是對數(shù)據(jù)表的水平劃分，將大表拆分為多個(gè)小表，執(zhí)行查詢時(shí)通過排除不需要掃描的分區(qū)來提高查詢效率。SQL Server分區(qū)視圖允許根據(jù)某一列的值在邏輯上將大表中數(shù)據(jù)劃分為數(shù)值范圍較小的數(shù)據(jù)分區(qū)，并將這些分區(qū)數(shù)據(jù)存儲在參與分區(qū)的小表中。為此，需在所有參與的表中分區(qū)列上使用Check關(guān)鍵字定義約束，用以將表中的該列數(shù)值限定在一定的范圍，然后再使用UNION ALL運(yùn)算符將所有參與表中的數(shù)據(jù)查詢結(jié)果合并為一個(gè)分區(qū)視圖。執(zhí)行查詢時(shí)，Check約束用于指定哪個(gè)分區(qū)中包含需要的數(shù)據(jù)，從而跳過其它分區(qū)。每個(gè)參與分區(qū)的表都是獨(dú)立的，在不改變分區(qū)列的前提下可以單獨(dú)地添加和修改。

在SQL Server上創(chuàng)建分區(qū)視圖有其局限性。如：分區(qū)列不能是標(biāo)識列、默認(rèn)列、計(jì)算列和時(shí)間戳列。分區(qū)列必須為表的主屬性。分區(qū)列上只能有一個(gè)Check約束。只能對表中的一個(gè)列進(jìn)行分區(qū)，即分區(qū)屬性只能有一個(gè)。這些限制了分區(qū)視圖的性能。面對復(fù)雜的數(shù)據(jù)和復(fù)雜的查詢需求需對多個(gè)屬性列進(jìn)行分區(qū)的情況時(shí)，SQL Server分區(qū)視圖提供的性能優(yōu)化十分有限。

2.2 Hive數(shù)據(jù)分區(qū)

Hive上的數(shù)據(jù)分區(qū)也是一種對數(shù)據(jù)表的劃分，采用“分而治之”的策略來管理數(shù)據(jù)。但與SQL Server分區(qū)視圖不同的是Hive數(shù)據(jù)分區(qū)是基于分布式集群環(huán)境的，分區(qū)數(shù)據(jù)存在集群的各個(gè)節(jié)點(diǎn)上[16]。其分區(qū)屬性可以有多個(gè)，可以將數(shù)據(jù)表按照多個(gè)屬性列做多維度的劃分。如圖2所示，以空氣質(zhì)量數(shù)據(jù)為例，按照“地區(qū)”和“時(shí)間”兩個(gè)屬性列對其做數(shù)據(jù)分區(qū)。按地區(qū)劃分以后根據(jù)地區(qū)屬性的值劃分為多個(gè)分區(qū)，相同地區(qū)的數(shù)據(jù)在一個(gè)分區(qū)內(nèi)。每個(gè)地區(qū)分區(qū)內(nèi)再進(jìn)一步按時(shí)間劃分。根據(jù)實(shí)際需求還可以繼續(xù)按其他屬性分區(qū)。如此一來，分區(qū)的粒度更加精細(xì)，查詢時(shí)需掃描的分區(qū)更加明確，查詢時(shí)間自然會減少，而能被優(yōu)化的查詢種類也會增多。在分布式數(shù)據(jù)倉庫上的分區(qū)可以充分利用集群節(jié)點(diǎn)的特性，將分區(qū)存儲在各個(gè)節(jié)點(diǎn)上有利于查詢和存儲的負(fù)載均衡。

圖2 Hive數(shù)據(jù)分區(qū)示例Fig.2 Examples of Hive data partition

但是不恰當(dāng)?shù)臄?shù)據(jù)分區(qū)策略并不能提高查詢效率。Hive上的數(shù)據(jù)分區(qū)中每一個(gè)分區(qū)都對應(yīng)一個(gè)分布式文件系統(tǒng)上的文件目錄，若選擇的分區(qū)屬性上的值的種類過多，分區(qū)以后產(chǎn)生了過多的分區(qū)，會導(dǎo)致集群上的文件目錄過多，進(jìn)而增加了集群數(shù)據(jù)節(jié)點(diǎn)負(fù)擔(dān)。若分區(qū)以后，數(shù)據(jù)傾斜度太高，某個(gè)或某些分區(qū)上集中了大部分的數(shù)據(jù)，這樣的分區(qū)方法也不一定能提高查詢效率。因此需要充分了解集群環(huán)境和數(shù)據(jù)查詢特性，選擇恰當(dāng)?shù)姆謪^(qū)策略才能有效地提高查詢效率。

3 空氣質(zhì)量大數(shù)據(jù)分區(qū)優(yōu)化方法

空氣質(zhì)量監(jiān)測數(shù)據(jù)是環(huán)境監(jiān)測中十分重要的一部分，經(jīng)過日復(fù)一日地積累，其數(shù)據(jù)量已經(jīng)十分巨大。在利用SQL Server及其上的分區(qū)視圖技術(shù)對這些數(shù)據(jù)做統(tǒng)計(jì)分析時(shí)，查詢消耗的時(shí)間長，導(dǎo)致分析工作效率低下。為此，采用先將數(shù)據(jù)導(dǎo)入Spark集群，使用Spark SQL語句在Hive中進(jìn)行分區(qū)存儲，然后在Spark集群環(huán)境下進(jìn)行數(shù)據(jù)查詢、統(tǒng)計(jì)和分析的方法以提高效率。

3.1 空氣質(zhì)量監(jiān)測數(shù)據(jù)

省級環(huán)境監(jiān)測中心站中的空氣質(zhì)量數(shù)據(jù)庫收集了全省所有空氣自動監(jiān)測站點(diǎn)的監(jiān)測數(shù)據(jù)。庫中為每個(gè)站點(diǎn)建立了一張數(shù)據(jù)表。本文提出的方法用到的數(shù)據(jù)來源于湖北省環(huán)境監(jiān)測中心站中的空氣質(zhì)量SQL Server數(shù)據(jù)庫，庫中記錄每個(gè)站點(diǎn)監(jiān)測數(shù)據(jù)的表結(jié)構(gòu)如表1所示。其中站點(diǎn)編號用于區(qū)分不同的監(jiān)測站點(diǎn)，如：編號SS4201002表示湖北省(42)，武漢市(01)，漢陽月湖自動化監(jiān)測站(002)。污染物編號表示記錄的污染物類型，如：編號EP02表示記錄的是SO2。數(shù)據(jù)庫中記錄站點(diǎn)信息的數(shù)據(jù)表包含站點(diǎn)編號、所屬地區(qū)編號、地址、站點(diǎn)類型等信息。

表1監(jiān)測站數(shù)據(jù)記錄表結(jié)構(gòu)Tab.1 Recording table structure of monitoring station data

3.2 空氣質(zhì)量大數(shù)據(jù)分區(qū)策略

數(shù)據(jù)分區(qū)過程中，分區(qū)屬性的選擇將影響最終的優(yōu)化效果。根據(jù)實(shí)際的數(shù)據(jù)統(tǒng)計(jì)分析需求，對空氣質(zhì)量數(shù)據(jù)的查詢往往是以所監(jiān)測數(shù)據(jù)的時(shí)間、地區(qū)、監(jiān)測站點(diǎn)以及數(shù)據(jù)所屬的污染物種類等屬性為查詢條件。因此，選擇以查詢條件中出現(xiàn)頻率高的所屬地區(qū)、監(jiān)測站點(diǎn)、污染物種類、監(jiān)測年份4個(gè)屬性為分區(qū)屬性，在Hive中進(jìn)行多維度分區(qū)的策略。

該分區(qū)策略具體執(zhí)行方法如下：首先，在原始SQL Server數(shù)據(jù)庫中，利用各個(gè)站點(diǎn)監(jiān)測數(shù)據(jù)表中的監(jiān)測數(shù)據(jù)創(chuàng)建分區(qū)視圖。由于每張表中記錄同一站點(diǎn)的數(shù)據(jù)，站點(diǎn)編號字段已添加了約束。再使用UNION ALL操作符合并每張數(shù)據(jù)表的查詢結(jié)果構(gòu)成分區(qū)視圖All_Air_Data。創(chuàng)建該視圖時(shí)，查詢站點(diǎn)信息表中的地區(qū)編號作為視圖的地區(qū)編號字段，如4 201表示湖北武漢。提取數(shù)據(jù)記錄表中記錄時(shí)間的第1到4位作為視圖的年份字段，其它需要的站點(diǎn)編號、污染物編號、監(jiān)測時(shí)間、監(jiān)測值、監(jiān)測值單位、樣本數(shù)量、儀器工作狀態(tài)等字段直接從各個(gè)站點(diǎn)監(jiān)測數(shù)據(jù)表中查詢。創(chuàng)建分區(qū)視圖偽代碼如下：

然后，搭建Spark集群并配置能連接到集群的Eclipse開發(fā)環(huán)境。編寫Spark SQL程序?qū)⑸弦徊絼?chuàng)建好的總數(shù)據(jù)視圖All_Air_Data讀取到Spark集群中。此處調(diào)用Spark SQL的入口是SparkSession，導(dǎo)入數(shù)據(jù)具體實(shí)現(xiàn)的核心偽代碼如下：

最后，用SparkSession.enableHiveSupport方法打開Hive連接，用Spark SQL程序操作Hive將導(dǎo)入到集群的數(shù)據(jù)按照地區(qū)編號，站點(diǎn)編號，污染物編號，監(jiān)測年份的順序進(jìn)行四維分區(qū)并存入Hive中，其在Hive中存儲為airdb數(shù)據(jù)庫下的AirData表。Spark SQL中的分區(qū)代碼如下：

按上述方法完成空氣質(zhì)量大數(shù)據(jù)的分區(qū)存儲以后，Hive中的每一個(gè)分區(qū)會在集群的分布式文件系統(tǒng)上生成一個(gè)文件目錄。數(shù)據(jù)在集群上的文件存儲結(jié)構(gòu)如圖3所示。圖3中4級文件目錄對應(yīng)按4個(gè)屬性進(jìn)行的4次分區(qū)操作，最里層的“監(jiān)測數(shù)據(jù)文件”為實(shí)際的數(shù)據(jù)文件。

圖3數(shù)據(jù)分區(qū)存儲結(jié)構(gòu)Fig.3 Storage structure of data partitions

4 實(shí)驗(yàn)部分

為評估本文提出的查詢優(yōu)化方法的效果。設(shè)計(jì)了對比實(shí)驗(yàn)，使用兩臺相同配置的服務(wù)器，其中一臺使用SQL Server分區(qū)視圖方法實(shí)驗(yàn)。另一臺按照本文提出的方法進(jìn)行實(shí)驗(yàn)。實(shí)驗(yàn)思路為：設(shè)計(jì)能充分代表實(shí)際查詢需求的數(shù)據(jù)查詢集，將查詢集中每一個(gè)查詢同時(shí)在Hive和SQL Server兩種存儲方法上執(zhí)行，每個(gè)查詢執(zhí)行3次取查詢時(shí)間的平均值為實(shí)驗(yàn)結(jié)果。

4.1 實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)用的服務(wù)器為兩臺一樣的戴爾Power-Edge R720服務(wù)器配有兩臺英特爾E5-2620 V2物理CPU，每臺CPU有6個(gè)內(nèi)核，共12內(nèi)核，主頻2.10 GHz，內(nèi)存32 GB，硬盤8 TB，物理網(wǎng)卡4個(gè)。一臺安裝Windows Server 2008操作系統(tǒng)，SQL Server 2012數(shù)據(jù)庫管理系統(tǒng)。另一臺用VMWare Vsphere將其虛擬化為4個(gè)虛擬機(jī)，安裝Hadoop、Spark、Hive搭 建包 含1個(gè)Master節(jié) 點(diǎn)4個(gè)Worker節(jié)點(diǎn)(Master節(jié)點(diǎn)也是Worker節(jié)點(diǎn))的集群環(huán)境。集群單個(gè)節(jié)點(diǎn)的硬件配置和軟件版本如表2所示。

表2集群每個(gè)節(jié)點(diǎn)軟硬件版本Tab.2 Hardware and software versions of each node of cluster

4.2 查詢集

實(shí)驗(yàn)用的查詢集從簡單到復(fù)雜分為3類。第1類查詢限定查某一地區(qū)的某一站點(diǎn)的數(shù)據(jù)，第2類限定查某一地區(qū)內(nèi)的所有站點(diǎn)的數(shù)據(jù)，第3類無限定地查所有地區(qū)所有站點(diǎn)的數(shù)據(jù)。每一類查詢在該類的查詢限定條件下分別設(shè)計(jì)了4個(gè)查詢：1）查詢該類的限定條件下某污染物某一年的數(shù)值總和。2）查詢該類的限定條件下某污染物所有年份的數(shù)值總和。3）查詢該類的限定條件下所有污染物某一年的數(shù)值和。4）查詢該類的限定條件下所有污染物所有年份的數(shù)值和。

以上3類限定條件，每類4個(gè)查詢共12個(gè)查詢分別用SQL編寫在SQL Server上執(zhí)行，用Java在Eclipse上編寫再連接到集群在Hive上執(zhí)行。所查詢數(shù)據(jù)集的數(shù)據(jù)量分別有0.5億條、1億條、2億條、4億條4種。

4.3 結(jié)果分析

12條查詢在Hive和SQL Server上的不同的數(shù)據(jù)集上執(zhí)行時(shí)間如表3所示。由表3可以看出第1類查詢(Q1.1至Q1.4)在SQL Server上的執(zhí)行時(shí)間極短約為1～2 s，而在Hive上的執(zhí)行時(shí)間卻有10 s左右。究其原因，是因?yàn)檫@一類查詢在查詢條件中限定了地區(qū)和站點(diǎn)，由于在SQL Server上建立分區(qū)視圖是使用Check約束限定了每張數(shù)據(jù)表的站點(diǎn)編號，在SQL Server上執(zhí)行這一類查詢時(shí)查詢分析器只需找到所查站點(diǎn)的數(shù)據(jù)表并將其讀入內(nèi)存進(jìn)行計(jì)算即可。而在Hive上執(zhí)行，首先Spark集群有額外的建立線程、分配內(nèi)存及銷毀現(xiàn)場等操作，然后Hive需按照分區(qū)的層次，讀入計(jì)算所需要的數(shù)據(jù)文件到內(nèi)存后，才能進(jìn)行計(jì)算。這些集群環(huán)境的額外時(shí)間開銷使得基于Hive的方法在執(zhí)行限定了具體站點(diǎn)的查詢時(shí)耗時(shí)長。

表3 Hive和SQL Server在不同數(shù)據(jù)集上的查詢時(shí)間Tab.3 Query times of Hive and SQL Server on different datasets s

對于其它幾類查詢，查詢的限定條件少，查詢目標(biāo)不明確，查詢復(fù)雜度增加了。此時(shí)，由于Hive上多維分區(qū)的優(yōu)勢，使得在Hive上的查詢時(shí)間明顯少于在SQL Server上的。這時(shí)即使基于Hive的方法有集群環(huán)境的額外開銷也顯得微不足道，優(yōu)化效果明顯。如圖4所示的是數(shù)據(jù)量為4億條時(shí)本文提出方法的查詢的優(yōu)化效果。從圖中可見優(yōu)化效果最好的是查詢Q2.3,有96%的時(shí)間優(yōu)化，最低的Q3.4也有47%的查詢時(shí)間優(yōu)化。

縱向分析實(shí)驗(yàn)結(jié)果，使用Hive和SQL Server兩種方案在數(shù)據(jù)量為4億條的數(shù)據(jù)集上的查詢時(shí)間對比，如圖5所示。從查詢Q1.1到查詢Q3.4，隨著查詢復(fù)雜度增加，查詢用時(shí)都會增多，但是顯然在Hive中的查詢時(shí)間增長比在SQL Server中的時(shí)間增長要緩慢。圖5中值得注意的是在Q2.3和Q2.4處的SQL Server查詢時(shí)間有一個(gè)突起和突降。這是因?yàn)椴樵僎2.3、Q2.4是查詢某一地區(qū)內(nèi)所有站點(diǎn)里所有污染物某一年份和所有污染物所有年份的數(shù)據(jù)。在SQL Server上執(zhí)行這2個(gè)查詢時(shí)由于設(shè)備內(nèi)存的限制，導(dǎo)致需掃描的文件只有輪流從內(nèi)存中換入換出才能完成全部文件的掃描，這浪費(fèi)了大量的時(shí)間。而在Hive上執(zhí)行時(shí)則沒有這樣的限制，不僅查詢耗時(shí)少，而且時(shí)間變化也非常平滑。這也是Hive上分區(qū)優(yōu)化方法的優(yōu)點(diǎn)之一。

圖4 Hive對不同查詢的優(yōu)化效果Fig.4 Optimization effects of Hive for different queries

圖5查詢4億條數(shù)據(jù)Hive與SQL Server用時(shí)對比Fig.5 Comparison of query time about 400 million entries of Hive and SQL Server

橫向分析實(shí)驗(yàn)結(jié)果，如圖6（a）和（b）所示，分別為Q3.4和Q2.4在4種不同數(shù)據(jù)集上查詢時(shí)，Hive和SQL Server兩種方案的用時(shí)對比。對于同一個(gè)查詢，隨著查詢數(shù)據(jù)量的增加，查詢用時(shí)也增加了，但在Hive上增加的時(shí)間要少于在SQL Server上增加的時(shí)間。對于其它的查詢也是如此。

圖6（a）查詢Q3.4在不同數(shù)據(jù)集上的查詢用時(shí)，（b）查詢Q2.4在不同數(shù)據(jù)集上的查詢用時(shí)Fig.6（a）Query times of Q3.4 on different data sets，（b）Query times of Q2.4 on different data sets

總而言之，同一查詢在同一數(shù)據(jù)集上執(zhí)行時(shí)，本文提出的基于Hive的方法比SQL Server要快。而同一查詢在不同數(shù)據(jù)集上執(zhí)行時(shí)，基于Hive的方法上查詢時(shí)間的增長要比SQL Server上的時(shí)間增長慢。不同復(fù)雜度的查詢在同一數(shù)據(jù)集上執(zhí)行時(shí)，基于Hive的方法上查詢時(shí)間的增長要比SQL Server上的增長也要慢。

5 結(jié)論

在環(huán)境空氣質(zhì)量自動監(jiān)測系統(tǒng)中已產(chǎn)生海量數(shù)據(jù)給統(tǒng)計(jì)分析工作帶來困難的背景下，本文基于Spark集群提出了一種在Hive上分區(qū)存儲的查詢優(yōu)化方法，降低了空氣質(zhì)量大數(shù)據(jù)的查詢時(shí)間消耗。通過與SQL Server上的分區(qū)視圖查詢方法對比得出：本文提出的方法對空氣質(zhì)量監(jiān)測大數(shù)據(jù)的查詢時(shí)間有47%到96%的優(yōu)化作用。特別是當(dāng)查詢的限定條件越少、復(fù)雜度越高和查詢數(shù)據(jù)量越大時(shí)，本文方法的優(yōu)化作用越大。這一查詢時(shí)間的優(yōu)化將提升空氣質(zhì)量數(shù)據(jù)的分析和預(yù)警及預(yù)報(bào)工作的效率。