Hadoop下的数据存储格式LZO

0x1 为什么要使用压缩技术?

压缩技术能够有效减少底层存储系统(HDFS)读写字节数. 压缩提高了网络带宽和磁盘空间的效率

MR中的场景 (I/O,网络数据传输,Shuffle,Merge)

用CPU换I/O

0x2 流行压缩技术1-Snappy

高速压缩速度,合理的压缩率

性能最高,但是不支持切片(split)

0x3 流行压缩技术2-Lzo[在这里重点说明]

3.1 概要

Hadoop体系下支持Lzo,需要安装

特点: 压缩/解压速度比较快,支持split

3.2 详解

优点:压缩/解压缩速度也比较快,合理的压缩率,支持split,是Hadoop中比较流行的压缩格式,可以再Linux中安装lzop命令,使用方便

缺点:压缩率比Gzip要低一些,Hadoop本身不支持,需要安装;在应用中对Lzo格式的文件需要做一些特殊处理(为了支持Split需要建立索引,还需要指定InputFormat为Lzo格式.

应用场景:一个很大的文本文件,压缩之后还大于200M以上的可以考虑,而且单个文件越大,lzo优点越明显.

看到这里肯定冒出几个问题

3.2.1 LZO的压缩速度快,快多少呢,如何跟其他的压缩格式相比?

直接上数据

压缩格式	算法	文件扩展名	是否可切分
DEFLATE	DEFLATE	.deflate	否
Gzip	DEFLATE	.gz	否
bzip2	bzip2	.bz2	是
==LZO==	LZO	.lzo	是
Snappy	Snappy	.snappy	否

为了支持多种压缩/解压缩算法，Hadoop引入了编码/解码器，如下表所示：

压缩格式	对应的编码/解码器
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

压缩性能的比较：

压缩算法	原始文件大小	压缩文件大小	压缩速度	解压速度
gzip	8.3GB	1.8GB	17.5MB/s	58MB/s
bzip2	8.3GB	1.1GB	2.4MB/s	9.5MB/s
LZO	8.3GB	2.9GB	49.3MB/s	74.6MB/s

3.2.2 LZO的比较好用,在大数据体系中哪些地方可以使用,如何使用?

1.Hive建表中可以直接导入HDFS中lzo格式的数据(要想走计算引擎需要增加索引)

2.Flume采集可以直接转换采集格式放入HDFS(hdfs sink)

参数在这里不多赘余,上链接

https://cwiki.apache.org/confluence/display/Hive/LanguageManual+LZO#space-menu-link-content

3.2.3 LZO为什么靠什么进行切片,为什么切片后能够被Driver进行Split[精]

0x4 文件存储格式(列存储的两种)

(TEXTFILE 、SEQUENCEFILE、ORC、PARQUET)

行存储跟列存储 Row layout/Column layout

4.1 ORC

Orc (Optimized Row Columnar)是Hive 0.11版里引入的新的存储格式。如下图所示可以看到每个Orc文件由1个或多个stripe组成，每个stripe一般为HDFS的块大小，每一个stripe包含多条记录，这些记录按照列进行独立存储，对应到Parquet中的row group的概念。每个Stripe里有三部分组成，分别是Index Data，Row Data，Stripe Footer