丁巖　楊萬(wàn)祥　汪清　楊樂(lè)　胡曉

【摘 要】大數(shù)據(jù)統(tǒng)一SQL引擎不管是從現(xiàn)實(shí)要求，還是從大數(shù)據(jù)應(yīng)用方面來(lái)講，都值得深入研究，目前大數(shù)據(jù)生態(tài)系統(tǒng)中的不同SQL引擎都有各自適合的應(yīng)用場(chǎng)景，性能指標(biāo)也不相同，很難選擇一種SQL引擎覆蓋所有的應(yīng)用需求。本文提出了大數(shù)據(jù)統(tǒng)一SQL引擎方案，集成多個(gè)SQL引擎，并提供統(tǒng)一的訪問(wèn)接口，用戶可以根據(jù)需要靈活選用相應(yīng)的SQL執(zhí)行引擎，解決傳統(tǒng)應(yīng)用如何快速移植到大數(shù)據(jù)平臺(tái)以及多個(gè)大數(shù)據(jù)SQL引擎選型難的問(wèn)題。

【關(guān)鍵詞】大數(shù)據(jù);統(tǒng)一SQL引擎;集成;訪問(wèn)接口

中圖分類號(hào)： TP311.13 文獻(xiàn)標(biāo)識(shí)碼： A文章編號(hào)： 2095-2457（2019）29-0001-004

DOI：10.19694/j.cnki.issn2095-2457.2019.29.001

Research and Design for Big Data SQL Engine

DING Yan1 YANG Wan-xiang1 WANG Qing2 YANG Le2 HU Xiao1

（1.Research Institute of Cloud Computing，Nanjing ZTE New Software Co.Ltd，

Nanjing Jiangsu 210012，China;

2.Information Center of Science and Technology，Nanjing City Public Security Bureau，

Nanjing Jiangsu 210012，China）

【Abstract】Unified SQL engine of big data is worthy to be explored in depth，whether from the practical requests， or from the big data application aspects.In the current big data ecosystem，different SQL engines have own application scenarios，their performance is also not the same，so it is difficult to choose one kind of SQL engines to cover all application requirements.This paper presents an unified scheme of SQL engine for big data，which integrates multiple kinds of SQL engines and provides unified access interfaces.It allows users choose the corresponding SQL engine flexibly，to solve the problem of how to quickly migrate traditional applications to big data platform and how to select the available SQL engine.

【Key words】Big data;SQL engine;Integrate;Access interface

0 引言

目前大數(shù)據(jù)技術(shù)發(fā)展及應(yīng)用越來(lái)越成熟[1-4]，從工程或者技術(shù)的角度來(lái)看，大數(shù)據(jù)的核心是如何存儲(chǔ)[5]、分析、挖掘海量[6]的數(shù)據(jù)來(lái)解決實(shí)際的問(wèn)題。對(duì)于一個(gè)工程師或者分析師來(lái)說(shuō)，如何查詢和分析TB/PB級(jí)別的數(shù)據(jù)是在大數(shù)據(jù)時(shí)代不可回避的問(wèn)題，所以基于大數(shù)據(jù)的SQL引擎成了大數(shù)據(jù)應(yīng)用的重要手段[7-8]。

但對(duì)于傳統(tǒng)的基于SQL實(shí)現(xiàn)的應(yīng)用如何快速移植到大數(shù)據(jù)平臺(tái)上來(lái)以及在現(xiàn)有的多個(gè)SQL引擎間如何進(jìn)行選型是個(gè)難題。

1 大數(shù)據(jù)統(tǒng)一SQL引擎相關(guān)技術(shù)研究

1.1 背景介紹

