HDFS的两大核心和元数据合并

文件上传过程：写

• 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第一次进行元数据合并的时候也会拉取这个文件