最近一直做系统优化,但从建模的角度今天有个小优化,原理比较简单,效果可能不是很大,但很有意思。
这种优化的好处是不用改变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 及如何确定其分区值
就成了关键。
- 还可以凭借一些业务经验去确定,更科学的是通过系统自动的解决该问题。
这里通过对hive sql 元数据解析,写一下算法进行分析,得到更好的提出更优的分区
具体如何选择需要,需要改字段满足一些特性。
- 比较容易枚举
- 字段指相对固定
- 频率最高的过滤字段
————
如下例子:
如果你在数据分析的过程中,
你的用户表操作的性别过滤很多,可以以性别作为分区。
———-
如果你经常分析成交数据
大量分析计算30天的交易成交,其次是60天的成交。
你也可以时段进行分区,这样可以节省你很多成本。