大數(shù)據(jù)可以說(shuō)無(wú)所不在，社交媒體、傳感設(shè)備、機(jī)器生成的信息、手持終端設(shè)備產(chǎn)生的信息等等，這些“新數(shù)據(jù)”有相當(dāng)一大部分都是非結(jié)構(gòu)化的，而且產(chǎn)生速度非常快，是大數(shù)據(jù)的一個(gè)重要部分。通過(guò)這些數(shù)據(jù)的分析，可以更加全面的了解用戶的心理、習(xí)慣、喜好等等，從而為提供更好的產(chǎn)品和服務(wù)。但是也不要忽略了，其實(shí)對(duì)于很多企業(yè)來(lái)說(shuō)，有一些傳統(tǒng)的關(guān)系型數(shù)據(jù)可能會(huì)是他們更加關(guān)心的。比如曾經(jīng)存儲(chǔ)在企業(yè)數(shù)據(jù)庫(kù)、商業(yè)智能應(yīng)用等中的歷史數(shù)據(jù)，企業(yè)為了保證在線平臺(tái)的實(shí)時(shí)查詢，不得不將這些數(shù)據(jù)導(dǎo)出來(lái)。但這些龐大的歷史數(shù)據(jù)中潛藏著巨大的價(jià)值，例如公安交警部門可以通過(guò)對(duì)車輛過(guò)車數(shù)據(jù)幾月、幾年的分析，從而分析出交通的擁堵情況、哪些線路需要優(yōu)化等等。這些數(shù)據(jù)雖然數(shù)據(jù)量龐大但是是關(guān)系型的，那么對(duì)于這類數(shù)據(jù)，自然的就會(huì)產(chǎn)生這樣一種需求：能不能利用已經(jīng)非常熟悉的 SQL 來(lái)對(duì)這種類型的大數(shù)據(jù)進(jìn)行分析？

或許有人會(huì)問(wèn)，MapReduce[9]不能夠做這樣的分析嗎？為什么需要再開發(fā)一種新的技術(shù)呢？原因有很多方面，但是最重要的原因有以下幾個(gè)方面：

1）與關(guān)系型數(shù)據(jù)庫(kù)技術(shù)相比，Hadoop 還比較年輕，那么對(duì)于 Hadoop 中的 MapReduce 技術(shù)掌握的開發(fā)人員相對(duì)來(lái)說(shuō)還是少數(shù)的。開發(fā)人員需要額外的花費(fèi)很多時(shí)間去學(xué)習(xí)這一新的技術(shù)框架，這不是很多人所愿意的。

2）如果去直接開發(fā) MapReduce 程序去做數(shù)據(jù)倉(cāng)庫(kù)里面操作，比如最常見的連接查詢，代碼量、性能調(diào)優(yōu)需要的精力等，都還是蠻大的。

3）提供大數(shù)據(jù)之上的 SQL 技術(shù)會(huì)吸引更多的人加入到大數(shù)據(jù)分析這個(gè)方向上來(lái)。因?yàn)?SQL 的語(yǔ)法大家已經(jīng)非常熟悉，這之上產(chǎn)品、工具、應(yīng)用也已經(jīng)有非常多，所以這是推動(dòng)大數(shù)據(jù)廣泛應(yīng)用很吸引人的一件事。

正是在這種需求下，現(xiàn)在市場(chǎng)上出現(xiàn)了大量的 Hadoop 之上的 SQL 產(chǎn)品，所有的這些產(chǎn)品基本都會(huì)去考慮以下幾個(gè)方面，這些也是衡量一個(gè)產(chǎn)品是否足夠強(qiáng)大的標(biāo)準(zhǔn)：

1）性能，查詢速度是否足夠快。

2）對(duì)SQL語(yǔ)法的支持程度。

因?yàn)閭鹘y(tǒng)的 SQL 是運(yùn)行在關(guān)系型數(shù)據(jù)庫(kù)中的表上的，表中是一條條的記錄。但是 Hadoop 之上的文件全部存儲(chǔ)在 HDFS 上，沒(méi)有真正的“表”的概念。 SQL 去運(yùn)行在這些 HDFS 文件上，并不是容易的事情，它需要在底層做很多工作，來(lái)完善對(duì) SQL 語(yǔ)法的支持。不光要簡(jiǎn)單的能夠運(yùn)行，還要對(duì)它進(jìn)行優(yōu)化，盡量讓查詢速度比較快。

3）企業(yè)級(jí)的特性。

比如安全性，是不是支持類似數(shù)據(jù)庫(kù)里面的行安全性、列安全性？比如跟企業(yè)其他信息系統(tǒng)的集成，是否支持標(biāo)準(zhǔn)的 JDBC/ODBC 接口等？

4）與 Hadoop 生態(tài)系統(tǒng)里面的其他組件的集成。

