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副本

7.hdfs工作流程及机制

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. 客户端本地进行数据的追加合并从而获得整个文件

7.hdfs工作流程及机制

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. 详细过程
    ![图片 1](http://img.liuyao.me/图片 1.png)

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

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

    <property>
             <name>dfs.name.dir</name>
             <value>/data/hadoop/name1,/data/hadoop/name2</value>
        </property>
    
    
  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文件中配置

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

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

  1. 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>
    
  2. 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地址

  3. 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

  4. 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秒。

  3.  

 转自:https://www.cnblogs.com/liu-yao/p/7078217.html  
上一篇:7月27日


下一篇:ORA-17629: Cannot connect to the remote database server