大數(shù)據(jù)統(tǒng)一SQL引擎研究與設(shè)計

丁巖　楊萬祥　汪清　楊樂　胡曉

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

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

中圖分類號： TP311.13 文獻標識碼： A文章編號： 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)用越來越成熟[1-4]，從工程或者技術(shù)的角度來看，大數(shù)據(jù)的核心是如何存儲[5]、分析、挖掘海量[6]的數(shù)據(jù)來解決實際的問題。對于一個工程師或者分析師來說，如何查詢和分析TB/PB級別的數(shù)據(jù)是在大數(shù)據(jù)時代不可回避的問題，所以基于大數(shù)據(jù)的SQL引擎成了大數(shù)據(jù)應(yīng)用的重要手段[7-8]。

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

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

1.1 背景介紹

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

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

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

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

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

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

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

2）對SQL語法的支持程度。

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

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

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

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

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

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

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

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

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

但是存在以下問題：

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

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

3）每次執(zhí)行Job都要啟動Task，花費很多時間，無法做到實時。

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

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

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

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

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

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

2.1 系統(tǒng)概述

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

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

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

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

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

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

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

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

5）集成以上幾項關(guān)鍵技術(shù)，研究開發(fā)一個大數(shù)據(jù)統(tǒng)一SQL引擎的軟件應(yīng)用系統(tǒng)，為了驗證該軟件應(yīng)用系統(tǒng)的有效性，以公安320項目中的現(xiàn)有數(shù)據(jù)為基礎(chǔ)進行驗證性開發(fā)，檢驗所研發(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語義，能查詢存儲在Hadoop的HDFS和HBase中的PB級大數(shù)據(jù)。已有的Hive系統(tǒng)雖然也提供了SQL語義，但由于Hive底層執(zhí)行使用的是MapReduce引擎，仍然是一個批處理過程，難以滿足查詢的交互性。相比之下，Impala的最大特點也是最大賣點就是它的快速。

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

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

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

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

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

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

（4）通過使用LLVM來統(tǒng)一編譯運行時代碼，避免了為支持通用編譯而帶來的不必要開銷。

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

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

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

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

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

2.3 實施與驗證

圖4 不同SQL引擎之間的性能對比

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對于同樣基于大數(shù)據(jù)存儲與計算平臺的SQL引擎來講，不同的SQL引擎性能指標也不相同，下面以Imapla和Phoenix為例進行說明，如圖4所示。

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

4 后續(xù)改進方向

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

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

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

【參考文獻】

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

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

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

[4]趙彥云，劉子燁.統(tǒng)計學要在大數(shù)據(jù)科學中扮演重要角色——ASA發(fā)布統(tǒng)計學科建設(shè)的發(fā)展報告[J].中國統(tǒng)計，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].中國科學院大學，2016.

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

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

[14]郭超，劉波，林偉偉.基于ImpaIa的大數(shù)據(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的碰撞比對分析[J].電視技術(shù)，2015，39（14）：94-98.

[17]佘楚玉，溫武少，肖揚，等.一種自適應(yīng)文件系統(tǒng)元數(shù)據(jù)服務(wù)負載均衡策略[J].軟件學報，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.