比如能不能直接訪問(wèn) Hbase里面的數(shù)據(jù)？數(shù)據(jù)能不能被類似于Pig這樣的高級(jí)MapReduce語(yǔ)言進(jìn)行查詢等等？

綜上，基于Hadoop系統(tǒng)的SQL引擎種類繁多，就會(huì)面臨應(yīng)用開發(fā)選型難等問(wèn)題。

1.2 現(xiàn)狀與優(yōu)缺點(diǎn)分析

目前業(yè)界使用最廣泛的大數(shù)據(jù)SQL引擎有Impala[7]、Hive[8]、Spark SQL[10]和Phoenix[11]等，下面分別進(jìn)行介紹。

Hive是目前處理大數(shù)據(jù)、構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)最常用的解決方案，甚至在很多公司部署了Hadoop集群不是為了跑原生MapReduce程序，而全用來(lái)跑Hive SQL的查詢?nèi)蝿?wù)。Hive是一個(gè)基于hadoop的開源數(shù)據(jù)倉(cāng)庫(kù)工具，采用HQL（類SQL）對(duì)數(shù)據(jù)進(jìn)行自動(dòng)化管理和處理。支持處理存儲(chǔ)在HBase上的數(shù)據(jù)，將HQL語(yǔ)句解析成MR任務(wù)運(yùn)行，獲取結(jié)果，適合于長(zhǎng)時(shí)間的批處理查詢分析[12]。

但是存在以下問(wèn)題：

1）data shuffle時(shí)的網(wǎng)絡(luò)瓶頸，Reduce要等Map結(jié)束才能開始，不能高效利用網(wǎng)絡(luò)帶寬。

2）一個(gè)SQL經(jīng)常會(huì)解析成多個(gè)job，輸出都直接寫HDFS，大量磁盤IO導(dǎo)致性能比較差。

3）每次執(zhí)行Job都要啟動(dòng)Task，花費(fèi)很多時(shí)間，無(wú)法做到實(shí)時(shí)。

Impala在HDFS或HBase上提供快速、交互式SQL查詢，使用與商用并行關(guān)系數(shù)據(jù)庫(kù)中類似的分布式查詢引擎，適合于實(shí)時(shí)交互式SQL查詢。Impala各個(gè)任務(wù)之間傳輸數(shù)據(jù)采用的是push的方式（MR采用的是pull的方式），也就是上游任務(wù)計(jì)算完就會(huì)push到下游，這樣能夠分散網(wǎng)絡(luò)壓力，提高job執(zhí)行效率，所以在性能上有大大地提高。但是在支持group by排序、非結(jié)構(gòu)化到結(jié)構(gòu)化的數(shù)據(jù)轉(zhuǎn)換、并行化以及表或者列級(jí)別的授權(quán)等安全問(wèn)題上存在較多問(wèn)題。

Spark SQL與傳統(tǒng) “DBMS查詢優(yōu)化器+執(zhí)行器”的架構(gòu)較為類似，只不過(guò)其執(zhí)行器是在分布式環(huán)境中實(shí)現(xiàn)的，并采用Spark作為執(zhí)行引擎 。與傳統(tǒng)方法的區(qū)別在于，SQL經(jīng)過(guò)查詢優(yōu)化器最終轉(zhuǎn)換為可執(zhí)行的查詢計(jì)劃是一個(gè)查詢樹 ，傳統(tǒng)DB可以執(zhí)行這個(gè)查詢計(jì)劃 ，而Spark SQL會(huì)在Spark內(nèi)將這棵執(zhí)行計(jì)劃樹轉(zhuǎn)換為有向無(wú)環(huán)圖 （DAG）再進(jìn)行執(zhí)行。中間輸出和結(jié)果保存在內(nèi)存中，所以具備較高的查詢性能。由于Spark SQL處理數(shù)據(jù)的原則是能放到內(nèi)存盡量放到內(nèi)存，優(yōu)點(diǎn)是做JOIN時(shí)會(huì)比較快，缺點(diǎn)是占用內(nèi)存太大，且自行管理內(nèi)存，占用內(nèi)存后不會(huì)釋放。

