Hive压缩测试

Hive存储格式

操作方式：

可以在建表的时候指定表的存储格式：stored as orc tblproperties ("orc.compress"="SNNAPY")，不指定表属性则默认压缩采用ZLIB。

比如：

create table Addresses (

  name string,

  street string,

  city string,

  state string,

  zip int

) stored as orc;

或者：

create table Addresses (

  name string,

  street string,

  city string,

  state string,

  zip int

) stored as orc tblproperties ("orc.compress"="SNNAPY");

注意点：

不能直接通过

ALTER TABLE table_name [PARTITION partition_spec] SET FILEFORMAT file_format;

方式来修改原先是text格式的表为orc格式，那只是修改了表属性，而文件存储格式还是text的，所以查询会出现解析错误。要使用orc格式，可以新建新表，指定存储格式为orc，然后从原先的text表insert到新表中即可。

另外load方式加载数据，只是一个移动数据的过程，不会修改数据的格式，所以使用load加载数据要注意。

测试对比：

6000万数据，50个字段(name1…name50)

空间占用

text格式占用空间：10.8g

orc格式采用zlib压缩（默认压缩方式）占用空间：1.4g

orc格式采用snnapy压缩，占用空间：1.5g

 

 

 

查询性能

1. select count(*) from table;

text，花费：34.202 seconds

orc格式采用zlib压缩，花费：33.576 seconds

orc格式采用snnapy压缩，花费：33.038 seconds

2. select count(*) from table where field = value ;

text，花费：37.311 seconds

orc格式采用zlib压缩，花费：35.847 seconds

orc格式采用snnapy压缩，花费：33.698 seconds

从上的对比可以看出，使用orc格式的存储，可以极大程度降低存储占用，而查询效率上也不会差。经过多次测试和对比，orc格式中，zlib和snnapy对比，zlib压缩率会略高，但是查询效率略低于snnapy。建议使用orc的snnapy压缩。另外由于数据压缩，数据量变小，所以job启动后生成的map/reduce数目也会变少（但单个map处理的数据就会增大，所以以前设置的很多内存参数比如-Xmx256就会太小，应该设大，不然出现大量溢写，计算效率不会好），占用的container就会少，所以变相增加了集群的计算能力。

 

Hive执行的临时目录

操作方法：

在启动hiveserver2的时候，指定临时目录，--hiveconf hive.exec.scratchdir=配置的目录A（而实际的临时目录会是：A/登陆用户名），该默认值是/tmp/hive/用户名，如下：

nohup hive --service hiveserver2 --hiveconf  hive.server2.thrift.port=10000 --hiveconf hive.log.dir=/e3base/e3base550/hive/logs/server2_10000 --hiveconf hive.metastore.uris='thrift://192.168.10.37:9083' -- hiveconf hive.exec.scratchdir=配置的目录 &

对比如下：

不加配置，默认：

 

加配置，使用--hiveconf hive.exec.scratchdir=/user/e3base/tmpdata