3.5 深刻理解HDFS工作机制

深入理解一个技术的工作机制是灵活运用和快速解决问题的根本方法,也是唯一途径。对于HDFS来说除了要明白它的应用场景和用法以及通用分布式架构之外更重要的是理解关键步骤的原理和实现细节。

3.5.1 HDFS数据写入过程分析

客户端要向HDFS写数据,首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode,然后客户端按顺序将文件逐个block传递给相应datanode,并由接收到block的datanode负责向其他datanode复制block的副本。

1)客户端向namenode发送上传文件请求,namenode对要上传目录和文件进行检查,判断是否可以上传,并向客户端返回检查结果。

2)客户端得到上传文件的允许后读取客户端配置,如果没有指定配置则会读取默认配置(例如副本数和块大小默认为3和128M,副本是由客户端决定的)。向namenode请求上传一个数据块。

3)namenode会根据客户端的配置来查询datanode信息,如果使用默认配置,那么最终结果会返回同一个机架的两个datanode和另一个机架的datanode。这称为“机架感知”策略。

4)客户端在开始传输数据块之前会把数据缓存在本地,当缓存大小超过了一个数据块的大小,客户端就会从namenode获取要上传的datanode列表。之后会在客户端和第一个datanode建立连接开始流式的传输数据,这个datanode会一小部分一小部分(4K)的接收数据然后写入本地仓库,同时会把这些数据传输到第二个datanode,第二个datanode也同样一小部分一小部分的接收数据并写入本地仓库,同时传输给第三个datanode,依次类推。这样逐级调用和返回之后,待这个数据块传输完成客户端后告诉namenode数据块传输完成,这时候namenode才会更新元数据信息记录操作日志。

5)第一个数据块传输完成后会使用同样的方式传输下面的数据块直到整个文件上传完成。

3.5.2 HDFS数据读取过程分析

客户端将要读取的文件路径发送给namenode,namenode获取文件的元信息(主要是block的存放位置信息)返回给客户端,客户端根据返回的信息找到相应datanode逐个获取文件的block并在客户端本地进行数据追加合并从而获得整个文件。

1)客户端向namenode发起RPC调用,请求读取文件数据。

2)namenode检查文件是否存在,如果存在则获取文件的元信息(blockid以及对应的datanode列表)。

3)客户端收到元信息后选取一个网络距离最近的datanode,依次请求读取每个数据块。客户端首先要校检文件是否损坏,如果损坏,客户端会选取另外的datanode请求。

4)datanode与客户端建立socket连接,传输对应的数据块,客户端收到数据缓存到本地,之后写入文件。

5)依次传输剩下的数据块,直到整个文件合并完成。

3.5.3 HDFS删除数据过程分析

HDFS中的数据删除也是比较有特点的,并不是直接删除,而是先放在一个类似回收站的地方(/trash),可供恢复。

对于用户或者应用程序想要删除的文件,HDFS会将它重命名并移动到/trash中,当过了一定的生命期限以后,HDFS才会将它从文件系统中删除,并由Namenode修改相关的元数据信息。并且只有到这个时候,Datanode上相关的磁盘空间才能节省出来,也就是说,当用户要求删除某个文件以后,并不能马上看出HDFS存储空间的增加,得等到一定的时间周期以后(现在默认为6小时)。

对于备份数据,有时候也会需要删除,比如用户根据需要下调了Replicaion的个数,那么多余的数据备份就会在下次Beatheart联系中完成删除,对于接受到删除操作的Datanode来说,它要删除的备份块也是先放入/trash中,然后过一定时间后才删除。因此在磁盘空间的查看上,也会有一定的延时。

那么如何立即彻底删除文件呢,可以利用HDFS提供的Shell命令:bin/Hadoopdfs expunge清空/trash。

results matching ""

    No results matching ""