Phoenix是一個(gè)java中間層，可以在HBase上執(zhí)行SQL查詢。不像Hive那樣使用MR任務(wù)，而是直接使用HBase api進(jìn)行操作?；驹硎菍⒁粋€(gè)對(duì)于HBase client來(lái)說(shuō)比較復(fù)雜的查詢轉(zhuǎn)換成一系列Region Scan，結(jié)合coprocessor和custom? filter在多臺(tái)Region Server上進(jìn)行并行查詢，匯總各個(gè)Scan結(jié)果。優(yōu)點(diǎn)是相對(duì)于Hbase支持更多的數(shù)據(jù)類型、直接使用JDBC操作數(shù)據(jù)、支持二級(jí)索引等，但在JOIN支持上、大規(guī)模數(shù)據(jù)傳輸、計(jì)算邏輯復(fù)雜時(shí)的內(nèi)存占用上存在較多問(wèn)題。

由上面的分析可以看出，大數(shù)據(jù)生態(tài)系統(tǒng)中的不同SQL引擎都有各自適合的應(yīng)用場(chǎng)景，性能指標(biāo)也不相同，很難選擇一種SQL引擎覆蓋所有的應(yīng)用需求，為了解決上述問(wèn)題，本方案及系統(tǒng)提供統(tǒng)一的大數(shù)據(jù)SQL引擎，集成多個(gè)SQL引擎，并提供統(tǒng)一的訪問(wèn)接口，用戶可以根據(jù)需要靈活選用相應(yīng)的SQL執(zhí)行引擎。

圖1 Impala系統(tǒng)架構(gòu)

2 大數(shù)據(jù)統(tǒng)一SQL引擎

2.1 系統(tǒng)概述

本方案及系統(tǒng)的總體目標(biāo)是提供統(tǒng)一的大數(shù)據(jù)SQL引擎，集成多個(gè)SQL引擎，并提供統(tǒng)一的訪問(wèn)接口，用戶可以根據(jù)需要靈活選用相應(yīng)的SQL引擎，解決傳統(tǒng)應(yīng)用如何快速移植到大數(shù)據(jù)平臺(tái)以及多個(gè)大數(shù)據(jù)SQL引擎選型難的問(wèn)題。

項(xiàng)目主要研究的內(nèi)容包括：

1）面向警務(wù)云平臺(tái)中的各種大型應(yīng)用系統(tǒng)

通過(guò)SQL處理海量數(shù)據(jù)的共性需求，基于Hadoop的海量數(shù)據(jù)存儲(chǔ)和并行計(jì)算框架，研究和建立一個(gè)統(tǒng)一的大數(shù)據(jù)SQL引擎。

2）在綜合分析和抽象提煉各應(yīng)用系統(tǒng)在通過(guò)SQL方式處理分析海量數(shù)據(jù)的共性問(wèn)題的基礎(chǔ)上，面向警務(wù)云應(yīng)用的數(shù)據(jù)多樣性，建立一種統(tǒng)一SQL引擎，提供適應(yīng)于應(yīng)用系統(tǒng)中不同場(chǎng)景的SQL應(yīng)用需求。

3）為了解決基于SQL的海量數(shù)據(jù)分析查詢問(wèn)題，在總結(jié)各種應(yīng)用數(shù)據(jù)共性的基礎(chǔ)上，引入并集成了Hive、Impala、Spark SQL和Phoenix等大數(shù)據(jù)SQL引擎，并提供統(tǒng)一的SQL引擎接口，以便能應(yīng)用系統(tǒng)能根據(jù)需要靈活選擇合適的SQL引擎實(shí)現(xiàn)基于SQL的數(shù)據(jù)查詢與分析。

4）開發(fā)并研究SQL Agent技術(shù)，引入并集成多個(gè)SQL處理引擎，并能夠根據(jù)技術(shù)發(fā)展的趨勢(shì)動(dòng)態(tài)擴(kuò)展。對(duì)于適合于長(zhǎng)時(shí)間的批處理查詢與分析使用Hive;對(duì)于系統(tǒng)資源較為充足的應(yīng)用，實(shí)時(shí)交互式查詢可以采用Imapla;對(duì)于系統(tǒng)資源較為充足且join使用較多的應(yīng)用可以采用Spark SQL;對(duì)于在Hbase上使用SQL且使用到二級(jí)索引的場(chǎng)景采用Phoenix，通過(guò)SQL Agent技術(shù)將應(yīng)用相應(yīng)的SQL分析查詢請(qǐng)求轉(zhuǎn)發(fā)到相應(yīng)的SQL引擎進(jìn)行分析處理。。

