大數(shù)據(jù)查詢技術(shù)應(yīng)用策略探討

譚志遠(yuǎn)

（中國電信股份有限公司廣州研究院，廣東 廣州 510630）

1 引言

隨著大數(shù)據(jù)技術(shù)及應(yīng)用的蓬勃發(fā)展，海量數(shù)據(jù)的處理、挖掘、統(tǒng)計分析得以實現(xiàn)，針對如何把這些海量數(shù)據(jù)處理后的結(jié)果呈現(xiàn)給決策者或最終用戶，或者說大數(shù)據(jù)應(yīng)用輸出的結(jié)果如何實現(xiàn)快速查詢，目前有多種技術(shù)解決方案，例如前端系統(tǒng)可以通過Impala查詢，或把HDFS數(shù)據(jù)同步到MySQL數(shù)據(jù)庫供前端查詢，或把數(shù)據(jù)存入HBase供前端查詢，也可以引入Kylin技術(shù)來實現(xiàn)大規(guī)模數(shù)據(jù)的查詢等。

在確保用戶感知（查詢的響應(yīng)時延在用戶可接受范圍內(nèi)）的前提下，各種查詢方式或技術(shù)如何選擇，各種查詢技術(shù)適合什么樣的應(yīng)用場景等問題，都值得進行深入的探討。本文結(jié)合大數(shù)據(jù)技術(shù)應(yīng)用經(jīng)驗，分析各種技術(shù)的特點及缺陷，參考各種應(yīng)用技術(shù)在實驗室性能測試的結(jié)果，探討大數(shù)據(jù)各種查詢技術(shù)的應(yīng)用策略。

2 大數(shù)據(jù)查詢技術(shù)特點及存在的問題

在Hadoop生態(tài)圈中，目前可以實現(xiàn)對海量數(shù)據(jù)結(jié)果進行查詢的工具或技術(shù)主要有：Hive、Impala、HBase、Kylin、MySQL（使用Sqoop同步）和Phoenix等。

在這些技術(shù)中，從用戶體驗的角度考慮，重點評估該技術(shù)的查詢響應(yīng)時延，即從提交查詢到得到查詢結(jié)果的時延，基于一般的使用經(jīng)驗，如果響應(yīng)時延超過3 s，這種查詢技術(shù)就嚴(yán)重影響用戶的使用體驗，因此響應(yīng)時延大的查詢技術(shù)不在選擇和評估的范圍內(nèi)，例如Hive用作數(shù)據(jù)處理、分析是非常理想的工具，但是如果用來作為查詢工具，其響應(yīng)時延就無法得到保證，如果用來作為查詢工具將帶來非常糟糕的用戶體驗。

對于Apache Phoenix，其核心還是使用HBase，只不過為了便于訪問，對HBase進行了封裝，提供JDBC訪問接口，降低開發(fā)難度，因此在本文，主要還是評估HBase本身的功能、性能及適用場景。

基于上述考慮，主要研究Impala、HBase、Kylin、MySQL等技術(shù)特點，結(jié)合實驗室的性能測試來綜合評估這些技術(shù)的適用場景。

2.1 Impala優(yōu)缺點

Impala是由Cloudera公司主導(dǎo)開發(fā)的大數(shù)據(jù)實時查詢分析工具，因其不同于Hive所用Map Reduce的處理機制（即中間結(jié)果不寫入HDFS，而是在內(nèi)存中直接處理），與Hive SQL查詢速度相比得到了極大的提升，且更加靈活易用。其提供類SQL的查詢語句，能夠查詢存儲在HDFS和HBase中的PB級大數(shù)據(jù)。Impala作為大數(shù)據(jù)實時查詢分析工具，具有查詢速度快、靈活性高、易整合、可伸縮性強等特點。Impala可以對已有數(shù)據(jù)進行查詢（緩存），減少數(shù)據(jù)的重復(fù)加載和轉(zhuǎn)換；支持多種存儲格式且可以自主選擇（Parquet、Text、Avro、 RCFile、SequeenceFile），可以與Hive配合使用。

