- zstd是Facebook在2016年开源的新无损压缩算法,优点是压缩率和压缩/解压缩性能都很突出。
- 在我们测试的文本日志压缩场景中,压缩率比gzip提高一倍,压缩性能与lz4、snappy相当甚至更好,是gzip的10倍以上。
- zstd还有一个特别的功能,支持以训练方式生成字典文件,相比传统压缩方式能大大的提高小数据包的压缩率。
- 在过去的两年里,Linux内核、HTTP协议、以及一系列的大数据工具(包括Hadoop 3.0.0,HBase 2.0.0,Spark 2.3.0,Kafka 2.1.0)等都已经加入了对zstd的支持。
- 可以预见,zstd将是未来几年里会被广泛关注和应用的压缩算法。
引用:https://blog.csdn.net/yizhiniu_xuyw/article/details/113811001
LZO:Lempel-Ziv-Oberhumer 的缩写,一种无损算法,LZO压缩算法采用(重复长度L,指回距离D)代替当前已经在历史字符串中出现过的字符串,其中,重复长度是指,后出现的字符串与先出现的字符串中连续相同部分的长度;指回距离是指,先后两个相同字符串之间相隔的距离(每个字节为一个单位);如果没出现过(定义为新字符),则首先输出新字符的个数,再输出新字符。
LZO压缩算法特点:
Snappy 是一个 C++ 的用来压缩和解压缩的开发包。其目标不是最大限度压缩或者兼容其他压缩格式,而是旨在提供高速压缩速度和合理的压缩率。Snappy 比 zlib 更快,但文件相对要大 20% 到 100%。在 64位模式的 Core i7 处理器上,可达每秒 250~500兆的压缩速度。
SNAPPY压缩算法特点:
尽管 Snappy 应该相当轻便,但它主要针对 64 位 x86 兼容处理器进行了优化,并且在其他环境中运行速度可能较慢。
bzip2 是一个基于Burrows-Wheeler 变换的无损压缩软件,压缩效果比传统的LZ77/LZ78压缩算法来得好。它广泛存在于UNIX && LINUX的许多发行版本中。bzip2能够进行高质量的数据压缩。它利用先进的压缩技术,能够把普通的数据文件压缩10%至15%,压缩的速度和解压的效率都非常高!支持大多数压缩格式,包括tar、gzip 等等。
BZIP2压缩算法特点:
HIVE的压缩格式
压缩格式 | 全类路径 |
---|---|
DEFLATE | org.apache.hadoop.io.compress.DefaultCodec |
GZIP | org.apache.hadoop.io.compress.GzipCodec |
BZIP2 | org.apache.hadoop.io.compress.BZip2Codec |
LZO | com.hadoop.compression.lzo.LzopCodec |
SNAPPY | org.apache.hadoop.io.compress.SnappyCodec |
ZSTD | org.apache.hadoop.io.compress.ZStandardCodec |
压缩可以存在很多地方,在mr任务运行时候,map端溢写到磁盘,以及reduce端从磁盘中拉取文件,都有大量的IO操作,都可以设置压缩方法。设置压缩格式的参数如下所示
HIVE配置map/reduce/all 端的压缩算法参数
参数 | 默认值 | 阶段 | 生产环境设置 |
---|---|---|---|
io.compression.codecs (在core-site.xml中配置) | org.apache.hadoop.io.compress.DefaultCodec, org.apache.hadoop.io.compress.GzipCodec, org.apache.hadoop.io.compress.BZip2Codec, org.apache.hadoop.io.compress.Lz4Codec |
输入压缩 | Hadoop使用文件扩展名判断是否支持某种编解码器 |
mapreduce.map.output.compress | false | mapper输出 | 这个参数设为true启用压缩 |
mapreduce.map.output.compress.codec | org.apache.hadoop.io.compress.DefaultCodec | mapper输出 | 使用LZO、LZ4或snappy编解码器在此阶段压缩数据 |
mapreduce.output.fileoutputformat.compress | false | reducer输出 | 这个参数设为true启用压缩 |
mapreduce.output.fileoutputformat.compress.codec | org.apache.hadoop.io.compress. DefaultCodec | reducer输出 | 使用标准工具或者编解码器,如gzip和bzip2 |
mapreduce.output.fileoutputformat.compress.type | RECORD | reducer输出 | SequenceFile输出使用的压缩类型:NONE和BLOCK |
存储格式可以分为两种:行式存储、列式存储
和我们平时认知的形同,一行数据就按照一行存,读取的时候也是一行一行的去读
行式存储是按照行为顺序进行存储,那么列式存储就是按照列为顺序进行存储。
为什么要列式存储呢?
在大数据存储上,数据量大,查询频繁,那么如果行式存储,我们每次查询数据会怎么办?举例:
co1, co2, co3, co4
data1, data2, data3, data4
size1, size2, size3, size4
如果我们要去执行一个语句
select co1, co4 from tbl;
按照行式存储,存储数据格式如下;
data1, data2, data3, data4, size1, size2, size3, size4
我们读取数据的时候要来回的跳,跳到第一个,再跳到第四个
如果按照列式存储,存储数据格式如下;
data1, size1, data2, size2, data3, size3, data4, size4
那我们读取时候,读到了哪个列,把这个列的数据顺序拿出来,然后再到下一个列,就不用像行数存储那样来回跳了。
存储类型 | 格式 |
---|---|
TEXTFILE | 行式存储 |
ORC | 列式存储 |
PARQUET | 列式存储 |
SEQUENCEFILE |
毋庸置疑,这是最常使用到的文件存储格式,就是文本文件。文本文件在加载的时候直接load即可,不用走MapReduce,因为是最简单的文本格式
- sequenceFile文件是Hadoop用来存储二进制形式的[Key,Value]对而设计的一种平面文件(Flat File)。
- 可以把SequenceFile当做是一个容器,把所有的文件打包到SequenceFile类中可以高效的对小文件进行存储和处理。
- SequenceFile文件并不按照其存储的Key进行排序存储,SequenceFile的内部类Writer提供了append功能。
- SequenceFile中的Key和Value可以是任意类型Writable或者是自定义Writable。
- 在存储结构上,SequenceFile主要由一个Header后跟多条Record组成,Header主要包含了Key classname,value classname,存储压缩算法,用户自定义元数据等信息,此外,还包含了一些同步标识,用于快速定位到记录的边界。每条Record以键值对的方式进行存储,用来表示它的字符数组可以一次解析成:记录的长度、Key的长度、Key值和value值,并且Value值的结构取决于该记录是否被压缩。
SEQUENCEFILE特点:
需要一个合并文件的过程,且合并后的文件不方便查看。
ORC 存储源自RC这种存储格式,RC是一种列式存储引擎,主要是在压缩编码,查询性能方面做了优化,但是对schema演化支持较差。ORC文件以二进制方式存储,所以是不可以直接读取,ORC文件也是自解析的,它包含许多的元数据,这些元数据都是同构ProtoBuffer进行序列化的。
源自google Dremel 系统,Parquet 相当一Dremel中的数据存储引擎,而Apache顶级开源醒目 Drill正式Dremel的开源实现。
Parquet文件格式包含一个header,多个blocks(row groups),一个footer。header仅仅包含4字节数字,表示这个文件是parquet格式。所有的文件元数据存储在footer中,文件元数据包含格式版本,schema,额外的key-value值,每个row group的元数据。footer还包含4字节文件元数据的编码长度,以及4字节的数字。
hive中指定存储格式和压缩的语法
CREATE [TEMPORARY] [EXTERNAL] TABLE [IF NOT EXISTS] [db_name.]table_name
[(col_name data_type [COMMENT col_comment], ... [constraint_specification])]
[COMMENT table_comment]
[PARTITIONED BY (col_name data_type [COMMENT col_comment], ...)]
[CLUSTERED BY (col_name, col_name, ...) [SORTED BY (col_name [ASC|DESC], ...)] INTO num_buckets BUCKETS]
[ROW FORMAT row_format]
[STORED AS file_format]
[LOCATION hdfs_path]
[TBLPROPERTIES (property_name=property_value, ...)]
[AS select_statement];
TEXTFILE
create table if not exists tmp_bdp.data_test (
json_cloumn string
)
row format delimited
fields terminated by '\t'
stored as textfile
tblproperties("textfile.compress"="NONE");
查看表详情
# Storage Information
SerDe Library: org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe
InputFormat: org.apache.hadoop.mapred.TextInputFormat
OutputFormat: org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat
Compressed: No
Num Buckets: -1
Bucket Columns: []
Sort Columns: []
插入数据,查看表大小
hadoop fs -du -s -h /path/
170G
修改压缩方式为lzo
ALTER TABLE tmp_bdp.data_test SET TBLPROPERTIES ('orc.compress'='LZO');
修改存储方式为ORC
ALTER TABLE tmp_bdp.data_test SET FILEFORMAT ORC;
查看格式是否改变
SerDe Library: org.apache.hadoop.hive.ql.io.orc.OrcSerde
InputFormat: org.apache.hadoop.hive.ql.io.orc.OrcInputFormat
OutputFormat: org.apache.hadoop.hive.ql.io.orc.OrcOutputFormat
Compressed: No
Num Buckets: -1
Bucket Columns: []
Sort Columns: []
格式+压缩 | 文件大小 |
---|---|
textfile+lzo | |
orc+lzo | 85.0G |
orc+snappy | 86.2G |
orc+tszd | 56.8G |
parquet+lzo | 89.4G |
parquet+snappy | 87.1G |
parquet+zstd | 52.8G |