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的工作机制

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

3. hdfs写入数据流程

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

-w 1000

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

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

5. hdfs读取数据流程

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

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

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

2. namenode工作机制

1. namenode常见问题

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

2. namenode的工作职责

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

3. 元数据管理

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

4. 元数据存储机制

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

5. 元数据查看

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

6. 元数据的checkpoint

每隔一段时间，secondary namenode 将namenode上积累的所有edits和一个最新的fsimage下载到本地，并加载到内存进行merge（这个过程为checkpoint）
详细过程
![图片 1](http://img.liuyao.me/图片 1.png)

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

首先在hdfs-site.xml配置

<property>
         <name>dfs.name.dir</name>
         <value>/data/hadoop/name1,/data/hadoop/name2</value>
    </property>

停止集群
重新格式化
```
hadoop namenode -format
```
开始集群

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的附带作用

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

10. 元数据目录说明

当第一次部署好hadoop集群的时候，在namenode上格式化硬盘后会在${dfs.namenode.name.dir}/current目录产生如下文件结构:
```
#ls /tmp/hadoop-root/dfs/name/current
---VERSION
---edits_*
---fsimage_*
---seen_txid
```

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

<property>
    <name>dfs.namenode.name.dir</name>
     <value>file://${hadoop.tmp.dir}/dfs/name</value>
</property>

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

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

<property>
    <name>hadoop.tmp.dir</name>
    <value>/tmp/hadoop-${user.name}</value>
    <description>A base for other temporary directories.</description>
</property>

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不能与环境中其他集群有冲突。如果没       
有提供cluster_id，则会自动生成一个唯一的ClusterID。
2. 使用如下命令格式化其他Namenode：
 $HADOOP_HOME/bin/hdfs namenode -format -clusterId <cluster_id>
3. 升级集群至最新版本。在升级过程中需要提供一个ClusterID，例如:                                  
$HADOOP_PREFIX_HOME/bin/hdfs start namenode --config
$HADOOP_CONF_DIR  -upgrade -clusterId <cluster_ID>
如果没有提供ClusterID，则会自动生成一个ClusterID。
```
6. blockpoolID
  
  针对每一个NameSpace所对应的blockpool的ID，上面的这个
  BP-1786918471-172.16.1.207-1498146139482 就是我在ns1的namespace下的存储块池的ID，这个id包括了对应的namenode节点服务器ip地址
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
current目录下在format的同时也好生成fsimage和edits文件及其对应的md5校验文件，

3. DataNode的工作机制

Datanode工作职责:

存储管理用户的文件块数据
定期向namenode汇报自身所持有的block信息（通过心跳信息上报）
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秒。

posted @ 2017-06-25 22:10 刘耀阅读(4181) 评论(0) 编辑收藏举报

刷新页面返回顶部

Yao.