Impala查詢處理機制：客戶端提交查詢，Impala查詢出結(jié)果后會一直緩存查詢結(jié)果，直到客戶端將查詢結(jié)果取出或是取消查詢或是超出了系統(tǒng)設(shè)置的idle_query_timeout（系統(tǒng)參數(shù)）時間。在此過程中，如果客戶端應(yīng)用程序開發(fā)不嚴(yán)謹(jǐn)、規(guī)范，很容易引起系統(tǒng)崩潰。

Impala的主要缺點：對內(nèi)存要求高，不支持超過內(nèi)存的查詢分析，并且多個基于Impala的并發(fā)查詢發(fā)生時，容易引起舊資源無法釋放，新任務(wù)因為得不到資源而無法啟動，嚴(yán)重時將導(dǎo)致大量查詢?nèi)蝿?wù)一直掛著，甚至引起系統(tǒng)癱瘓。Impala會因掃描的分區(qū)過多，或小文件過多而嚴(yán)重影響查詢性能，對客戶端開發(fā)的規(guī)范性和嚴(yán)謹(jǐn)性要求極高。例如：當(dāng)查詢響應(yīng)較慢或當(dāng)查詢結(jié)果還沒取出時，用戶可能點擊其他菜單離開或者關(guān)閉當(dāng)前頁面，而客戶端未釋放相關(guān)資源，造成該查詢一直沒有關(guān)閉，查詢和會話一直掛著，嚴(yán)重耗費資源，將集群越拖越慢。

因此基于上述Impala優(yōu)、缺點和實際應(yīng)用經(jīng)驗綜合考慮，建議在Impala集群有充足的資源保障前提下，且查詢客戶端代碼高效、嚴(yán)謹(jǐn)（例如：不會因關(guān)聯(lián)不當(dāng)引起數(shù)據(jù)膨脹等），Impala可作為查詢分析工具之一供選擇使用，否則強烈建議僅作為日常數(shù)據(jù)統(tǒng)計分析使用。

2.2 HBase優(yōu)缺點

HBase是一個分布式的、面向列的開源數(shù)據(jù)庫。HBase的讀寫性能都非常出色，由于寫入HBase的數(shù)據(jù)是根據(jù)Row Key按字典順序存儲的，因此基于Row Key的查詢響應(yīng)時延非常小。

HBase不能支持條件查詢，只支持按照Row Key（及其Range）來查詢或全表掃描，如果是按精確的Row Key查詢，響應(yīng)速度非?？欤ê撩爰墸駝t如果用模糊匹配（如：按Row Key的前綴模糊匹配查詢），則查詢響應(yīng)時延遠(yuǎn)大于精確匹配的查詢時延。另一方面，因為需要使用Row Key組合，寫入HDFS后數(shù)據(jù)膨脹非常厲害（如1 G的數(shù)據(jù)，寫入HBase可能占用2 G的空間），字段越多，Row Key越長，存儲到HDFS后數(shù)據(jù)膨脹越大。為規(guī)避數(shù)據(jù)膨脹的問題，可通過犧牲字段的可讀性，即把Hive表中不同字段的數(shù)據(jù)利用分隔符拼接在一個字段后再寫入HBase。

2.3 MySQL優(yōu)缺點

MySQL作為開源的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)，目前被廣泛地應(yīng)用各行業(yè)中。因使用比較大眾，本文不做詳細(xì)描述。其主要優(yōu)點有：MySQL為多種編程語言提供了API接口，訪問和使用方便；支持并發(fā)訪問，支持事務(wù)處理等。

相比于Impala、HBase等查詢引擎，MySQL隨著數(shù)據(jù)規(guī)模的擴大，查詢性能下降比較明顯。

2.4 Kylin優(yōu)缺點

Apache Kylin是一個開源的分布式分析引擎，提供Hadoop之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規(guī)模數(shù)據(jù)，能在亞秒內(nèi)查詢巨大的Hive表。Kylin的原理是利用Hadoop的Map Reduce框架實現(xiàn)對Hive中數(shù)據(jù)的預(yù)計算，并把計算出的結(jié)果存入HBase中，可通過Rest API、JDBC/ODBC等接口使用SQL供前端查詢，并能快速響應(yīng)查詢結(jié)果，適應(yīng)于對大規(guī)模數(shù)據(jù)的統(tǒng)計分析。

Kylin的主要優(yōu)點包括如下幾個方面：

