hdfs合并块_hdfs两大核心-文件上传和文件下载以及元数据合并

hdfs两大核心

1、文件上传 (写)

hadoop fs -put

1、客户端向namenode发送文件上传请求

2、namenode对发送的请求进行检查

1、目录是否存在

2、权限

3、检查父目录

之后向客户端返回检查成功的消息

3、客户端真正的提交上传文件请求，包括文件大小

4、namenode计算文件的切块个数，向上取整。获取副本个数(配置文件中hdfs-site.xml)

返回给客户端数据块id以及存储的的节点信息

节点选择优先原则：

1、距离近的优先返回

2、之后顺序同节点->同机架->同机房

5、客户端准备文件上传，首先对文件进行逻辑切块

6、真正上传文件

1、准备上传第一个数据块

2、客户端构建数据块上传的通道(pipeline)，同时开启守护进程，等待pipeline构建完成的响应

pipeline构建过程：

客户端->第一个副本节点->第二个副本节点->……

3、pipeline构建完成，开始上传数据块，上传的时候是边上传边划分，以packet(64k)为单位上传，因为写数据比较慢，所以借助队列，客户端先将数据放在数据队列中。

4、客户端将数据块以packet为单位按照pipeline构建顺序传递。在节点间的传递中，内存中的数据是边向磁盘写入，边向下一个副本节点发送

5、重复以上的1-4步，知道所有的数据块上传成功

7、 整个文件上传成功，向客户端反馈，同时namenode修改元数据信息

文件上传过程中存在的问题：

1、数据传输或者构建pipeline过程中，发现有一个datanode宕机，则立即重启，如果重启后通信仍然存在问题，则将这个有问题的datanode剔除出pipeline，重新构建pipeline

2、上传中，只要保证有一个副本成功即可，失败的副本重新向namenode申请节点，namenode重新分配节点，datanode间异步复制

3、在给数据块分配节点时，为了减少传输失败的问题，将第一个副本放在客户端所在节点，至少保证一个副本上传成功

2、文件下载(读)

hadoop fs -get

1、客户端向namenode发送文件下载请求

2、namenode查询元数据进行校验，存在返回对应文件的数据块id以及对应的副本节点

3、客户端开始第一个数据块的下载，与对应的副本节点通信下载，会优先选择距离近的节点

4、第一个数据块下载完成后，进行crc校验，校验通过，才下载成功

5、重复3-4步，下载的数据会自动追加到本地的前一个数据块的末尾

6、所有的数据块下载完成，返回消息给客户端，关闭资源

文件下载过程中，发现有一个数据块节点有故障：

1、客户端立即读取其他副本所在的其他节点

2、将宕机的datanode节点汇报给namenode，之后请求节点的时候，namenode将不会优先该节点

3、元数据合并(checkpoint)

元数据

1、元数据按功能分用来存储以下内容：

1、抽象目录树

2、数据和数据块的关系

3、数据块的存储位置

2、元数据存储位置：

1、内存

2、磁盘

3、磁盘上存储元数据的文件

1、edits_0000000000000000001-0000000000000000002

元数据历史日志文件

2、edits_inprogress_0000000000000003741

正在编辑的日志文件，默认情况下1h回滚一次

3、fsimage_0000000000000003740

镜像文件，真正的元数据文件，存储了1)抽象目录树、2)数据和数据块的关系，不是全部的元数据信息

4、 fsimage_00000000000000003740.md5

加密文件

5、seen_txid：

当前日志文件的最大编号，是数据回滚的日志文件的起始编号

6、VERSION：

元数据的版本信息

元数据文件编号

fsimage文件编号从0开始，后续的编号是每次合并的edits的最大编号。fsimage最开始的文件是hdfs格式化生成的。fsimage先存在。

edits文件编号是从0开始递增

集群关闭时，内存中的元数据释放，下次启动时，内存需要从磁盘中获取最新的元数据，从磁盘中加载的是编号最大的fsimage文件+edits(fsimage的编号+1~seen_txid)这部分的edits文件，此时namenode是边加载边修改的，保证内存中的数据最新的

元数据写入

客户端进行写入操作，请求中需要修改元数据的时候

hadoop fs -mkdir|put|rm|touchz……

1、客户端发送修改元数据的请求，内存中的元数据是最新最全的

2、客户端先修改内存中的元数据，速度快

3、客户端修改磁盘中的元数据，不是直接修改fsimage，是先将执行的操作记录在edits_inprogress中，因此faimage中的数据不是最新的，每隔一段时间会将fsimage和edits文件进行合并

4、合并过程是在secondarynamenode中进行的

元数据真正的合并

合并的触发默认条件是(满足以下一条即触发)：

1)时间间隔 每隔1h进行一次元数据合并的工作

dfs.namenode.checkpoint.period3600The number of seconds between two periodic checkpoints.

2)日志条数间隔 100w

dfs.namenode.checkpoint.txns1000000The Secondary NameNode or CheckpointNode will create a checkpoint of the namespace every 'dfs.namenode.checkpoint.txns' transactions, regardless of whether 'dfs.namenode.checkpoint.period' has expired.

1、secondarynamenode定期向namenode发送元数据合并的请求

2、namenode检查是否需要合并，即是否满足触发条件，当满足任意一条触发条件时，namenode向secondarynamenode发送元数据合并的请求

3、secondarynamenode真正的发送元数据合并的请求

4、namenode将edits_inprogress回滚为edits文件，同时生成一个新的edits_inprogress，继续接受客户端对元数据修改的日志，不参与合并过程

5、secondarynamenode将需要进行合并的元数据edits和fsimage文件拉取到本地，拉取的是fsimage的编号+1~最新回滚的edits的编号之间的edits文件

6、secondarynamenode将拉取到的数据加载到内存中进行合并，根据edits文件修改fsimage中的数据

7、合并完成，将fsimage文件重命名，编号是最大的edits文件所对应的编号，同时在自己的磁盘中存储一份