7.hdfs工作流程及机制

1. hdfs基本工作流程

1. hdfs初始化目录结构

hdfs namenode -format 只是初始化了namenode的工作目录
而datanode的工作目录是在datanode启动后自己初始化的

namenode在format初始化的时候会形成两个标识：
blockPoolId：
clusterId：

新的datanode加入时，会获取这两个标识作为自己工作目录中的标识

一旦namenode重新format后，namenode的身份标识已变，而datanode如果依然
持有原来的id，就不会被namenode识别

2. hdfs的工作机制

1. hdfs集群分为两大角色:NameNode,DataNode (Secondary NameNode)
2. NameNode负责管理整个文件的元数据(命名空间信息，块信息) 相当于Master
3. DataNode负责管理用户的文件数据块 相当于Salve
4. 文件会按照固定的大小（block=128M）切成若干块后分布式存储在若干个datanode节点上
5. 每一个文件块有多个副本（默认是三个），存在不同的datanode上
6. DataNode会定期向NameNode汇报自身所保存的文件block信息，而namenode则会负责保持文件副本数量
7. hdfs的内部工作机制会对客户的保持透明，客户端请求方法hdfs都是通过向namenode申请来进行访问
8. SecondaryNameNode有两个作用，一是镜像备份，二是日志与镜像的定期合并

3. hdfs写入数据流程

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

4. 写入数据步骤详细解析

1. 客户端向namenode通信，请求上传文件，namenode检查目标文件是否已经存在，父目录是否存在
2. namenode返回给客户端，告知是否可以上传
3. 客户端请求第一个block该传输到那些datanode服务器上
4. namenode返回3个datanode服务器abc
5. 客户端请求3台datanode的一台a上传数据（本质上是一个rpc调用，建立pipeline），A收到请求后会继续调用b，然后b调用c，将整个pipeline建立完成，逐级返回客户端。
6. 客户端开始忘a上传第一个block（先从磁盘读取数据放入本地内存缓存），以packet为单位，a收到一个packet将会传给b，b传给c，a每传一个packet会放入一个应答队列等待应答
7. 宕一个block传输完之后，客户端再次请求namenode上传第二个block的服务器

5. hdfs读取数据流程

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

6. 读取数据详细步骤解析

1. 客户端跟namenode通信查询元数据，找到文件块所在的datanode服务器
2. 挑选一台datanode（就近原则，然后随机）服务器，请求建立socket流
3. datanode开始发送数据（从磁盘里面读取数据放入流，以packet为单位做校验）
4. 客户端以packet为单位接收，先在本地缓存，然后写入目标文件。

2. namenode工作机制

1. namenode常见问题

1. 集群启动后，可以查看文件，但是上传文件报错，打开web页面看到namenode正在处于sofemode状态，怎么处理？
2. namenode服务器磁盘故障导致namenode宕机，如何解决？
3. namenode是否可以有多个？
4. namenode内存要配置多大？
5. namenode跟集群数据存储能力有关系吗？
6. 文件的blocksize究竟调大好，还是调小好？

2. namenode的工作职责

1. 负责客户端的请求及相应
2. 元数据的管理（查询，修改）

3. 元数据管理

1. namenode对数据的管理采用三种存储形式
2. 内存元数据（NameSystem）
3. 磁盘元数据镜像文件
4. 数据操作日志文件（可通过日志运算出元数据）类似于mysql的binlog

4. 元数据存储机制

1. 内存中有一份完整的元数据（内存 metadata）
2. 磁盘有一个 “准完整” 的元数据镜像（fsimage）文件（在namenode工作目录中）
3. 用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志（edits log文件）
4. 当客户端对hdfs中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存metadata中

5. 元数据查看

1. hdfs oev -i edits_0000000000000000162-0000000000000000163 -o edits.xml
2. hdfs oiv -i fsimage_0000000000000000262 -p XML -o fsimage.xml

6.  元数据的checkpoint

1. 每隔一段时间，secondary namenode 将namenode上积累的所有edits和一个最新的fsimage下载到本地，并加载到内存进行merge（这个过程为checkpoint）
2. 详细过程
   

7. 解决namenode的灾难性错误的方法

1. 首先在hdfs-site.xml配置

   
            dfs.name.dir
            /data/hadoop/name1,/data/hadoop/name2
       
   

2. 停止集群

3. 重新格式化

   hadoop namenode -format

4. 开始集群

8. checkpoint操作的触发条件配置参数

#dfs.namenode.checkpoint.check.period=60  #检查触发条件是否满足的频率，60秒
#hdfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary
#以上两个参数做checkpoint操作时，secondary namenode的本地工作目录
#dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir}
#dfs.namenode.checkpoint.max-retries=3  #最大重试次数
#dfs.namenode.checkpoint.period=3600  #两次checkpoint之间的时间间隔3600秒
#dfs.namenode.checkpoint.txns=1000000 #两次checkpoint之间最大的操作记录

9. checkpoint的附带作用

