总结HDFS的IO操作

最新推荐文章于 2022-12-14 11:10:18 发布

qq_33069917

最新推荐文章于 2022-12-14 11:10:18 发布

阅读量1.7k

点赞数

分类专栏：大数据

大数据专栏收录该内容

3 篇文章 0 订阅

订阅专栏

数据完整性

用户希望储存和处理数据的时候，不会有任何损失或者损坏。
Hadoop提供两种校验：
1. 校验和（常用循环冗余校验CRC-32）
2. 运行后台进程来检测数据块

HDFS是用CRC-32(32位循环冗余校验，4个字节大小)作为其数据完整性校验方式，下面分两种常态情况介绍其校验过程：

IO操作

在通过client向DataNode节点写数据时，会先在client端针对写的数据每个io.bytes.per.checksum(默认512字节)字节创建一个单独的校验和，并将该校验和同数据本身一起传送给DataNode，DataNode接收数据时，会自行再次按照io.bytes.per.checksum字节创建一个校验和，通过两个校验和的比较，判断数据是否完整传输，如果两者相同，那么正确写入block，同时针对每个hdfs上的文件，会产生一个已.filename.crc为文件名的隐藏校验和文件，crc文件位于本地文件系统，hdfs上面无法直接查看；如果两者不同，那么会抛出ChecksumException给client，告知client传输出错。
在通过client从DataNode读取数据时，DataNode会将读取数据以及其校验和一起送给client，client本身再次创建校验和，同传送过来的校验和比较，判断读取数据是否完整，判断方式和写数据一样。在读取文件时，可以使用忽略crc校验，加快读取速度。
数据存储在磁盘上

存储在磁盘上的数据并不是一定安全，也可能随着时间的流逝，磁盘出现硬件损坏等原因，导致数据丢失或者不可用。DataNode节点在启动是，会顺便启动一个DataBlockScanner线程，该线程按照校验和的方式定时检测DataNode节点上的所有block块信息是否完整，如果存在不完整的block，标记之，同时发送信息给NameNode，由NameNode发出命令复制该block其他的备份副本来“治愈”这个问题。
为了提高系统性能，避免数据节点在启动后对还没有过期的数据块又扫描一遍，DataBlockScanner在其内部使用了日志记录器来持久化保存每一个数据块上一次扫描的时间

文件格式

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

面向行：同一行的数据存储在一起，即连续存储。

SequenceFile,MapFile,Avro Datafile。采用这种方式，如果只需要访问行的一小部分数据，亦需要将整行读入内存，推迟序列化一定程度上可以缓解这个问题，但是从磁盘读取整行数据的开销却无法避免。面向行的存储适合于整行数据需要同时处理的情况。
面向列：整个文件被切割为若干列数据，每一列数据一起存储。

Parquet , RCFile,ORCFile。面向列的格式使得读取数据时，可以跳过不需要的列，适合于只处于行的一小部分字段的情况。但是这种格式的读写需要更多的内存空间，因为需要缓存行在内存中（为了获取多行中的某一列）。同时不适合流式写入，因为一旦写入失败，当前文件无法恢复，而面向行的数据在写入失败时可以重新同步到最后一个同步点，所以Flume采用的是面向行的存储格式。

Sequence file
Sequence file由一系列的二进制key/value组成，如果key为小文件名，value为文件内容，则可以将大批小文件合并成一个大文件。Hadoop-0.21.0版本开始中提供了SequenceFile，包括Writer，Reader和SequenceFileSorter类进行写，读和排序操作。该方案对于小文件的存取都比较自由，不限制用户和文件的多少，支持Append追加写入，支持三级文档压缩（不压缩、文件级、块级别）。

这里写图片描述

文件中每条记录是可序列化,可持久化的键值对,提供相应的读写器和排序器,写操作根据压缩的类型分为3种：

Write 无压缩写数据
RecordCompressWriter记录级压缩文件,只压缩值
BlockCompressWrite块级压缩文件,键值采用独立压缩方式

