一種基于HiveSQL的增加任務(wù)并行度與建立中間表組合的優(yōu)化查詢方法

鄭靈逸，李擎

（1.北京信息科技大學(xué)自動(dòng)化學(xué)院，北京 100192；2.高動(dòng)態(tài)導(dǎo)航技術(shù)北京市重點(diǎn)實(shí)驗(yàn)室，北京 100192）

0 引言

在如今的大數(shù)據(jù)時(shí)代［1］，大數(shù)據(jù)的處理和查詢?cè)絹碓匠蔀檠芯康闹攸c(diǎn)和技術(shù)攻克的難關(guān)，其中主要的問題在于數(shù)據(jù)量級(jí)龐大并且數(shù)據(jù)每日更新，一方面很難對(duì)如此大量的數(shù)據(jù)做到有效的管理，另一方面也很難從數(shù)據(jù)量為Pb［2］的數(shù)據(jù)中得到所需要的數(shù)據(jù)。MySql 作為一種最流行的關(guān)系型數(shù)據(jù)庫(kù)，它有著查詢效率高、數(shù)據(jù)準(zhǔn)確且無數(shù)據(jù)重復(fù)的特點(diǎn)，在數(shù)據(jù)量為Gb的數(shù)據(jù)處理場(chǎng)景當(dāng)中被廣泛使用。然而，在大數(shù)據(jù)處理場(chǎng)景之下［3］，MySql存在明顯的缺點(diǎn)，MySql在使用大量存儲(chǔ)過程中每個(gè)連接的內(nèi)存使用量將會(huì)大大增加，由于MySql 不允許調(diào)試存儲(chǔ)的特點(diǎn)，使得開發(fā)和維護(hù)存儲(chǔ)過程都較為困難。為了能夠更好存儲(chǔ)和處理Pb 級(jí)別的數(shù)據(jù)量，從大數(shù)據(jù)應(yīng)用場(chǎng)景下提取所需要的數(shù)據(jù)，許多學(xué)者將Hadoop生態(tài)系統(tǒng)下的Hive數(shù)據(jù)庫(kù)作為大數(shù)據(jù)場(chǎng)景下的存儲(chǔ)和處理工具，并將SQL 作為Hive的查詢工具。Hadoop 是一個(gè)開發(fā)和運(yùn)行處理大數(shù)據(jù)的軟件平臺(tái)，是Apache 的一個(gè)用Java 語(yǔ)言實(shí)現(xiàn)的開源軟件框架，實(shí)現(xiàn)通過大量計(jì)算機(jī)組成的集群對(duì)海量數(shù)據(jù)進(jìn)行分布式計(jì)算。Hadoop 的核心是HDFS［4］、MapReduce 和YARN，這使得它具有可靠、高效、可伸縮的特點(diǎn)［5］。Hive是基于Hadoop的一個(gè)數(shù)據(jù)倉(cāng)庫(kù)工具，用來進(jìn)行數(shù)據(jù)提取、轉(zhuǎn)化、加載，是一種可以存儲(chǔ)、查詢和分析存儲(chǔ)在Hadoop 中的大規(guī)模數(shù)據(jù)的工具。Hive 數(shù)據(jù)庫(kù)由于其具有提供類SQL 查詢語(yǔ)言HQL［6］、為超大數(shù)據(jù)集設(shè)計(jì)了計(jì)算和擴(kuò)展能力［7］以及提供統(tǒng)一的元數(shù)據(jù)管理等優(yōu)點(diǎn)，是其他大數(shù)據(jù)處理技術(shù)無法比擬的。其工作原理是把編寫的SQL 語(yǔ)句進(jìn)行解析，翻譯成MapReduce 代碼，然后在Hadoop 上執(zhí)行［8］。因此，可以使用Hive 解決大數(shù)據(jù)場(chǎng)景下數(shù)據(jù)存儲(chǔ)、處理和查詢的問題。

