HDFS 中常用的数据压缩算法分为可拆分和不可拆分两类。Snappy 具有高压缩速度和
较好的压缩率。它在速度和压缩率之间作了较好的权衡。由于 Snappy 是不可拆分算法,即压
缩后的文件不可拆分,它需要在一个特定的文件格式(如 Parquet、ORC)中使用。LZO 和
Snappy 类似,比较注重压缩速度。不同的是 LZO 压缩后的文件是可拆分的.因此相对于
Snappy，LZO 更适合用作一个独立的压缩格式来对 HDFS 上的文本格式的文件进行压
缩.Gzip 提供了较高的压缩性能,平均达到 Snappy 的 2.5 倍,但是它的写入性能不如 Snappy.
在读性能方面,Gzip 和 Snappy 接近。Gzip 同样是不可拆分算法,因此也需要嵌入在一个文
件格式中使用。在部分情况下 Gzip 的压缩效果太好,导致压缩出的数据很小、数据块数很少,
所以在执行数据处理任务时的并行度可能会偏低，从而导致数据处理的速度反而降低[38].
这个问题可以通过使用较小的数据块来避免.bzip2 提供了非常好的压缩性能,但是其解压性
能较差,通常只用于存储空间非常有限的情况。
4 HDFS 的应用、分析及改进
HDFS 改进方案 1：通过改进 HDFS 元数据管理方案，来负责存储和管理大数据。由于
当前的 HDFS 基于元数据管理，因此 HDFS 在系统利用率方面还存在许多问题。现有一种
基于 RDBMS 的方式改善 HDFS 的功能方面。众所周知，现有的 HDFS 存在五个问题。第
一个问题是，因为现有的 HDFS 加载了所有元数据进入 NameNode，因此主内存中的文件
（或目录）数可能会受到限制。二是现有的 HDFS 管理的元数据在复杂的映像和日志文件
中，这会导致较长的引导时间去查找元数据。三是现有系统只能通过命令来搜索或修改元数
据，并且这种基于命令的方案对于分布式的环境具有很高的依赖性。四是由于 Hadoop 管理
元数据在单个 NameNode（或在联合模式下的一个或多个单独的 NameNode）中，对 HDFS
的所有访问请求都需要通过相应的 NameNode。这种访问结构严重限制了 Hadoop 的可扩展
性。五是所有对文件的查看都需要通过 HDFS，不能用户单独操作文件。综合起来即鲁棒性，
依赖性和可扩展性三项问题。现我们考虑一种新型的 HDFS 架构，如图：
评论0