hadoop文件格式和压缩

Hadoop中的文件格式大致上分为面向行和面向列两类：

面向行：TextFile、SequenceFile、MapFile、Avro Datafile

二进制格式文件大小比文本文件大。

生产环境常用，作为原始表的存储格式，会占用更多磁盘资源，对它的 解析开销一般会比二进制格式高 几十倍以上。

Hadoop API 提供的一种二进制文件，它将数据以<key,value>的形式序列化到文件中。这种二进制文件内部使用Hadoop 的标准的Writable 接口实现序列化和反序列化。它与Hadoop API中的MapFile 是互相兼容的。

MapFile即为排序后的SequeneceFile，它会额外生成一个索引文件提供按键的查找。文件不支持复写 *** 作，不能向已存在的SequenceFile(MapFile)追加存储记录，在执行文件写 *** 作的时候，该文件是不可读取的。

Avro是一种用于支持数据密集型的二进制文件格式。它的文件格式更为紧凑，若要读取大量数据时，Avro能够提供更好的序列化和反序列化性能。并且Avro数据文件天生是带Schema定义的，所以它不需要开发者在API 级别实现自己的Writable对象。最近多个Hadoop 子项目都支持Avro 数据格式，如Pig 、Hive、Flume、Sqoop和Hcatalog。

面向列：Parquet 、RCFile、ORCFile

RCFile是Hive推出的一种专门面向列的数据格式。 它遵循“先按列划分，再垂直划分”的设计理念。当查询过程中，针对它并不关心的列时，它会在IO上跳过这些列。

ORCFile （Optimized Record Columnar File)提供了一种比RCFile更加高效的文件格式。其内部将数据划分为默认大小为250M的Stripe。每个Stripe包括索引、数据和Footer。索引存储每一列的最大最小值，以及列中每一行的位置。

Parquet 是一种支持嵌套结构的列式存储格式。Parquet 的存储模型主要由行组（Row Group）、列块（Column Chuck）、页（Page）组成。

1、行组，Row Group：Parquet 在水平方向上将数据划分为行组，默认行组大小与 HDFS Block 块大小对齐，Parquet 保证一个行组会被一个 Mapper 处理。

2、列块，Column Chunk：行组中每一列保存在一个列块中，一个列块具有相同的数据类型，不同的列块可以使用不同的压缩。

3、页，Page：Parquet 是页存储方式，每一个列块包含多个页，一个页是最小的编码的单位，同一列块的不同页可以使用不同的编码方式。

一般原始表数据使用文本格式存储，其他的都是列式存储。

目前在Hadoop中常用的几种压缩格式：lzo，gzip，snappy，bzip2,主要特性对比如下：

其性能对比如下：

2.1 lzo

hadoop中最流行的压缩格式，压缩/解压速度也比较快，合理的压缩率，支持split。适用于较大文本的处理。

对于lzo压缩，常用的有LzoCodec和lzopCodec，可以对sequenceFile和TextFile进行压缩。对TextFile压缩后，mapred对压缩后的文件默认是不能够进行split *** 作，需要对该lzo压缩文件进行index *** 作，生成lzo.index文件，map *** 作才可以进行split。如果设置LzoCodec，那么就生成.lzo后缀的文件，可以用LzoIndexer 进行支持split的index计算，如果设置LzopCodec，那么生成.lzo_deflate后缀的文件，不支持建立index。

在大数据领域，无论上层计算引擎采用的是什么，在存储过程中，压缩都是一个避不开的问题。合适的压缩选择可以降低存储成本、减少网络传输I/O。而错误的压缩选择则可能让 cpu 负荷达到瓶颈、降低并发度等等，所以是否选择压缩、选择什么压缩格式在大数据存储环节中都是一个至关重要的问题。

点评：压缩时间和压缩率之间的取舍本质上是 cpu 资源和存储资源的取舍。是否需要支持分片也不是绝对的，如果单个文件大小均小于 splitSize，则没必要支持分片。

点评：一阶段考虑尽可能支持分片（单个文件大于 splitSize 时）。二阶段考虑尽可能快的压缩速度。三阶段根据是作为长期归档（几乎不用）or 作为下一作业输入，考虑尽可能高的压缩能力 or 支持分片。

点评：有两点需要注意，第一点：这里的速度和压缩率没有具体测试数据，而是给出了一个模糊的表达。因为即使具体测试了速度和压缩率，也会因数据不同而结果有很大的差异。后面会给出测试的脚本，大家可以结合自己的表数据自行测试。第二点：有些压缩格式性能参数很相似，为什么 Hadoop 中要搞这么多种？较为直观的一个原因是：不同存储格式支持的压缩是不一样的，比如 orc 存储格式只支持 zlib 和 snappy 两种压缩 [8] ，parquet 虽然支持很多压缩格式，但是不支持 bzip2 [7]

以下摘自《Hadoop The Definitive Guide》