圖2 統(tǒng)一SQL引擎架構(gòu)

5）集成以上幾項(xiàng)關(guān)鍵技術(shù)，研究開發(fā)一個(gè)大數(shù)據(jù)統(tǒng)一SQL引擎的軟件應(yīng)用系統(tǒng)，為了驗(yàn)證該軟件應(yīng)用系統(tǒng)的有效性，以公安320項(xiàng)目中的現(xiàn)有數(shù)據(jù)為基礎(chǔ)進(jìn)行驗(yàn)證性開發(fā)，檢驗(yàn)所研發(fā)系統(tǒng)的有效性。

2.2 關(guān)鍵技術(shù)

1）大數(shù)據(jù)SQL引擎技術(shù)

下面以Impala[13]為例介紹大數(shù)據(jù)SQL引擎技術(shù)。Impala系統(tǒng)架構(gòu)如圖1所示。

Impala提供SQL語(yǔ)義，能查詢存儲(chǔ)在Hadoop的HDFS和HBase中的PB級(jí)大數(shù)據(jù)。已有的Hive系統(tǒng)雖然也提供了SQL語(yǔ)義，但由于Hive底層執(zhí)行使用的是MapReduce引擎，仍然是一個(gè)批處理過(guò)程，難以滿足查詢的交互性。相比之下，Impala的最大特點(diǎn)也是最大賣點(diǎn)就是它的快速。

Impala使用的列存儲(chǔ)格式是Parquet，未來(lái)還將支持 Hive并添加字典編碼、游程編碼等功能。Impala使用了Hive的SQL接口（包括SELECT、 INSERT、Join等操作），但目前只實(shí)現(xiàn)了Hive的SQL語(yǔ)義的子集，表的元數(shù)據(jù)信息存儲(chǔ)在Hive的 Metastore中。StateStore是Impala的一個(gè)子服務(wù)，用來(lái)監(jiān)控集群中各個(gè)節(jié)點(diǎn)的健康狀況，提供節(jié)點(diǎn)注冊(cè)、錯(cuò)誤檢測(cè)等功能。 Impala在每個(gè)節(jié)點(diǎn)運(yùn)行了一個(gè)后臺(tái)服務(wù)Impalad，Impalad用來(lái)響應(yīng)外部請(qǐng)求，并完成實(shí)際的查詢處理。Impalad主要包含Query Planner、Query Coordinator和Query Exec Engine三個(gè)模塊。QueryPalnner接收來(lái)自SQL APP和ODBC的查詢，然后將查詢轉(zhuǎn)換為許多子查詢，Query Coordinator將這些子查詢分發(fā)到各個(gè)節(jié)點(diǎn)上，由各個(gè)節(jié)點(diǎn)上的Query Exec Engine負(fù)責(zé)子查詢的執(zhí)行，最后返回子查詢的結(jié)果，這些中間結(jié)果經(jīng)過(guò)聚集之后最終返回給用戶。

在實(shí)際測(cè)試中發(fā)現(xiàn)，Impala的查詢效率比Hive有數(shù)量級(jí)的提升[14]。從技術(shù)角度上來(lái)看，Impala之所以能有好的性能，主要有以下幾方面的原因[15-16]。

（1）Impala不需要把中間結(jié)果寫入磁盤，省掉了大量的I/O開銷。

圖3 傳統(tǒng)數(shù)據(jù)庫(kù)與Impala性能對(duì)比

（2）省掉了MapReduce作業(yè)啟動(dòng)的開銷。MapReduce啟動(dòng)task的速度很慢（默認(rèn)每個(gè)心跳間隔是3秒鐘），Impala直接通過(guò)相應(yīng)的服務(wù)進(jìn)程來(lái)進(jìn)行作業(yè)調(diào)度，速度快了很多。

（3）Impala完全拋棄了MapReduce這個(gè)不太適合做SQL查詢的范式，而是像Dremel一樣借鑒了MPP并行數(shù)據(jù)庫(kù)的思想另起爐灶，因此可做更多的查詢優(yōu)化，從而省掉不必要的shuffle、sort等開銷。