1. namenode和secondary namenode的工作目录存储结构完全相同，所以当namenode故障退出需要重新恢复时，可以从secondary namenode 的工作目录将fsimage拷贝到namenode的工作目录。以恢复namenode的元数据

10. 元数据目录说明

1. 当第一次部署好hadoop集群的时候，在namenode上格式化硬盘后会在${dfs.namenode.name.dir}/current目录产生如下文件结构:

   #ls /tmp/hadoop-root/dfs/name/current
   ---VERSION
   ---edits_*
   ---fsimage_*
   ---seen_txid

2. dfs.namenode.name.dir在hdfs-site.xml文件中配置

   
       dfs.namenode.name.dir
        file://${hadoop.tmp.dir}/dfs/name
   

   注:dfs.namenode.name.dir的属性可以配置多个目录，每个目录存在的文件结构和内容都是一样的，相当于备份，好处是其中有一个目录损坏了，也不会影响到hadoop的元数据。

3. hadoop.tmp.dir在core-site.xml文件中配置

   
       hadoop.tmp.dir
       /tmp/hadoop-${user.name}
       A base for other temporary directories.
   

4. VERSION文件是java属性文件

   [root@hadoop-1 current]# cat VERSION
   #Thu Jun 22 11:42:19 EDT 2017
   namespaceID=1169207959
   clusterID=CID-ce01b250-9850-4da5-b81f-ab24905fbdd7
   cTime=0
   storageType=NAME_NODE
   blockpoolID=BP-1786918471-172.16.1.207-1498146139482
   layoutVersion=-63

   1. namespace

      文件系统的唯一标识符，在文件系统首次格式化后生成的

   2. StorageType

      说明这个文件存储的是什么进程的数据结构信息（如果是DataNode，storageType=DATA_NODE）；

   3. cTime

      NameNode存储时间的创建时间，由于我的NameNode没有更新过，所以这里的记录值为0，如果NameNode升级后，cTime将会记录更新时间戳

   4. layoutVersion

      HDFS永久性数据结构的版本信息，只要数据结构变更，版本号也要递减，此时的hdfs也需要升级，否则磁盘仍旧是使用旧版本的数据结构，这会导致新版本的NameNode无法使用。

   5. clusterID

      系统生成或者手动指定的集群id，在-clusterid选项中可以使用它

      1. $HADOOP_HOME/bin/hdfs namenode -format [-clusterId ]
      选择一个唯一的cluster_id，并且这个cluster_id不能与环境中其他集群有冲突。如果没       
      有提供cluster_id，则会自动生成一个唯一的ClusterID。
      2. 使用如下命令格式化其他Namenode：
       $HADOOP_HOME/bin/hdfs namenode -format -clusterId 
      3. 升级集群至最新版本。在升级过程中需要提供一个ClusterID，例如:                                  
      $HADOOP_PREFIX_HOME/bin/hdfs start namenode --config
      $HADOOP_CONF_DIR  -upgrade -clusterId 
      如果没有提供ClusterID，则会自动生成一个ClusterID。

   6. blockpoolID

      针对每一个NameSpace所对应的blockpool的ID，上面的这个
      BP-1786918471-172.16.1.207-1498146139482 就是我在ns1的namespace下的存储块池的ID，这个id包括了对应的namenode节点服务器ip地址

5. seen_teid文件

   存放transactionid的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾数，namenode重启的时候，会按照seen_txid的数字，循序从头跑edits_0000001~到seen_txid的数字。所以当你的hdfs发生异常重启的时候，一定要比对seen_txid内的数字是不是你edits最后的尾数，不然会发生建置namenode时metaData的资料有缺少，导致误删Datanode上多余Block.
   文件中记录的是edits滚动的序号，每次重启namenode时，namenode就知道要将哪些edits进行加载edits

6. current目录下在format的同时也好生成fsimage和edits文件及其对应的md5校验文件，

3. DataNode的工作机制

1. Datanode工作职责:

   存储管理用户的文件块数据
   定期向namenode汇报自身所持有的block信息（通过心跳信息上报）

2. Datanode掉线判断的时限参数：

   datanode进程死亡或网络故障造成datanode无法与namenode通信，namenode不会立即把该节点判断为死亡，要经过一段时间，它这段时间暂称为超时时长,hdfs默认的超时时长为10分钟+30秒，如果定义超时时间为timeout，则超时时长的计算公式为:
   timeout = 2* heartbeat.recheck.interval + 10 * dfs.heartbeat.interval

   默认的heartbeat.recheck.interval 大小为5分钟，dfs.heartbeat.interval默认为3秒

   需要注意的是 hdfs-site.xml配置文件中的heartbeat.recheck.interval的单位为毫秒
   dfs.heartbeat.interva的单位为秒，所以，举个例子，如果heartbeat.recheck.interval设置为5000（毫秒），dfs.heartbeat.interval设置为3（秒，默认），则总的超时时间为40秒。

转载于:https://www.cnblogs.com/liu-yao/p/7078217.html