應用場景

Impala是目前主流的SQL on Hadoop查詢引擎，它主要是針對分析類交互式查詢場景設計的，特別適用于大數據量的全表數據掃描，多表關聯以及匯總分析等。隨著Impala的使用越來越廣泛，很多客戶在使用Impala做分析查詢的同時，也開始使用Impala做單表的條件明細查詢，例如基于手機號碼查詢過去一段時間的通話記錄。由于Impala不支持索引，因此，即使只有幾條通話記錄，Impala也需要對全表做掃描，效率比較低。目前唯一的優(yōu)化手段就是采用分區(qū)策略，但是仍然不能從根本上解決明細查詢的性能問題。

為了更好的應對明細查詢的應用場景，Impala在2.9版本推出了兩個基于parquet文件格式的存儲索引技術：min/max過濾，以及字典過濾。

min/max過濾

min/max存儲索引只在底層文件格式是parquet時才有效。在parquet文件中，每個block（row group）會存放每個字段的在該block中最大和最小值統計信息。當Impala掃描parquet文件時，可以先判斷min/max統計信息，然后決定是否讀取該block，從而達到加速查詢性能的目的。例如以下示例：

select * from cdr_table where calling_phone_num = '13700885960';

注意，min/max存儲索引對于非排序的數據過濾不是非常有效。因此，為了有效的使用該功能，一般建議對數據按照某個常用的查詢字段進行排序。在Impala中，支持在創(chuàng)建表的時候指定排序字段，這樣當數據加載到這張表時，會自動進行排序。例如以下示例：

create table cdr_table (...)? ?

sort by (calling_phone_num)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

stored as parquet ;

目前min/max支持數值類型（包括numeric和decimal）、string類型以及timestamp類型。

字典過濾

在parquet文件格式中，會對每一個字段進行編碼（encoding），缺省會采用PLAIN_DICTIONARY的編碼方式，每個字段的字典（DICTIONARY）信息會在parquet block中的dictionary page中保存，Impala在掃描parquet block時會根據字典統計信息進行block級別的過濾；但是當這個字段在一個parquet block中的唯一值（DISTINCT Value）> 40,000時，該字段的編碼方式自動切換為PLAIN，字典過濾失效。因此為了避免字典過濾失效，可以把parquet block的大小調小，具體可以通過以下參數配置：

set parquet_file_size=128m

測試環(huán)境

1個主節(jié)點，7個工作節(jié)點，工作節(jié)點配置如下：

? 2個10 Core CPU

? 256GB內存，分給Impala 120GB

? 12塊4TB SATA硬盤

? 1Gb網絡

操作系統是CentOS 6.5

Hadoop版本是CDH 5.12/Impala 2.9

測試用例

本次測試采用一天的呼叫詳單記錄（Call Detail Record），總計37.2億條記錄，270GB數據（壓縮后）。呼叫詳單記錄有20+字段，其中最主要的查詢字段包括：

? 主叫號碼? calling_num

? 被叫號碼? called_num

? 主叫卡號? calling_imsi

? 主叫設備號 calling_imei

? 接入基站? base_station

? 呼叫日期? calling_date

本次測試用例分兩組，共12個查詢。第一組是明細查詢，第二組是簡單的匯總查詢。具體用例描述如下：

圖一:測試用例

測試結果

本次測試共運行4個批次，分別為：baseline, sort-128, sort-64,sort-32。

圖二:測試批次

我們注意到，當數據按主叫號碼排序后，由于壓縮比更高，數據大小相比未排序前減少了將近50%，同時，由于block size變小，最終生成的parquet文件數量增多。

分組1的測試結果如下：

圖三：測試結果（組1）

分組2的測試結果如下：

圖四：測試結果（組2）

總結

min/max過濾對于排序字段的查詢性能有顯著的提升：例如對于排序字段（calling_num）的單一條件查詢（Query 1, 2），sort-128平均提升了22.6倍，sort-64平均提升了26.3倍。

字典過濾在block size較小的情況下對查詢性能有顯著的提升：例如對于非排序字段(calling_imsi, base_station,called_num)的查詢（Query 3,4,6,7,8,9）, sort-128平均提升了2.4倍，sort-64平均提升了3.6倍，sort-32平均提升了4.9倍。

對于簡單的匯總查詢，改變block size并不會對性能有太大的影響，事實上，由于排序后壓縮比變大，實際性能得到了提升。