（4）通過(guò)使用LLVM來(lái)統(tǒng)一編譯運(yùn)行時(shí)代碼，避免了為支持通用編譯而帶來(lái)的不必要開銷。

（5）用C++實(shí)現(xiàn)，做了很多有針對(duì)性的硬件優(yōu)化，例如使用SSE指令。

（6）使用了支持Data locality的I/O調(diào)度機(jī)制，盡可能地將數(shù)據(jù)和計(jì)算分配在同一臺(tái)機(jī)器上進(jìn)行，減少了網(wǎng)絡(luò)開銷。

2）大數(shù)據(jù)統(tǒng)一SQL引擎技術(shù)

大數(shù)據(jù)統(tǒng)一SQL引擎提供統(tǒng)一的數(shù)據(jù)服務(wù)，業(yè)務(wù)訪問(wèn)大數(shù)據(jù)，均通過(guò)SQL Agent接入提供統(tǒng)一SQL服務(wù)，通過(guò)元數(shù)據(jù)服務(wù)，提供數(shù)據(jù)路由，如圖2所示。

基于SQL Agent的統(tǒng)一SQL服務(wù)引擎，通過(guò)引入并集成多個(gè)SQL處理引擎實(shí)現(xiàn)，并能夠根據(jù)技術(shù)發(fā)展的趨勢(shì)動(dòng)態(tài)擴(kuò)展。對(duì)于適合于長(zhǎng)時(shí)間的批處理查詢與分析使用Hive;對(duì)于系統(tǒng)資源較為充足的應(yīng)用，實(shí)時(shí)交互式查詢可以采用Imapla;對(duì)于系統(tǒng)資源較為充足且join使用較多的應(yīng)用可以采用Spark SQL;對(duì)于在Hbase上使用SQL且使用到二級(jí)索引的場(chǎng)景采用Phoenix，通過(guò)SQL Agent技術(shù)將應(yīng)用相應(yīng)的SQL分析查詢請(qǐng)求轉(zhuǎn)發(fā)到相應(yīng)的SQL引擎進(jìn)行分析處理。

2.3 實(shí)施與驗(yàn)證

圖4 不同SQL引擎之間的性能對(duì)比

本方案與系統(tǒng)是在大數(shù)據(jù)統(tǒng)一SQL處理基礎(chǔ)理論和技術(shù)方法研究的基礎(chǔ)上，從現(xiàn)有的大數(shù)據(jù)SQL引擎系統(tǒng)入手，結(jié)合警務(wù)云海量數(shù)據(jù)的特點(diǎn)和技術(shù)問(wèn)題，研究建立適用于警務(wù)云處理海量數(shù)據(jù)的SQL引擎的架構(gòu)和模型，并研究解決一系列關(guān)鍵性技術(shù)方法，最后設(shè)計(jì)實(shí)現(xiàn)整個(gè)大數(shù)據(jù)統(tǒng)一SQL引擎系統(tǒng)。

整個(gè)系統(tǒng)在具體實(shí)施時(shí)主要分為以下幾步：

1）大數(shù)據(jù)統(tǒng)一SQL引擎設(shè)計(jì)

在分析Hadoop生態(tài)圈現(xiàn)有常見的SQL引擎的的基礎(chǔ)上，設(shè)計(jì)實(shí)現(xiàn)SQL Agent，做好元數(shù)據(jù)服務(wù)的統(tǒng)一管理。

通過(guò)SQL Agent技術(shù)將應(yīng)用相應(yīng)的SQL分析查詢請(qǐng)求轉(zhuǎn)發(fā)到相應(yīng)的SQL引擎進(jìn)行分析處理，并進(jìn)行基本的對(duì)比和分析驗(yàn)證;

2）大數(shù)據(jù)統(tǒng)一SQL引擎設(shè)計(jì)與實(shí)現(xiàn)

研究設(shè)計(jì)基于Hive、Impala、Spark SQL和Phoenix的SQL Agent系統(tǒng)，應(yīng)用在使用SQL進(jìn)行分析查詢時(shí)，直接與SQL Agent進(jìn)行交互處理，由SQL Agent判斷并選擇合適的SQL引擎進(jìn)行執(zhí)行，并將正確的結(jié)果返回給應(yīng)用系統(tǒng)。