重点阅读文中加粗片段。大致意思是：因为 gzip 压缩格式使用的 DEFLATE 压缩算法没办法做到随机任意读取，必须同步顺序读取。也就意味着没办法为每一个 block 创建一个分片(split)，然后为该分片启一个 mapper 去读取数据。所以即使 gzip 文件有很多 block，MR 程序也只会启动一个 Mapper 去读取所有的 block。也即 gzip 这种压缩格式不支持分片。相反的，如果压缩格式使用的算法支持随机任意读取，那么就可以为每一个 block 创建一个分片，同时启动一个 mapper 去读取数据，这样有多少个 block 就有多少个分片，就有多少个 mapper ，这些 mapper 并行读取数据，效率大大提升。上述涉及到几个小概念，接下来分别进行详述。

一句话总结: zlib、gzip 在大数据语境中都是一种 压缩格式 ，他们使用相同的 压缩算法: DEFLATE，DefaultCodec 是 zlib 使用的 编解码器 ，Gzip 使用的编解码器是 GzipCodec

我们知道，Hadoop 在任务切分时，是按照文件的粒度进行的。即一个文件一个文件进行切分。而每一个文件切分成几块，取决于 splitSize 的大小。比如两个文件，第一个文件 300M，第二个文件150M。分片大小是128M，那么对于第一个文件将会切分成3片（128M，128M，44M），第二个文件会切分成2片（128M，22M）。共计5片。所以分片数量除了由文件数决定，另一个决定因素就是 splitSize 即分片大小。

splitSize 如何计算？

几个前提：

影响参数：

接下来进行实际验证：

经过了 2.4.2 中的一系列实验，验证了一个结论：当一个输入格式支持分片时，mapper 数量是无限制的，反之 mapper 数量小于等于文件的数量。所以我们可以通过设置参数来试图调小分片大小来增加 mapper 数量看其上限是否等于文件数量即可。假如输入的文件个数只有一个，那么当 mapper 数量大于1的时候，说明该输入格式是支持分片的。

大家可以根据自己数据集和想测试的压缩和存储格式自行修改脚本。通过以上脚本跑出来的结果如下：

由 2.1 中评价压缩的三项指标可知，压缩率、压缩/解压速度、是否支持分片是衡量压缩最重要的三项指标。3.1.1小节中只对压缩率进行了测试。压缩/解压速度可以通过跑一些查询语句进一步测试。这里就不展开测试了。业界中常用的存储格式一般是 parquet, orc,所以上面测试除了纯文本只测试了这两种存储格式。

我们可以通过 hive>set io.compression.codecs来查看当前Hadoop集群支持的压缩，在公司的集群中查询得到的结果是：

可以看到 lzo 有两种编解码器: LzoCodec 和 LzopCodec。他们之间有什么区别呢？

如果你阅读过关于 Hadoop 压缩的文章，应该可以看到，绝大多数文章中对于 snappy 是否支持分片都是直接给出的否定的答案。 CDH 的文档中也指出来 snappy 是不支持分片的。

看文中加粗片段，虽然 snappy 本身是不支持分片的，但是如果 snappy 存储在一些特定的存储格式比如 SequenceFile 或者 Avro 中，那么是可以支持分片的。也就是说 snappy 是否支持分片是分情况讨论的。不能说使用了 snappy 压缩就一定不支持分片。前面提到了，业界中常用的存储格式一般是 parquet 或者 orc，而上面 CDH 的文章中恰恰没有提到 parquet 和 orc 是否支持，接下来以 parquet 为例，进行测试。测试内容即为 parquet + snappy 组合，是否支持分片。

首先准备数据，因为之前做压缩率测试，已经有了 parquet + snappy 文件了，这里直接拿来用。

一共3个输入文件，启了6个mapper，说明输入文件是可以分片的。即 parquet + snappy 的组合是支持分片的。在《Hadoop The Definitive Guide》中也对 parquet 是否支持分片有说明：

以 mapreduce.output.fileoutputformat.compress.codec 为例，这个参数可以在三个地方配置：

那么当三者都设置时，以哪个为准呢？按照经验来看，一定是粒度小的优先级大于粒度大的优先级。经过测试也验证了这种猜测。即：表级别 >hive >hadoop

初学者往往容易混淆存储格式和压缩格式之间的关系，其实二者是完全独立的。如果完整的阅读了该篇文章，应该已经消除了这一块理解对误区。这里总结一下：比如 parquet, orc，他们都是常见的 存储格式 。是否使用压缩，使用何种压缩都是可以设置的。而 zlib、gzip、lzo、lz4、snappy 等等这些都是常见的 压缩格式 ，他们既可以依附于某些 存储格式 ，比如之前提到的 parquet + snappy，orc + zlib 等等。也可以脱离特定的 存储格式 ，比如纯文本文件进行压缩，text + parquet, text + bzip2 等等。

---