一些學(xué)者發(fā)現(xiàn)在Hadoop平臺(tái)上用Hive處理大數(shù)據(jù)時(shí)，在數(shù)據(jù)量超過Pb并且SQL查詢語(yǔ)句冗長(zhǎng)同時(shí)所需要的指標(biāo)查詢過多［9］的情況下，仍然會(huì)出現(xiàn)數(shù)據(jù)處理查詢時(shí)間過長(zhǎng)的問題。針對(duì)這一現(xiàn)象，馬鐵［10］提出了一種專為大規(guī)模數(shù)據(jù)處理而設(shè)計(jì)的快速通用的計(jì)算引擎Spark，不同于Hadoop MapReduce的是在Spark當(dāng)中任務(wù)的中間輸出結(jié)果可以保存在內(nèi)存當(dāng)中［11］，由于這一特性，Spark在大數(shù)據(jù)場(chǎng)景下表現(xiàn)出來具有更快更高效的特性。但是Spark 本身沒有自己的存儲(chǔ)與Meta 庫(kù)兩種最核心的東西，需要依賴HDFS 和Hive 的相關(guān)功能［12］，雖然SparkSQL 是非常具有潛力的，但目前來說仍然是以Hive Meta 庫(kù)作為元數(shù)據(jù)管理HDFS 作為數(shù)據(jù)存儲(chǔ)，并且Spark 本身的SQL 解析器不如Hive 同時(shí)由于Spark 是基于內(nèi)存的特性導(dǎo)致建立在Spark 之上的大數(shù)據(jù)計(jì)算集群的成本會(huì)大大增加［13］，因此從考慮成本和性能穩(wěn)定性的角度出發(fā)，Spark仍然有許多不足之處。由于在大數(shù)據(jù)處理和查詢時(shí)小文件會(huì)造成資源的多度占用以及影響查詢效率，有的學(xué)者提出采用Sequence?File 作為表存儲(chǔ)格式，而不用TextFile，在一定程度上可以減少小文件的個(gè)數(shù)，有的學(xué)者也提出采用JVM重用機(jī)制，該方式是Hadoop中調(diào)優(yōu)參數(shù)的內(nèi)容，對(duì)于小文件特別多的場(chǎng)景或者Task 特別多的場(chǎng)景這種調(diào)優(yōu)方式對(duì)Hive 的性能有很大的幫助，在這類場(chǎng)景下的大數(shù)據(jù)執(zhí)行時(shí)間都很短。但不管是SequenceFile 方法還是JVM 重用機(jī)制都只是針對(duì)小文件過多場(chǎng)景下的優(yōu)化方法，對(duì)于多數(shù)情況下的大數(shù)據(jù)處理問題仍然是在數(shù)據(jù)量極大且所需要提取出的數(shù)據(jù)指標(biāo)過多的場(chǎng)景中進(jìn)行計(jì)算查詢操作，所以根本的問題并沒有得到一個(gè)很好的解決。因此本文提出采用增加復(fù)雜SQL 的任務(wù)并行度、提高集群利用效率和建立中間表的方法。在傳統(tǒng)的Hadoop大數(shù)據(jù)生態(tài)系統(tǒng)基礎(chǔ)上，采用基于Hive 數(shù)據(jù)庫(kù)的編寫SQL 的大數(shù)據(jù)查詢方法，利用MapReduce 的可以并行執(zhí)行的特性［14］，即將一個(gè)復(fù)雜的SQL 任務(wù)拆分為多個(gè)并行執(zhí)行，不僅可以將一個(gè)復(fù)雜冗長(zhǎng)的SQL 代碼細(xì)分為多個(gè)，使得每一個(gè)代碼塊的分工更加明確，還可以使計(jì)算查詢結(jié)果一目了然方便閱讀。另外，對(duì)于多個(gè)并行的SQL 任務(wù)有重復(fù)查詢某幾個(gè)相同的數(shù)據(jù)指標(biāo)時(shí)，采用建立中間表的方法，也可以大大降低查詢復(fù)雜度和查詢時(shí)間。

1 基于Hadoop大數(shù)據(jù)生態(tài)系統(tǒng)的Hive數(shù)據(jù)庫(kù)