3）大數(shù)據(jù)統(tǒng)一SQL引擎的優(yōu)化

針對(duì)應(yīng)用在調(diào)用大數(shù)據(jù)統(tǒng)一SQL引擎的過(guò)程進(jìn)行跟蹤統(tǒng)計(jì)，盡可能的獲取各個(gè)SQL執(zhí)行引擎的性能數(shù)據(jù)并進(jìn)行對(duì)比分析，以便在后續(xù)使用時(shí)進(jìn)行合理的調(diào)度分配，大大提高系統(tǒng)的易用性。

4）原型系統(tǒng)開發(fā)與應(yīng)用驗(yàn)證

在上述關(guān)鍵技術(shù)研究實(shí)現(xiàn)的基礎(chǔ)上，實(shí)現(xiàn)大數(shù)據(jù)統(tǒng)一SQL引擎系統(tǒng)，同時(shí)為了驗(yàn)證和改進(jìn)該軟件框架和平臺(tái)，選擇320項(xiàng)目原始的監(jiān)控點(diǎn)位數(shù)據(jù)、實(shí)時(shí)過(guò)車信息數(shù)據(jù)進(jìn)行實(shí)際的驗(yàn)證。

3 應(yīng)用成效與推廣價(jià)值

本方案與系統(tǒng)實(shí)現(xiàn)了大數(shù)據(jù)統(tǒng)一SQL引擎的設(shè)計(jì)，主要完成了以下幾方面的工作。

1）從大數(shù)據(jù)SQL引擎的業(yè)務(wù)需求著手，收集并整理大數(shù)據(jù)SQL引擎相關(guān)技術(shù)和實(shí)現(xiàn)要求;

2）為實(shí)現(xiàn)該系統(tǒng)，難點(diǎn)在于大數(shù)據(jù)SQL引擎方案設(shè)計(jì)、統(tǒng)一SQL引擎設(shè)計(jì)等問(wèn)題，通過(guò)統(tǒng)一SQL引擎元數(shù)據(jù)管理，采用SQL Agent解決大數(shù)據(jù)不同SQL引擎接入的問(wèn)題;

3）完成了大數(shù)據(jù)統(tǒng)一SQL引擎的整體解決方案設(shè)計(jì)，最終實(shí)現(xiàn)整個(gè)系統(tǒng)的實(shí)施與驗(yàn)證。

下面以實(shí)際的數(shù)據(jù)進(jìn)行說(shuō)明，數(shù)據(jù)量以萬(wàn)為單位，縱坐標(biāo)代表響應(yīng)時(shí)間，以查詢操作為例，統(tǒng)一SQL使用Impala的結(jié)果如圖3所示，可見隨著數(shù)據(jù)量的增大，傳統(tǒng)數(shù)據(jù)庫(kù)的查詢性能顯著降低，當(dāng)達(dá)到億級(jí)數(shù)據(jù)時(shí)系統(tǒng)幾乎不可用。

對(duì)于同樣基于大數(shù)據(jù)存儲(chǔ)與計(jì)算平臺(tái)的SQL引擎來(lái)講，不同的SQL引擎性能指標(biāo)也不相同，下面以Imapla和Phoenix為例進(jìn)行說(shuō)明，如圖4所示。

大數(shù)據(jù)統(tǒng)一SQL引擎不管是從現(xiàn)實(shí)要求，還是從大數(shù)據(jù)應(yīng)用方面來(lái)講，都值得深入研究，目前大數(shù)據(jù)生態(tài)系統(tǒng)中的不同SQL引擎都有各自適合的應(yīng)用場(chǎng)景，性能指標(biāo)也不相同，很難選擇一種SQL引擎覆蓋所有的應(yīng)用需求。本方案及系統(tǒng)提供統(tǒng)一的大數(shù)據(jù)SQL引擎，集成多個(gè)SQL引擎，并提供統(tǒng)一的訪問(wèn)接口，用戶可以根據(jù)需要靈活選用相應(yīng)的SQL執(zhí)行引擎，解決傳統(tǒng)應(yīng)用如何快速移植到大數(shù)據(jù)平臺(tái)以及多個(gè)大數(shù)據(jù)SQL引擎選型難的問(wèn)題。

4 后續(xù)改進(jìn)方向