（1）多維度查詢響應(yīng)迅速。Kylin基于Cube技術(shù)實現(xiàn)多表關(guān)聯(lián)分析的技術(shù)應(yīng)用，能解決目前前端復(fù)雜查詢的時延問題，基本能在亞秒內(nèi)響應(yīng)。

（2）輸出結(jié)果占用存儲空間小。Kylin基于字典技術(shù)，把Cube Build后的結(jié)果存放于HBase，占用存儲空間極小，是原始文件的千分之一，甚至更小。

（3）采用Kylin技術(shù)可有效減少統(tǒng)計分析表的設(shè)計數(shù)量，減少數(shù)據(jù)處理任務(wù)的調(diào)度量及調(diào)度難度，可大大節(jié)省集群資源。Kylin構(gòu)建后，基于一個Cube可實現(xiàn)多維度靈活統(tǒng)計，如按天、周、月，按本地網(wǎng)、基站、小區(qū)等多維度統(tǒng)計，避免對同一個數(shù)據(jù)源需要分別設(shè)計多個不同統(tǒng)計維度的分析表。

（4）調(diào)用方便：前端可以基于JDBC/ODBC或者REST API查詢Kylin預(yù)計算后的結(jié)果。

Kylin技術(shù)的應(yīng)用主要缺點包括如下幾個方面：

（1）Kylin只支持對字符型日期分區(qū)進行增量更新。目前Cube只支持按天、小時進行增量更新，但分區(qū)類型必須是字符型（整型不能實現(xiàn)自動增量更新），因此如果集群中現(xiàn)有表的分區(qū)類型非字符型（這里指需要增量更新的分區(qū)）都必須修改，但是基于Hive存儲的分區(qū)表，如果需要修改分區(qū)的字段類型，只能重新構(gòu)建Hive表（如果使用視圖來進行字段類型轉(zhuǎn)換的話，分區(qū)字段轉(zhuǎn)換過程會引起Hive的全表掃描，性能極低，不建議采用這種方式進行分區(qū)字段類型的轉(zhuǎn)換，但普通字段可以利用視圖來進行轉(zhuǎn)換）。

（2）Kylin的維表（Dimension Table，也稱Lookup Table）不支持分區(qū)增量更新。即在Kylin的Cube構(gòu)建過程中，不支持維表也使用增量更新分區(qū)的方式，除非在設(shè)計事實表（Fact Table）的時候，先與這種維表關(guān)聯(lián)，把維表的相關(guān)信息直接生成在事實表中，從而規(guī)避維表不支持增量更新分區(qū)（這里主要指按日期需要增量更新的分區(qū)，如DAY或HOUR分區(qū)等，普通分區(qū)是可以支持的）的問題。

（3）構(gòu)建Cube的表中各維度的基數(shù)（即對某個字段去重后，字段中內(nèi)容不同取值的數(shù)量）不能太大，官方建議不超過100萬，因此目前基于用戶號碼的統(tǒng)計查詢，將不能用Kylin來實現(xiàn)。

3 性能對比測試

為便于比較上述幾種查詢技術(shù)的性能，在各測試場景中都使用同一份數(shù)據(jù)（測試數(shù)據(jù)信息如表1所示）進行性能測試，因此選取了一段時間內(nèi)3G、4G用戶上網(wǎng)流量記錄進行對比測試。

表1 大數(shù)據(jù)查詢技術(shù)測試數(shù)據(jù)信息

3.1 Impala&MySQL性能對比測試

因為MySQL和Impala可以使用相同的SQL直接進行性能對比測試，因此測試前先通過Sqoop工具把Hive表中的數(shù)據(jù)同步到MySQL中，并都使用同樣的分區(qū)結(jié)構(gòu)（以DAY為分區(qū)），MySQL預(yù)先針對查詢條件配置了相應(yīng)的索引。表2是使用同樣的SQL語句/同樣的數(shù)據(jù)量情況下，查詢響應(yīng)時延的分布情況。

