Hadoop压缩格式中“是否可切分”字段说明

文件压缩有两个好处：减少存储文件所需的磁盘空间，并加速数据在网络和磁盘上的传输
在存储中，所有算法都要权衡空间/时间；在处理时，所有算法都要权衡CPU/传输速度

以下列出了与Hadoop结合使用的常见压缩方法：

压缩格式	工具	算法	文件扩展名	是否可切分
DEFLATE	无	DEFLATE	.deflate	否
Gzip	gzip	DEFLATE	.gz	否
bzip2	bzip2	bzip2	.bz2	是
LZO	lzop	LZO	.lzo	否
LZ4	无	LZ4	.lz4	否
Snappy	无	Snappy	.snappy	否

---

上述表格中，其他的几列倒容易理解，但是“是否可切分”具体是什么概念呢？
官方的说法：对应的压缩算法是否可以搜索数据流的任意位置并进一步往下读取数据。

---

以下举个例子来进行说明：

• 以一个存储在HDFS文件系统中且不进行压缩的大小为 1 GB 的文件为例。如果HDFS的块大小设置为128，那么该文件将被存储在8个块中，把这个文件作为输入数据的MapReduc/Spark作业，将创建8个map/task任务，其中每个数据块对应一个任务作为输入数据。
• 现在，假如经过gzip压缩后，文件大小为1GB。与之前一样，HDFS也是将这个文件存储成8个数据块。但是每个单独的map/task任务将无法独立于其他任务进行数据处理，官方一点的说法，原因就是因为数据存储在HDFS时是被切成块的，且该压缩算法无法从任意进行读取。
• 通俗的讲解，就是因为存储在HDFS的每个块都不是完整的文件，我们可以把一个完整的文件认为是具有首尾标识的，因为被切分了，所以每个数据块有些有头标示，有些有尾标示，有些头尾标示都没有，所以就不能多任务来并行对这个文件进行处理。 对于这种不可切分的，只有将该文件的所有HDFS的数据块都传输到一个map/task任务来进行处理，但是大多数数据块都没有存储在这个任务的节点上，所以需要跨节点传输，且不能并行处理，因此运行的时间可能很长。

---

有一个需要注意的，就是LZO压缩的，我们会面临相同的问题，因为这个压缩格式也不支持数据读取和数据流同步。但是，在预处理LZO文件的时候使用包含在 Hadoop LZO 库文件中的索引工具是有可能的，该工具构建了切分点索引，如果使用恰当的任务输入格式，那么可以有效实现文件的可切分特性。