Hive-如何基于分区优化

最近一直做系统优化，但从建模的角度今天有个小优化，原理比较简单，效果可能不是很大，但很有意思。

这种优化的好处是不用改变sql代码，对用户是透明的。

所以分享下。

-

由于hive在文件基础上，而会全部扫一个分区里面的内容。

hive表的概念是基于hadoop的文件系统hdfs，表其实是分布式文件里面的一个文件目录。

再加上没有索引，如果要取的表里面的某些字段就必须全部扫描该表对应的文件目录

-

如：建表way1：

create table if not exists t_hm_0501_test_01

(

uid string,

nick string

)

PARTITIONED BY (pt STRING , bc_seller string )

row format delimited

fields terminated by ‘/t’

lines terminated by ‘/n’

stored as textfile;

-

在hadoop的hdfs中其实是这样的目录

–

t_hm_0501_test_01表对应hdfs里的如下文件目录。

/t_hm_0501_test_01

—-

一级分区

/t_hm_0501_test_01/pt=20110501000000

/t_hm_0501_test_01/pt=20110502000000

–

二级分区

/t_hm_0501_test_01/pt=20110501000000/bc_seller=0

/t_hm_0501_test_01/pt=20110501000000/bc_seller=1

最后那个分区目录后面放的是真正的数据文件

—

如果有语句 select ,.. from t_hm_0501_test_01  where pt’=20110501000000’ and bc_seller=0

Hadoop只读取/t_hm_0501_test_01/pt=20110501000000/bc_seller=0 下面的数据，不用处理bc_seller = 1 的数据。

–

如果这个表where条件中的值不是分区字段，则会全部扫里面的内容。

如果我们把部分常用字段枚举成分区字段，则会减少扫的内容（条数）。

！！

Way2：

如果这样建表：

create table if not exists t_hm_0501_test_01

(

uid string,

nick string

)

PARTITIONED BY (pt STRING )

row format delimited

fields terminated by ‘/t’

lines terminated by ‘/n’

stored as textfile;

-

一级分区

/t_hm_0501_test_01/pt=20110501000000

/t_hm_0501_test_01/pt=20110502000000

同样的sql 语句：

select ,.. from t_hm_0501_test_01  where pt’=20110501000000’ and bc_seller=0

-

其实是扫的是：

/t_hm_0501_test_01/pt=20110501000000 所有东西，包括下面bc_seller=1的数据，增加了脏数据。

浪费了一些map 及其他资源。

-

这其实是一个树形结构，如果做得好就是个tree算法，可以最少的读取文件。

而且这种优化的好处是不用改变sql代码，对用户是透明的。

那么如何设定partition 及如何确定其分区值

就成了关键。

1. 还可以凭借一些业务经验去确定，更科学的是通过系统自动的解决该问题。

这里通过对hive sql 元数据解析，写一下算法进行分析，得到更好的提出更优的分区

具体如何选择需要，需要改字段满足一些特性。

1. 比较容易枚举
2. 字段指相对固定
3. 频率最高的过滤字段

————

如下例子：

如果你在数据分析的过程中，

你的用户表操作的性别过滤很多，可以以性别作为分区。

———-

如果你经常分析成交数据

大量分析计算30天的交易成交，其次是60天的成交。

你也可以时段进行分区，这样可以节省你很多成本。