HDFS两大核心
- 文件上传操作
-
- 1.客户端发送文件上传的请求给namenode
- 2.namenode会进行一系列的检查,文件是否存在,父目录,权限等
- 3.检查通过 namenode向客户端返回相应
- 4.客户端开始发送真正的文件上传请求
-
-
- 请求中包含了一个重要的内容,文件长度(分块个数 --> 存储的节点)
-
-
- 5.namenode开始进行计算,并向客户端返回每一个数据块的存储节点及数据块的id
-
-
- 200M/128=2 副本2
- blk_172872 hadoop01 hadoop02
- blk_172873 hadoop03 hadoop02
-
-
- 6.客户端准备上传
- 7.客户端先对数据进行逻辑分块
- 8.客户端开始准备上传第一个数据块
- 9.客户端开始构建第一个数据块的管道(pipeline),客户端开启一个后台进程,等待pipeline构建完成的相应
- 10.客户端开始文件上传,开启一个后台进程,等待第一个数据块上传完成响应的
-
-
- 写入方向(过程):
-
· 以packet为单位进行数据写入(64kb),客户端--第一个副本---第二个副本---先写入内存 内存--->磁盘 写入datanode01
-
- 11.第一个数据块上传完成,关闭当前的pipeline
- 12.开始准备上传第2个数据块(步骤同8、9、10)
- 13.所有的数据块上传完成,客户端向namenode发送响应,namenode修改元数据信息
- 文件下载操作
-
- 1.客户端向namenode发送文件下载的请求
- 2.namenode会进行检查,检查通过,向客户端返回相应的数据对应的块及数据块的存储节点
-
-
- hadoop.tar.gz blk_123 :[hadoop01, hadoop02]
- blk_124 :[hadoop02,hadoop03]
-
-
- 3.客户端开始进行第一个数据块的下载,到对应的节点上下载(优先选择距离较近的节点) --->datanode01
-
-
- 从datanode上读取写出到本地文件中
-
-
- 4.第一个数据块下载完成开始下载第二个数据块--->datanode02
-
-
- 从datanode读,写出到本地的文件追加写入到第一个数据块的末尾的
-
-
- 5.所有的数据块下载完成,文件就下载完成,关闭对应的资源
- 物理分块:
-
- 真实存在的切分,数据被真正的分成了多个块(多个部分)
- HDFS数据的分块存储
- Hadoop 200M
- blk01 128M
- blk02 72M
- 逻辑分块:
-
- 逻辑上的概念,相当于一个区域、范围的划分,并没有对数据进行真正的切分
- 文件上传注意的问题:
-
- 1)文件上传过程中的物理切块问题:
-
-
- 边上传变切分的过程,文件切块是客户端负责的
-
-
- 2)pipeline构建的问题:
-
-
- blk01 : hadoop01 hadoop02 hadoop03
- 客户端 ---> 第一个副本 ---> 第二个副本 ---> 第三个副本
- client ---> hadoop01 ---> hadoop03 ---> hadoop04
- 发现pipeline中某一个节点有问题,hadoop03有问题,尝试重试2次,2次通信都有问题,将hadoop03剔除出pipeline,重新构建pipeline
- client ---> hadoop01 --->hadoop04
-
-
- 3)上传过程中的最低保障:
-
-
- 每一个数据块至少有一个数据块副本上传成功就认为成功
- 副本存放策略第一个副本优先放置在客户端所在节点就是为了保证数据上传成功的几率
- 第一个副本放在客户端所在节点就相当于本地复制
- 将数据从本地的原始路径复制到/home/hadoop/data/hadoopdata/data/
- 其他副本自己进行异步复制(datanode之间)
-
- 文件下载注意的问题:
-
- 节点分配问题:
-
-
- 存几个副本则返回这个数据块的几个存储节点
- 返回节点的时候有优先级的问题:距离+空间(综合考虑)
-
· 1)优先返回客户端所在的节点
· 2)返回同机架节点
· 3)不同机架的节点
-
- 返回节点:客户端所在存储数据块副本节点 返回同机架 不同机架
- 文件下载异常:
-
-
- 第一个数据的副本下载失败,重试,不成功,换另一个副本的节点下载同时客户端将这个节点报告给namenode,namenode会对之进行标识,后续减少该节点的操作
-
-
- 注意:文件下载的时候,每一个数据块读取完成都会进行crc文件校验