文件上传过程:写
- 1.客户端向namenode发送上传的请求
- 2.namenode进行一系列的检查(权限 文件的父目录是否存在,文件是否已经存在同名等等,检查通过则允许上传)
- 3.允许客户端上传
- 4.客户端发送真正的文件上传的请求,(请求中包含一个重要信息:文件的长度/大小)
- 5.namenode根据文件的长度计算文件的切块个数 文件的大小(200/128=2),获取副本的配置信息(dfs.replication=3),返回副本的节点的时候遵循:就近原则,客户端所在节点,不同机架
- 6.客户端准备文件上传
- 7.客户端对文件进行逻辑切块
- 逻辑切块:在形式上的切分(并没有真正的进行切分,只是一个范围的划分)
- 物理切块:对数据进行真正的切分的过程
- 8.开始上传第一个数据块
- 9.先构建第一个数据块上传的通道pipline,(客户端->向节点发),构建通道的时候,客户端启动搞一个阻塞进程,等待datanode的响应
- 10.开始第一个数据块的数据上传(客户端上传到datanode01,先上传到内存中,存在磁盘里,datanode03向01进行数据拷贝)【文件上传的过程以packet为单位进行传输的64K为单位进行写的】
- 11.第一个数据块上传成功,关闭当前的pipline
- 12.开始上传第二个数据块
- 13.重复9,10,11
- 14.当所有的数据块上传完成,客户端向namenode反馈
- 文件上传需要注意的问题:
- 1.构建pipline的过程中 blk:client->datanode01->datanode02->datanode03
- pipline中的某一个节点宕机了(通信失败),datanode01会立即重试一次,如果还失败,将这个节点剔除pipline重新构建( blk:client->datanode01->datanode03),至少保证pipline中有一个存货的节点就可以
- 2.进程整个文件的上传的过程中,只需要保证至少一个副本上传成功就认为整个数据块上传成功,其他副本集群中自动进异步复制
- 3.在进行文件上传的过程中,优先第一个副本的节点,是客户端所在的节点,(原因:保证副本最大程度的可以成功上传一个,就相当于本地复制的工作,不需要网络传输)
- 文件下载:
- 1.客户端向namenode发送文件下载的请求
- 2.namenode会进行一系列的检查(权限,文件是否都存在),检查没问题,返回需要下载的文件所分的数据块和数据块的存储的节点
- 3.客户端开始下载第一个数据块,就近原则,将第一个数据块写在本地文件中【流】
- 4.第一个数据块下载完成,下载第二个数据块。。。追加到第一个数据块的末尾的过程
- 5.所有的数据块下载完成,客户端向namenode响应
- 文件下载需要注意的问题:
- 1.文件校验的问题,以数据块为单位进行数据crc校验的
- 2.下载过程中,就近原则进行下载的,如果某一个数据块下载失败,默认重试三次,还失败,客户端将这个失败的datanode报告给namenode,namenode会做一个标记(以后将少访问这个 datanode),客户端会换一个datanode再次进行下载这个数据块,直到下载成功为止
- 元数据合并:
- 重点讲的是secondarynamenode
- 元数据:
- 1.抽象目录树
- 2.数据和块的对应关系
- 3.数据块的存储位置
- 存储目录上分:
- 元数据的存储位置:namenode节点上
- cd /home/bd1/data/hadoopdata/name/current/
- 4个部分:
- 1.edits部分:历史日志文件。记录所有的元数据的操作日志
- 2.inprogress部分:正在编辑的日志文件,目前正在编辑的,隔一定的时间间隔 或者 一定的数据条数间隔 会进行滚动(把正在你好编辑的回滚为历史日志文件)【回滚】
- 3.fsimage部分:元数据镜像,硬盘存储的元数据的一部分(序列化的文件不能直接查看)
- 4.seen_txid部分:合并点信息
- 合并点:下一次需要进行合并开始的日志文件的id
- fsimage文件=fsimage文件+edits文件合并得来的
- 元数据合并的时间:
- 1.时间间隔
- 2.元数据的条数
- 1.secondarynamenode定期向namenode发送检查,检查namenode的元数据是否需要合并,每5min发送一次
- 2.namenode需要进行元数据合并
- 3.secondarynamenode向namenode发送元数据合并的请求
- 4.namenode将正在编辑的日志文件回滚,变成历史日志文件同时生成全新的正在编辑的日志文件
- 5.将需要合并的文件(edits和fsimag)拉取到自己的本地
- 6.secondarynamenode将edits文件和fsimage文件进行合并在内存中,根部edtis文件的日志修改fsimage文件
- 7.将合并好的fsimag文件发送给namenode,自己本地也会保存一份
- 8.namenode将最新的fsimage文件进行重命名覆盖掉原来的fsimage文件
- 元数据合并的注意点:
- 1.集群启动完成之后,入股偶不是第一次元数据合并,这个时候元数据合并的时候只需要拉取合并点之后的edits文件即可
- 2.集群正常关闭的时候,要求fsimage文件时最新的最全的元数据信息
- 集群正常关闭的时候,内存中的元数据会序列化磁盘中,形成一个最新的fsimage文件,内存中的元数据会强行的刷出到磁盘中
- 下次集群启动的时候,加载这个最新的fsimage文件,secondarynamenode第一次进行元数据合并的时候也会拉取这个文件