Hive-如何基于分区优化
2011-05-16 17:19
204 查看
最近一直做系统优化,但从建模的角度今天有个小优化,原理比较简单,效果可能不是很大,但很有意思。
这种优化的好处是不用改变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天的成交。
你也可以时段进行分区,这样可以节省你很多成本。
这种优化的好处是不用改变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天的成交。
你也可以时段进行分区,这样可以节省你很多成本。
相关文章推荐
- 数据仓库(七)---hive的性能优化---hive的分区和分桶
- 基于MySQL 水平分区的优化示例
- 基于MySQL 水平分区的优化示例
- HIVE优化提示-如何写好HQL
- 数据仓库(八)---hive的性能优化---hive动态分区
- 【原创】基于MySQL 水平分区的优化示例
- Unity中国技术总监刘钢:如何优化基于Unity开发的3D移动游戏
- 在Hive中如何实现数据分区
- hive优化:基于map数和reduce数
- 分区表的作用和使用深入分析(如何用分区表来优化数据库)
- 大数据系列之数据仓库Hive中分区Partition如何使用
- mysql hive sqoop 分区,优化
- 在Hive中如何实现数据分区
- Hive 分区优化以及jon 优化
- 016-Hadoop Hive sql语法详解6-job输入输出优化、数据剪裁、减少job数、动态分区
- 如何基于CPU的架构来优化软件的性能?
- 四十四、如何基于数据统计做网站页面布局的优化和适配
- 基于MySQL 水平分区的优化示例
- Hive优化1---分区、桶、index
- 大数据Hive的案例、参数、动态分区、分桶、视图、索引、运行方式、权限管理、Hive的优化_03_03