準備了一個 427144792 行的 textfile 格式表 t_item：

[impale-host:21000] > select count(1) from t_item;
Query: select count(1) from t_item  
+-----------+
| count(1)  |
+-----------+
| 427144792 |
+-----------+
Fetched 1 row(s) in 191.67s  

該表在 hdfs 儲存的大小：

$ sudo -u hdfs hadoop fs -du -s -h /user/hive/warehouse/t_item
44.5
 
 G  133.6 G  /user/hive/warehouse/t_item  

現在我們使用預設的 snappy 壓縮方式建立一個 parquet_snappy_t_item 表：

[impale-host:21000] > create table parquet_snappy_t_item like t_item stored as parquet;
Query: create table parquet_snappy_t_item like t_item stored as parquet

Fetched 0 row(s) in 0.36s  
[impala-host:21000] > set
 
 COMPRESSION_CODEC=snappy;
COMPRESSION_CODEC set to snappy  
[impala-host:21000] > insert into parquet_snappy_t_item select * from t_item;
Query: insert into parquet_snappy_t_item select * from t_item  
Inserted 427144792 row(s) in 421.85s  

先看下資料的壓縮情況：

$ sudo -u hdfs hadoop fs -du -s -h /user/hive/warehouse/parquet_snappy_t_item
7.3
 
 G  14.5 G  /user/hive/warehouse/parquet_snappy_t_item  

已經壓縮到了原先的 1/6 左右，符合我們對 snappy 壓縮演算法的預期。

那麼對資料查詢有沒有什麼影響：

先跑下 count 看看：

[impala-host:21000] > select count(1) from parquet_snappy_t_item;
Query: select count(1) from parquet_snappy_t_item  
+-----------+
| count(1)  |
+-----------+
| 427144792 |
+-----------+
Fetched 1 row(s) in 2.60s  

2.60s vs 191.67s 好驚人的優化。

不過經同事提醒，可能是 Parquet 將行數預先儲存在元資料裡面了。

那再跑一下 group by ：

[impala-host:21000] > select count(item_id), item_id from parquet_snappy_t_item group by 2 order by 1 desc limit 10;
... 省略輸出 ...
Fetched 10 row(s) in 11.62s  

而相對於原先 textfile 格式的表：

[impala-host:21000] > select count(item_id), item_id from t_item group by 2 order by 1 desc limit 10;
... 省略輸出 ...
Fetched 10 row(s) in 189.42s  

11.62s vs 189.42s 優勢依然明顯。

再來比較下 gz 和 snappy 壓縮：

gz 的優勢在於進一步將資料壓縮到了 1/10，但是用時也多了一倍，但是在查詢中的 CPU 和記憶體比較 snappy，相差並不大。

以上。

既壓縮了資料還能優化了查詢速度，這麼逆天的黑科技，還不趕緊用起來？

轉載：https://zhengheng.me/2017/05/23/impala-parquet/