在储存结构上,sequenceFile主要由一个Header后跟多条Record组成。

这里写图片描述

前三个字节是一个Bytes SEQ代表着版本号，同时header也包括key的名称，value class , 压缩细节，metadata，以及Sync markers。Sync markers的作用在于可以读取任意位置的数据。
　在recourds中，又分为是否压缩格式。当没有被压缩时，key与value使用Serialization序列化写入SequenceFile。当选择压缩格式时，record的压缩格式与没有压缩其实不尽相同，除了value的bytes被压缩，key是不被压缩的。

当保存的记录很多时候，可以把一串记录组织到一起同一压缩成一块。
　　在Block中，它使所有的信息进行压缩，压缩的最小大小由配置文件中，io.seqfile.compress.blocksize配置项决定。

MapFile
MapFile是SequenceFile的变种，在SequenceFile中加入索引并排序后就是MapFile。索引作为一个单独的文件存储，一般每个128个记录存储一个索引。索引可以被载入内存，用于快速查找。存放数据的文件根据Key定义的顺序排列。
MapFile的记录必须按照顺序写入，否则抛出IOException。

一个MapFile可以通过SequenceFile的地址，进行分类查找的格式。使用这个格式的优点在于，首先会将SequenceFile中的地址都加载入内存，并且进行了key值排序，从而提供更快的数据查找。
与SequenceFile只生成一个文件不同，MapFile生成一个文件夹。
索引模型按128个键建立的，可以通过io.map.index.interval来修改
缺点
1. 文件不支持复写操作，不能向已存在的SequenceFile(MapFile)追加存储记录
2. 当write流不关闭的时候，没有办法构造read流。也就是在执行文件写操作的时候，该文件是不可读取的

这里写图片描述

排序后的SequeneceFile,并且它会额外生成一个索引文件提供按键的查找.读写mapFile与读写SequenceFile
非常类似，只需要换成MapFile.Reader和MapFile.Writer就可以了。
在命令行显示mapFile的文件内容同样要用 -text

mapFile既然是排序和索引后的SequenceFile那么自然可以把SequenceFile转换为MapFile使用mapFile.fix()方法把一个SequenceFile文件转换成MapFile

压缩

我们会在 hadoop 系统中对数据进行压缩处理来优化磁盘使用率，提高数据在磁盘和网络中的传输速度，从而提高系统处理数据的效率。在使用压缩方式方面，主要考虑压缩速度和压缩文件的可分割性。综合所述，使用压缩的优点如下：
1. 节省数据占用的磁盘空间；
2. 加快数据在磁盘和网络中的传输速度，从而提高系统的处理速度。
Hadoop 对于压缩格式的是自动识别。如果我们压缩的文件有相应压缩格式的扩展名（比如 lzo，gz，bzip2 等）。Hadoop 会根据压缩格式的扩展名自动选择相对应的解码器来解压数据，此过程完全是 Hadoop 自动处理，我们只需要确保输入的压缩文件有扩展名。
Hadoop 对每个压缩格式的支持, 详细见下表：

http://blog.csdn.net/oh_mourinho/article/details/52525203

Hadoop 下各种压缩算法的压缩比，压缩时间，解压时间见下表:
因此我们可以得出：
1) Bzip2 压缩效果明显是最好的，但是 bzip2 压缩速度慢，可分割。
2) Gzip 压缩效果不如 Bzip2，但是压缩解压速度快，不支持分割。
3) LZO 压缩效果不如 Bzip2 和 Gzip，但是压缩解压速度最快！并且支持分割！

这里提一下，文件的可分割性在 Hadoop 中是很非常重要的，它会影响到在执行作业时 Map 启动的个数，从而会影响到作业的执行效率！

所有的压缩算法都显示出一种时间空间的权衡，更快的压缩和解压速度通常会耗费更多的空间。在选择使用哪种压缩格式时，我们应该根据自身的业务需求来选择。

使用哪种压缩和具体应用有关，对于巨大，没有储存边界的文件如日志可以考虑：