大數(shù)據(jù)統(tǒng)一SQL引擎系統(tǒng)后續(xù)會(huì)在如下方向進(jìn)行改進(jìn)：

1）不同的SQL引擎都有各自的元數(shù)據(jù)管理方案，完全兼容比較困難，需要改造、適配[17]。

2）不同的SQL引擎支持的SQL語(yǔ)法不盡相同，同樣的SQL語(yǔ)句在有的SQL引擎上可以執(zhí)行，在另外的SQL引擎上可能沒(méi)法執(zhí)行，需要SQL Agent進(jìn)行適配[18]。

【參考文獻(xiàn)】

[1]梁吉業(yè)，馮晨嬌，宋鵬.大數(shù)據(jù)相關(guān)分析綜述[J].計(jì)算機(jī)學(xué)報(bào)，2016（1）：1-18.

[2]王元卓，靳小龍，程學(xué)旗.網(wǎng)絡(luò)大數(shù)據(jù)：現(xiàn)狀與展望[J].計(jì)算機(jī)學(xué)報(bào)，2013，36（6）：1125-1138.

[3]邁爾-舍恩伯格，庫(kù)克耶，盛楊燕，周濤.大數(shù)據(jù)時(shí)代：生活、工作與思維的大變革[M].浙江人民出版社，2013.

[4]趙彥云，劉子燁.統(tǒng)計(jì)學(xué)要在大數(shù)據(jù)科學(xué)中扮演重要角色——ASA發(fā)布統(tǒng)計(jì)學(xué)科建設(shè)的發(fā)展報(bào)告[J].中國(guó)統(tǒng)計(jì)，2015（12）：4-5.

[5]Aisha，SIDDIQA，Ahmad，et al.Big data storage technologies：a survey[J].信息與電子工程前沿：英文版，2017（8）：1040-1070.

[6]Sowmya R，Suneetha K R.Data Mining with Big Data[C]. International Conference on Intelligent Systems and Control. IEEE，2017：246-250.

[7]Kornacker M，Behm A，Bittorf V，et al.Impala：A Modern， Open-Source SQL Engine for Hadoop.[C].conference on innovative data systems research，2015.

[8]Thusoo A，Sarma J S，Jain N，et al.Hive：a warehousing solution over a map-reduce framework[J].very large data bases， 2009，2（2）：1626-1629.

[9]Dean J，Ghemawat S.MapReduce：simplified data processing on large clusters[J].Communications of The ACM，2008，51（1）：107-113.

[10]Armbrust M，Xin R S，Lian C，et al.Spark SQL： Relational Data Processing in Spark[C].international conference on management of data， 2015： 1383-1394.

[11]歐陳庚.基于HBase的復(fù)雜關(guān)聯(lián)查詢技術(shù)研究[D].中國(guó)科學(xué)院大學(xué)，2016.

[12]宋杰，郭朝鵬，王智，等.大數(shù)據(jù)分析的分布式MOLAP技術(shù)[J].軟件學(xué)報(bào)，2014， 25（4）：731-752.

[13]賈傳青.開源大數(shù)據(jù)分析引擎Impala實(shí)戰(zhàn)[M].清華大學(xué)出版社，2015.

[14]郭超，劉波，林偉偉.基于ImpaIa的大數(shù)據(jù)查詢分析計(jì)算性能研究[J].計(jì)算機(jī)應(yīng)用研究，2015（5）：1330-1334.

[15]Li X，Zhou W.Performance Comparison of Hive，Impala and Spark SQL[C].International Conference on Intelligent Human-Machine Systems and Cybernetics.IEEE Computer Society，2015：418-423.

[16]王艷，潘晨光.基于HDFS和IMPALA的碰撞比對(duì)分析[J].電視技術(shù)，2015，39（14）：94-98.

[17]佘楚玉，溫武少，肖揚(yáng)，等.一種自適應(yīng)文件系統(tǒng)元數(shù)據(jù)服務(wù)負(fù)載均衡策略[J].軟件學(xué)報(bào)，2017，28（8）：1952-1967.

[18]Lu X，Su F，Liu H，et al.A unified OLAP/OLTP big data processing framework in telecom industry[C].International Symposium on Communications and Information Technologies.IEEE，2016：290-295.