Hadoop 是一個(gè)開發(fā)和運(yùn)行處理大規(guī)模數(shù)據(jù)的軟件平臺(tái)，是Apache 的一個(gè)用Java 語(yǔ)言實(shí)現(xiàn)的開源軟件框架，實(shí)現(xiàn)通過大量計(jì)算機(jī)組成的集群對(duì)海量數(shù)據(jù)進(jìn)行分布式計(jì)算。Hadoop 的核心是HDFS和MapReduce以及YARN。

圖1 hadoop核心架構(gòu)

HDFS是Hadoop體系中數(shù)據(jù)存儲(chǔ)管理的基礎(chǔ)。它是一個(gè)高度容錯(cuò)的系統(tǒng)，用于在低成本的通用硬件上運(yùn)行。HDFS 簡(jiǎn)化了文件的一致性模型，通過流式數(shù)據(jù)訪問，提供高吞吐量應(yīng)用程序數(shù)據(jù)訪問功能，適合帶有大型數(shù)據(jù)集的應(yīng)用程序［15］。MapReduce 源自于Google 的MapReduce 論文，它是一種計(jì)算模型，用以進(jìn)行大數(shù)據(jù)量的計(jì)算。其中Map 對(duì)數(shù)據(jù)集上的獨(dú)立元素進(jìn)行指定的操作，生成鍵值對(duì)形式中間結(jié)果。Reduce 則對(duì)中間結(jié)果中相同“鍵”的所有“值”進(jìn)行規(guī)約，以得到最終結(jié)果。MapReduce 這樣的功能劃分，非常適合在大量計(jì)算機(jī)組成的分布式并行環(huán)境里進(jìn)行數(shù)據(jù)處理。YARN 是一種新的Hadoop 資源管理器，它是一個(gè)通用資源管理系統(tǒng)，可謂上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度，它的引入為集群在利用率、資源統(tǒng)一管理和數(shù)據(jù)共享等方面帶來了巨大好處。

雖然Hadoop 框架是為大數(shù)據(jù)處理而設(shè)計(jì)的，但是如果直接使用Hadoop將面臨學(xué)習(xí)成本過高以及MapReduce 實(shí)現(xiàn)復(fù)雜查詢邏輯開發(fā)難度太大的問題。因此基于Hive 具有可擴(kuò)展、高延展、高容錯(cuò)以及操作接口采用類SQL 語(yǔ)法提供快速開發(fā)能力的特性。將Hive 作為大數(shù)據(jù)處理計(jì)算和查詢的工具是非常適合的。

2 大數(shù)據(jù)的計(jì)算處理和性能查詢優(yōu)化

本案例中，以某品牌手機(jī)瀏覽器當(dāng)中推送文章為背景，獲取與手機(jī)瀏覽器信息流中文章相關(guān)的數(shù)據(jù)，本文的hive 大數(shù)據(jù)處理計(jì)算和查詢是基于四張大數(shù)據(jù)庫(kù)中的表進(jìn)行，分別是o2o_ne?whome_log_info 信息流用戶日志表、newhome_valid_user_day 有效用戶中間表、dwm_dvc_ne?whome_device_dura_di 停留時(shí)長(zhǎng)中間表、 ne?whome_mcc_new_expose_imei_day 新用戶表，總數(shù)據(jù)量在1Pb 左右。從1Pb 的數(shù)據(jù)中查詢出信息流DAU、有效用戶數(shù)、有效用戶占比、用戶次留、加權(quán)內(nèi)容曝光量等18個(gè)指標(biāo)。

2.1 數(shù)據(jù)計(jì)算查詢框架設(shè)計(jì)

在本案例中，根據(jù)指標(biāo)需求設(shè)計(jì)出單個(gè)任務(wù)執(zhí)行的計(jì)算框架。首先從數(shù)據(jù)源的四張表中根據(jù)指標(biāo)需求編寫出相應(yīng)代碼，將求得的指標(biāo)導(dǎo)入到自己創(chuàng)建的Hive表中，最后進(jìn)入Hive表查看指標(biāo)結(jié)果。

圖2 單任務(wù)執(zhí)行計(jì)算框架

