Hive数据压缩笔记
Hive数据压缩
本文介绍Hadoop系统中Hive数据压缩方案的比较结果及具体压缩方法。
一、压缩方案比较
关于Hadoop HDFS文件的压缩格式选择,我们通过多个真实的Track数据做测试,得出结论如下:
1. 系统的默认压缩编码方式 DefaultCodec 无论在压缩性能上还是压缩比上,都优于GZIP 压缩编码。这一点与网上的一些观点不大一致,网上不少人认为GZIP的压缩比要高一些,估计和Cloudera的封装及我们Track的数据类型有关。
2. Hive文件的RCFile 的在压缩比,压缩效率,及查询效率上都优于SEQENCE FILE (包括RECORD, BLOCK 级别) 。
3. 所有压缩文件均可以正常解压为TEXT 文件,但比原始文件略大,可能是行列重组造成的。
关于压缩文件对于其他组件是适用性如下:
1. Pig 不支持任何形式的压缩文件。
2. Impala 目前支持SequenceFile的压缩格式,但还不支持RCFile的压缩格式。
综上所述:
从压缩及查询的空间和时间性能上来说,DefaultCodeC + RCFile的压缩方式均为最优,但使用该方式,会使得Pig 和Impala 无法使用(Impala的不兼容不确定是否是暂时的)。
而DefaultCodeC+ SequenceFile 在压缩比,查询性能上略差于RCFile (压缩比约 6:5), 但可以支持 Impala实时查询。
推荐方案:
采用RCFile 方式压缩历史数据。FackBook全部hive表都用RCFile存数据。
二、局部压缩方法
只需要两步:
1. 创建表时指定压缩方式,默认不压缩,以下为示例:
create external table track_hist(
id bigint, url string, referer string, keyword string, type int, gu_idstring,
…/*此处省略中间部分字段*/ …, string,ext_field10 string)
partitioned by (ds string) stored as RCFile location '/data/share/track_histk' ;
2. 插入数据是设定立即压缩
SET hive.exec.compress.output=true;
insert overwrite table track_histpartition(ds='2013-01-01')
select id,url, …/*此处省略中间部分字段*/ …, ext_field10 fromtrackinfo
where ds='2013-01-01';
三、全局方式,修改属性文件
在hive-site.xml中设置:
<property>
<name>hive.default.fileformat</name>
<value>RCFile</value>
<description>Default file format for CREATE TABLE statement.Options are TextFile and SequenceFile. Users can explicitly say CREAT
E TABLE ... STORED AS<TEXTFILE|SEQUENCEFILE> to override</description>
</property>
<property>
<name>hive.exec.compress.output</name>
<value>true</value>
<description> This controls whether the final outputs of a query(to a local/hdfs file or a hive table) is compressed. The compres
sion codec and other options are determinedfrom hadoop config variables mapred.output.compress* </description>
</property>
四、注意事项
1、Map阶段输出不进行压缩
2、对输出文本进行处理时不压缩

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Hbase系统架构及数据结构
HBase中的表一般有这样的特点: 1 大:一个表可以有上亿行,上百万列 2 面向列:面向列(族)的存储和权限控制,列(族)独立检索。 3 稀疏:对于为空(null)的列,并不占用存储空间,因此,表可以设计的非常稀疏。 下面一幅图是Hbase在Hadoop Ecosystem中的位置。 二、逻辑视图 HBase以表的形式存储数据。表有行和列组成。列划分为若干个列族(row family) Row Key 与nosql数据库们一样,row key是用来检索记录的主键。访问hbase table中的行,只有三种方式: 1 通过单个row key访问 2 通过row key的range 3 全表扫描 Row key行键 (Row key)可以是任意字符串(最大长度是 64KB,实际应用中长度一般为 10-100bytes),在hbase内部,row key保存为字节数组。 存储时,数据按照Row key的字典序(byte order)排序存储。设计key时,要充分排序存储这个特性,将经常一起读取的行存储放到一起。(位置相关性) 注意: 字典序对int排序的结果是1,10,100,11,12,...
- 下一篇
Hadoop分布式文件系统:架构和设计要点
原文:http://hadoop.apache.org/core/docs/current/hdfs_design.html一、前提和设计目标 1、硬件错误是常态,而非异常情况, HDFS可能是有成百上千的 server组成,任何一个组件都有可能一直失效,因此错误检测和快速、自动的恢复是 HDFS的核心架构目标。 2、跑在 HDFS上的应用与一般的应用不同,它们主要是以流式读为主,做批量处理;比之关注数据访问的低延迟问题,更关键的在于数据访问的高吞吐量。 3、 HDFS以支持大数据集合为目标,一个存储在上面的典型文件大小一般都在千兆至 T字节,一个单一 HDFS实例应该能支撑数以千万计的文件。 4、 HDFS应用对文件要求的是 write-one-read-many访问模型。一个文件经过创建、写,关闭之后就不需要改变。这一假设简化了数据一致性问 题,使高吞吐量的数据访问成为可能。典型的如 MapReduce框架,或者一个 web crawler应用都很适合这个模型。 5、移动计算的代价比之移动数据的代价低。一个应用请求的计算,离它操作的数据越近就越高效,这在数据达到海量级别的时候更是如...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- Windows10,CentOS7,CentOS8安装Nodejs环境
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS7设置SWAP分区,小内存服务器的救世主
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8安装Docker,最新的服务器搭配容器使用
- SpringBoot2配置默认Tomcat设置,开启更多高级功能