项目迭代中用Impala逐步替换原有的Hive作为查询组件，速度有了脱胎换骨的飞跃。但在把原先按列存储的表转换成两个按行存储的表之后，联表查询的表现不那么给力了（原先对Hive的十倍速度优势变成了两倍）。
考虑到项目转用Impala是我的提议，调整存储结构也是我的提议，这个结果确实是个让我丢面子的事情，于是挽起袖子找优化查询的方案。
优化前
Query: select count(a.sn) from usermodel_inter_total_label a join usermodel_inter_total_info b
on a.sn = b.sn where a.label = 'porn' and a.heat > 0.1 and b.platform = 'android'
Returned 1 row(s) in 36.86s
寻路
先不管三七二十一，按SQL调优的套路来，explain一下发现了一个很隐蔽的warning：
WARNING: The following tables are missing relevant table and/or column statistics.
default.usermodel_inter_total_info, default.usermodel_inter_total_label
这种waring，不是处(pian)女(zhi)座(kuang)发现不了！
先不忙，记下来，网上找那坑爹的Tuning Impala Performance文档看看（插个题外话，Impala的中文资料太寒酸了，做数据的矿工们已经全部投奔Spark阵营了么？），眼神掠过Column Statistics和Table Statistics的时候心里一凉，矿工的直觉告诉我「秘密就在这」！
大体意思就是通过预先分析表和列（对联表特别重要）的结构，并把这些信息保存到MetaStore，Impala查询时会利用这些信息优化查询的策略。
哟，这是个自动挡！
然后坑爹的文档就把我指到Hive的「ANALYZE TABLE」去了，试了半天Impala没反应啊，果然不是亲生兄弟~
祭出谷歌大法，噢，终于找到答案了，simple，naive！感觉找回了逝去的青春。
神奇指令
COMPUTE STATS usermodel_inter_total_info;
COMPUTE STATS usermodel_inter_total_label;
优化后
Query: select count(a.sn) from usermodel_inter_total_label a join usermodel_inter_total_info b
on a.sn = b.sn where a.label = 'porn' and a.heat > 0.1 and b.platform = 'android'
Returned 1 row(s) in 3.15s
Cool！10倍的提升，相对Hive20倍的提升，和单表查询一样的迅速！
分析
以前老师总说对待问题要知其然更要知其所以然，那时特反感这一句，人生苦短，除了要大干快上，还要及时行乐，哪来的时间去知道那么多道理。
好了离题了，让我做一回现象的搬运工，让更聪明的读者来为我们解释吧。
「COMPUTE STATS」前
指令：
show table stats usermodel_inter_total_label;
返回：
| log_date | #Rows | #Files | Size | Bytes Cached | Format |
|---|---|---|---|---|---|
| 2014-12-13 | -1 | 15 | 1.18GB | NOT CACHED | TEXT |
| 2014-12-14 | -1 | 3 | 1.80GB | NOT CACHED | TEXT |
| 2014-12-15 | -1 | 4 | 2.96GB | NOT CACHED | TEXT |
| Total | -1 | 22 | 5.93GB | 0B | - |
指令：
show column stats usermodel_inter_total_label;
返回：
| Column | Type | #Distinct Values | #Nulls | Max Size | Avg Size |
|---|---|---|---|---|---|
| sn | STRING | -1 | -1 | -1 | -1 |
| label | STRING | -1 | -1 | -1 | -1 |
| heat | DOUBLE | -1 | -1 | -1 | -1 |
| active_record | STRING | -1 | -1 | -1 | -1 |
| log_date | STRING | 3 | 0 | -1 | -1 |
「COMPUTE STATS」后
指令：
show table stats usermodel_inter_total_label;
返回：
| log_date | #Rows | #Files | Size | Bytes Cached | Format |
|---|---|---|---|---|---|
| 2014-12-13 | 9498438 | 2 | 469.76MB | NOT CACHED | TEXT |
| 2014-12-14 | 17891595 | 1 | 893.44MB | NOT CACHED | TEXT |
| 2014-12-15 | 27885473 | 2 | 1.37GB | NOT CACHED | TEXT |
| Total | 55275506 | 5 | 2.71GB | 0B | - |
指令：
show column stats usermodel_inter_total_label;
返回：
| Column | Type | #Distinct Values | #Nulls | Max Size | Avg Size |
|---|---|---|---|---|---|
| sn | STRING | 13984716 | -1 | 30 | 24.0039005279541 |
| label | STRING | 36 | -1 | 13 | 4.26140022277832 |
| heat | DOUBLE | 382126 | -1 | 8 | 8 |
| active_record | STRING | 7 | -1 | 3 | 1.667400002479553 |
| log_date | STRING | 3 | 0 | -1 | -1 |
看来「COMPUTE STATS」的作用就是得出Impala原先不知道的值（-1）。
来自：建造者说