圖1為MySQL和Impala性能對比的曲線圖，從圖中可以看成，MySQL的性能曲線比較陡，而Impala比較平緩，說明MySQL查詢響應(yīng)時延受數(shù)據(jù)量的影響比Impala大，且超過500萬條記錄時，MySQL的查詢時延越來越長。在不進一步擴充集群資源或者優(yōu)化的前提下，在測試所使用的環(huán)境下，MySQL相對來說更適用于數(shù)據(jù)量在500W條記錄以內(nèi)的檢索，而如果是大數(shù)據(jù)的關(guān)聯(lián)分析，Impala更加合適。

表2 MySQL和Impala查詢時延對比

圖1 Impala和MySQL查詢響應(yīng)時延曲線圖

3.2 HBase性能測試

在實驗室采用Hive集成HBase表（即Hive建表的時候通過STORED BY...WITH語句關(guān)聯(lián)HBase表）的方式，把74億條數(shù)據(jù)寫入HBase表中，為提高寫入性能，HBase建表時根據(jù)用戶號碼（通過MD5加密后的號碼）后三位模1 000的隨機數(shù)進行預(yù)分區(qū)（切分Region）。

HBase基于Row Key的字典排序以及Region的切分等策略，確保了其基于Row Key的快速查詢，因此在實驗室測試時HBase的讀寫性能相比Impala和MySQL都是極其出色的。無論數(shù)據(jù)量是百萬條、千萬條、億條，甚至是十億、百億條，只要檢索條件中給出確定的Row Key或Row Key的起始范圍（STARTROW和ENDROW），測試響應(yīng)時延都在0.1 s至0.2 s間。但是如果使用模糊查詢（如前綴匹配PrefixFilter），響應(yīng)時延將隨著數(shù)據(jù)量的擴大而變得不可控，響應(yīng)時延短的為5 s～6 s，長的為6 s～40 s，甚至超時響應(yīng)的都有，因此實際應(yīng)用過程中盡量避免使用模糊匹配的查詢方式。

3.3 Kylin性能測試

根據(jù)Kylin的實現(xiàn)機制，在測試前需要創(chuàng)建數(shù)據(jù)模型，根據(jù)查詢需求構(gòu)建適當(dāng)?shù)腃ube，包括確定統(tǒng)計維度、統(tǒng)計內(nèi)容、增量更新的分區(qū)字段、優(yōu)化策略等，針對構(gòu)建好的Cube執(zhí)行Build操作，從而把Hive中的各分區(qū)數(shù)據(jù)通過增量更新導(dǎo)入到Kylin中（Kylin采用HBase存儲預(yù)計算后的結(jié)果）。由于Kylin在寫入HBase的時候利用字典編碼技術(shù)對寫入數(shù)據(jù)進行了二次編碼，因此在不啟用壓縮的情況下（Kylin配置文件中有參數(shù)可以配置是否啟用壓縮），原來存儲在HDFS上920 G的數(shù)據(jù)，全部存入HBase只占用720 M的空間，每天數(shù)據(jù)（7～10億條左右）增量更新耗時30～45分鐘不等（測試時Cube定了5個維度，實際更新時間會隨著維度的增加而增加）。

針對上述測試數(shù)據(jù)經(jīng)Kylin預(yù)計算后的結(jié)果進行查詢，響應(yīng)時延基本都在毫秒級，測試結(jié)果如表3所示。

4 應(yīng)用建議

沒有一種大數(shù)據(jù)查詢技術(shù)能完全滿足各種應(yīng)用場合的需要，因此只能盡可能地取長補短，結(jié)合實際工作需求、資源情況，選取合適的技術(shù)，充分發(fā)揮各種技術(shù)的特長。因此結(jié)合MySQL、Impala、HBase、Kylin等技術(shù)特點以及實驗室性能對比測試情況，針對上述幾種技術(shù)，進行了對比分析，并形成了4種查詢技術(shù)的應(yīng)用建議，詳細(xì)如表4所示。

表3 Kylin構(gòu)建時長及查詢響應(yīng)時延情況

表4 MySQL、Impala、HBase、Kylin性能對比

5 結(jié)束語

本文通過分析Impala、MySQL、HBase、Kylin等查詢技術(shù)的優(yōu)缺點，結(jié)合實驗室性能測試結(jié)果，對這幾種查詢技術(shù)進行了對比分析，最終給出這幾種查詢技術(shù)適合應(yīng)用場景的建議，并指出應(yīng)用過程中需要注意的問題。