在Hive 數(shù)據(jù)倉(cāng)庫(kù)中以上述四張?jiān)磾?shù)據(jù)表作為基礎(chǔ)，根據(jù)所需要求的18個(gè)數(shù)據(jù)指標(biāo)，編寫相應(yīng)的SQL 操作代碼，最后將所得到的數(shù)據(jù)指標(biāo)進(jìn)行輸出打印。

整個(gè)數(shù)據(jù)處理時(shí)長(zhǎng)為：

雖然最終能夠查詢出相應(yīng)的指標(biāo)結(jié)果，但是從執(zhí)行時(shí)長(zhǎng)來看，數(shù)據(jù)處理計(jì)算的時(shí)間過長(zhǎng)，需要進(jìn)行相應(yīng)的優(yōu)化。

2.2 增加sql的任務(wù)并行度優(yōu)化方法

當(dāng)單個(gè)查詢SQL 執(zhí)行時(shí)，集群只會(huì)分配單個(gè)任務(wù)資源進(jìn)行數(shù)據(jù)的計(jì)算處理。因此，可以將一個(gè)復(fù)雜的SQL 拆分為多個(gè)SQL，即將單一任務(wù)轉(zhuǎn)換為多個(gè)任務(wù)并行執(zhí)行。當(dāng)集群處于資源隊(duì)列未滿的情況時(shí)，這種方法也可以提高集群的利用效率。

本案例采用的策略是根據(jù)數(shù)據(jù)源的四張表將單個(gè)復(fù)雜的SQL 語(yǔ)句拆分為四個(gè)SQL 語(yǔ)句，即將原本單獨(dú)執(zhí)行的任務(wù)轉(zhuǎn)變?yōu)樗膫€(gè)任務(wù)并行執(zhí)行。即

圖3 多任務(wù)執(zhí)行計(jì)算框架

整個(gè)數(shù)據(jù)處理時(shí)長(zhǎng)為：

數(shù)據(jù)并行計(jì)算處理相較于之前的執(zhí)行單個(gè)SQL 任務(wù)時(shí)長(zhǎng)縮短60%，同時(shí)也提高了集群的利用效率。

2.3 建立中間表的優(yōu)化方法

為了能夠進(jìn)一步縮短數(shù)據(jù)計(jì)算處理時(shí)長(zhǎng)，設(shè)計(jì)了建立中間表的優(yōu)化方法。針對(duì)某一個(gè)計(jì)算處理多個(gè)指標(biāo)的SQL，通過聚合SQL 中相同的代碼塊提取出中間指標(biāo)建立中間表，這種方法減少了代碼冗余量的同時(shí)也縮短了任務(wù)執(zhí)行時(shí)長(zhǎng)。

圖4 多任務(wù)組合中間表計(jì)算框架

整個(gè)數(shù)據(jù)處理時(shí)長(zhǎng)為

通過在任務(wù)并行計(jì)算的基礎(chǔ)之上采用建立中間表的方式，相較于之前只通過任務(wù)并行優(yōu)化的方式執(zhí)行時(shí)長(zhǎng)上縮短了25%，對(duì)比之前沒有采取任何優(yōu)化措施的執(zhí)行方式時(shí)長(zhǎng)上縮短了70%。

3 結(jié)語(yǔ)

該大數(shù)據(jù)計(jì)算處理優(yōu)化方法采用增加任務(wù)并行度與建立中間表組合的方式，通過MapReduce進(jìn)行數(shù)據(jù)計(jì)算。利用MapReduce 的執(zhí)行特點(diǎn)，增加任務(wù)并行度提高集群使用效率，同時(shí)根據(jù)SQL的執(zhí)行特性建立中間表，也大大降低了數(shù)據(jù)計(jì)算的時(shí)長(zhǎng)。通過實(shí)驗(yàn)得出采用增加任務(wù)并行度融合建立中間表的方法相較于僅采用增加任務(wù)并行度的方法在計(jì)算時(shí)間上減少了30%，相較于不做任何優(yōu)化處理的方式時(shí)間上減少了78%，并且提高了集群的使用效率，同時(shí)也能夠很好的保證最后得到需要的數(shù)據(jù)。