HDFS框架的基本原理

HDFS框架整体概述

• HDFS是Hadoop Distribute File System的简称，以为Hadoop分布式文件系统
• HDFS是Hadoop核心组件之一，作为大数据生态圈最底层的分布式存储服务而存在
• HDFS解决的问题是大数据如何存储，他是横跨在多台计算机上的文件存储系统，并且具高度的容错能力

HDFS框架图：

• HDFS集群遵从主从架构（master/slave），通常包括一个主节点核多个从节点
• 在内部，文件分块存储，每个块根据复制因子存储在不同的从节点计算机上形成 北非。
• 主节点存储核管理文件系统namespace，即有关文件块的信息，例如块位置、权限等等，从节点存储文件的数据块
• 主从各司其职，相互配合，共同对外提供分布式文件存储服务，当然内部细节对于用户来说是透明的。

HDFS集群角色介绍

• HDFS遵从主从架构
• NameNode是主节点，负责存储和管理文件系统的元数据信息，包裹namespace目录结构、文件快位置信息等等
• DataNode是从节点，负责存储文件具体的数据块
• 主从各司其职，相互配合，共同对外提供分布式文件存储服务
• SecondaryNameNode是主角色的辅助角色，帮助主角色进行数据的合并

主角色 NameNode

• NameNode是Hadoop分布式文件系统的核心，架构中的主角色

• NameNode维护和管理文件系统元数据，包括名称目录树结构、文件和块的位置信息、访问权限等信息

• NameNode是访问HDFS的唯一入口

• NameNode内部通过内存和磁盘文件两种方式管理元数据

• 其中磁盘上的元数据文件包括Fsimage内存元数据镜像文件和edits log（Journal） 编辑日志

• 在Hadoop2之前，NameNode是单点故障，Hadoop2之后引入了Hadoop的高可用，Hadoop集群体系结构允许集群中以热备配置运行两个或者多个NameNode

从角色：dataNode

• DataNode是Hadoop HDFS中的从角色，负责具体的数据块存储
• DataNode的数量决定了HDFS集群的整体数据存储能力，通过和NameNode配合维护者数据块 （但是NameNode 不知道这些数据块来自谁，仅仅负责存储）

主角色的辅助角色：SecondaryNameNode

• 出了DataNode和NameNode之外，还有另一个守护进程，它称为SecondaryNameNode，充当NameNode的辅助节点，但不能代替NameNode。
• 当NameNode启动时，NameNode合并Fsimage和edits log文件以还原当前文件系统名称空间，如果edits log过大不利于加载，Secondary NameNode就辅助NameNode从NameNode下载Fsimage文件和edits log文件进行合并

HDFS重要特性

主从架构

• HDFS采用master/slave架构，一般一个HDFS集群是有一个NameNode和一定数目的DataNode组成
• NameNode是HDFS主节点，DataNode是HDFS从节点，两种各司其职，共同协调完成分布式的文件存储服务

分块存储机制

• HDFS中的文件在物理上是分块存储的，块的大小可以通过配置具体的参数来规定，参数位于hdfs-default.xml中dfs.blocksize。默认大小128M(134217728)

分块存储的好处： 可以提高操作效率、决负载均衡以解决单机能不能存储下的问题

副本存储机制

• 文件的所有block都会有副本，每个文件的block大小（dfs.blocksize）和副本系数(dfs.replication)都是可以进行配置的，副本系数可以在文件创建的时候指定，也可以在之后通过命令进行改变

• 默认dfs.replication的值是3，这个3容易存在歧义，这个3的实际含义是带上本身一共存在三份

我们可以进行一个上传，查看其是存储位置。

namespace

• HDFS 支持传统的层次型文件组织结构，用户可以创建目录，然后将文件保存在目录中，文件系统名字空间的层次结构和大多数现有的文件系统类似，用户可以创建、删除、移动或者重命名文件
• NameNode负责维护系统文件系统的namespace名称空间，任何对文件系统名称空间或者属性的修改都将被记录下来
• HDFS会给客户端提供一个同意的抽象目录树，客户端通过路径来访问文件。

元数据管理

在HDFS中，NameNode管理的元数据具有两种类型：

• 文件自身属性信息：
  文件名称、权限、修改时间、文件大小、复制因子、数据块大小等
  
• 文件块位置映射信息
  记录文件块喝DataNode之间的映射信息，即哪个快位于那个节点上。
  

数据块存储

文件的各个block的具体存储管理由DataNode节点承担，每一个block都可以在多个DataNode上存储。

HDFS Web Interfaces

模块功能介绍

OvwrView

Summary

NameNode Storage

DFS Storage Types

DataNodes

DataNodes模块主要记录了HDFS集群中各个DataNode的相关状态信息

Datanode Volume Failures

记录模块异常

当前还没有异常

Snapshot

Snapshot模块记录HDFS文件系统的快照相关信息，包括那些文件夹创建了快照和总共那些快照。

Satartup progress

Satartup progress 模块记录了HDFS集群启动过程中的信息，执行步骤和每一步所用的时间和所做的事

Utilities

Browse the file system

使用最多的模块，可以直接进行一系列的操作，告别shell API

Logs、Log Level

Logs是直接把所有的Log都显示出来，可以点击直接查看：

Log Level 可以进行一个所有

Configuration

Hadoop的所有配置：

HDFS读写流程

写入数据流程

Pipeline管道、ACK应答

Pipeline，中文管道，是HDFS在上传文件写数据过程中采用的一种数据传输方式。客户端将数据块写入第一个数据节点，第一个数据节点保存数据之后再将块复制到第二数据节点，后者保存后再将其复制到第三个数据节点。简单描述pipeline过程：

客户端->A->B->C

为什么DataNode之间采用Pipeline先行传输而不是一次给三个DataNode拓扑式的传输？

因为数据一贯道的方式顺序的沿着一个方向传输，这样能够充分利用每个机器的带宽，避免网络瓶颈和高延迟时的连接，最小化推送所有数据的延时，在现行推送模式下，每台机器所有的出口带宽都将以最大的线性速度传输数据，而不是在多个接收者之间分配带宽。

ACK即是确认字符，在数据通信中，接收方发送给发送方的一种传输类控制字符。表示发来的数据已确定接收无误。在pipeline管道传输数据的过程中，传输的反方向会进行ACK校验，确保数据传输安全。

具体流程

• HDFS客户端通过对DistributedFileSystem对象调用create()请求创建文件。
• DistributedFileSystem对NameNode进行PRC远程调用，请求上传文件。NameNode执行各种检查判断：文件目标是否存在、父目录是否存在、客户端是否具有创建该文件、客户端是否具有创建该文件的权限。检查通过，NameNode就会为创建新文件记录一条数据。否则文件创建失败，并会抛出IOException
• DistributedFileSystem为客户端返回FSDataOutputStream输出对象流，由此客户端可以进行写入数据。FSDataOutputStream是一个包装类，所包装的时DFSOutputStream。
• 在客户端写入数据时，DFSOutputStream将他分成一个个数据包（packet 默认4kb）并写入一个称为数据队列的内部队列中。DFSOutputStream有一个内部类嘴DataStreamer，用于请求NameNode挑选出合适的存储数据副本的一组DataNode，这一组DataNode采用Pipeline机制做数据的发送，默认时3副本存储的。
• DataStreamer将数据包流式传输到pipeline的第一个datanode，改DataNode存储数据包并将它发送到Pipeline的第二个DataNode。同样的第二个DataNode存储数据包并且发送给第三个（最后一个）DataNode
• DFSOutputStream 内部也维护着一个内部数据包队列等待DataNode的收到确认回执，称之为确认队列（Ack Queue），收到pipeline中所有DataNode确认信息后，该数据包才会从确认队列删除。
• 客户端完成数据写入后，将在流上调用close()方法关闭，改造错将剩余的数据包写入到DataNode pipeline，并联系到NameNode告知文件写入完成之前等待确认
• 因为NameNode已经知道文件有哪些块组成（DataStream请求分配数据块），因此他仅需等待最小复制块即可完成返回。
• 数据块最小赋值是由参数dfs.namenode.replication.min指定，默认为1

默认三副本存储策略

在默认情况下是一个三副本模式，

第一块副本：有限客户端本地，否则随机

第二块副本：不同于第一块副本的不同机架

第三块副本：第二块副本相同机架的不同机器

读数据流程

具体流程

• 客户端通过调用DistributedFileSystem都西昂上的Open()来打开希望读取的文件
• DistributedFileSystem使用RPC远程调用NameNode来确定文件中前几个块的块位置，对于每个块，NameNode返回具有该块副本的datanode地址，并且datanode根据块与客户端的距离进行排序。需要注意的是这里的距离指的是网络拓扑中的距离。
• DistributedFileSystem将FSDataInputStream(支持文件seek定位度的输入流)返回到客户端以供读者读取数据。
• FSDataInputStream类转而封装为DFSInputStream类。DFSInputStream 管理着Datanode和NameNode之间的IO
• 客户端在流上调用read()方法。然后，已存储着文件前几个块DataNode地址的DFSInputStream随机连接到文件中第一个快的的最近的DataNode节点，通过对数据流反复调用read()方法，可以将数据从DataNode传输到客户端
• 当该块快要读取结束结束时，DFSInputStream将关闭与该DataNode的连接，然后寻找下一个块的最佳DataNode，这些操作对用户来说是透明的（也就是说看不见的），所以用户觉得在读取一个连续的流
• 客户端从流中读取数据时，块是按照打开DFSInputStream与DataNode新建连接的顺序读取的，他也会根据需要询问NameNode来检索下一批数据块的DataNode 位置信息，一旦客户端完成了读取，就对FSDataInputStream调用close()方法
• 如果DFSinputStream与DataNode通讯时遇到错误，他将尝试该块的下一个最近的DataNode读取数据。并记住此时发生故障的DataNode，保证以后不会反复读取该DataNode后续的块。此外，DFSInputStream也会通过检验和(checksum)确认从DataNode发来的数据是否完整，如果发现有损坏的块，DFSInputStream会尝试从其他DataNode读取该块的副本，也会将被损坏的块报告给NameNode

角色职责简述

NameNode职责

1. NameNode是HDFS的核心，集群的主角色，被称之为Master
2. NameNode仅存储管理HDFS的元数据，文件系统NameSpace操作位数目录树、文件和块的位置信息
3. NameNode不存储实际数据或者数据集，数据本身存储在DataNode中
4. NameNode知道HDFS中任何给定文件的块列表及其位置，使用此信息NameNode知道如何从块中构建文件
5. NameNode并不持久化存储每个文件中各块所在的DataNode的位置信息，这些信息会在系统启动的时候从DataNode汇报中重建
6. NameNode对HDFS至关重要，当NameNode关闭时，HDFS说Hadoop集群无法访问。所以NameNode故障是一个单点故障，除非配置了相关的高可用
7. NameNode所在的机器通常会配置大的内存(RAM)

DataNode职责

1. DataNode负责将实际数据存储在HDFS中，是集群的从角色，被称之为Slave。
2. DataNode启动时，它将自己发布到NameNode并汇报自己持有的块列表。
3. 根据NameNode的指令，执行块的创建、复制、操作、删除操作
4. DataNode会定期(dfs.heartbeat.interval配置项进行配置，默认为3s)向NameNode发送心跳，如果NameNode长时间没有接收到DataNode发送的心跳，NameNode将会认为该DataNode失效
5. DataNode会定期向NameNode进行自己持有的数据块消息汇报，汇报时间间隔取参数dfs.blockreport.intervalMsec，参数为配置时默认6小时
6. DataNode所在机器通常配置有大量的硬盘空间，因为实际数据存储在DataNode

NameNode元数据管理

元数据是什么

元数据，又称中介数据，为描述数据的数据（data about data）,主要是描述数据属性(property)的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能

HDFS中，元数据主要指的是文件相关的元数据，由NameNode管理维护，从广义的角度来讲，因为NameNode还需要管理众多的DataNode节点，因此DataNode的位置和健康状态信息也属于元数据。

元数据管理

在HDFS中，文件相关元数据具有两种类型：

• 文件自身属性信息

  文件名称、权限、修改日期、文件大小、复制因子、数据块大小

  

• 文件块映射信息

  记录文件块和DataNode之间的映射信息，即哪个块位于那个节点上。

  按照存储形势分为内存元数据和元数据文件两种，分别存储在内存和磁盘上。

  

内存元数据

为了保证用户操作员数据交互高效、低延迟，NameNode把所有的元数据都存储在内存中，我们称作为内存元数据。内存中的元数据是最完整的，包括文件自身属性信息、文件块位置映射信息。

但是内存的致命问题就是断电数据丢失，数据不会持久化，因此NameNode又辅佐了元数据文件来保证元数据的完全完整。

磁盘元数据文件

fsimage 内存镜像文件

是内存元数据的一个持久化的检查点，但是fsimage中仅包含hadoop文件系统中文件自身属性的相关的元数据信息，但不包括文件快位置的信息。文件块位置信息之存储在内存中，由datanode启动加入集群的时候，向namenode进行数据块汇报得到的，并且后续间断指定时间进行数据块报告。

持久化的动作是一种数据从内存到磁盘的IO过程，会对NameNode正常服务造成一定的影响，不能频繁的进行持久化。

Edits log 编辑日志

为了避免两次持久化之间数据丢失问题，又设计了Edits log编辑日志文件，文件中记录的是HDFS所有更改操作(文件创建、删除或者修改)的日志，文件系统客户端执行的更新操作首先先回记录到edits文件中。

加载元数据顺序

fsimage和edits文件都是经过序列化的，在被NameNode启动的时候，他会将fsimage文件中的内存加载到内存中，之后再执行edits文件中的各项操作，是的内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作，也是最完整的元数据。

当客户端对HDFS中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存元数据中，因为fsimage问及那一半都很大（GB级别十分常见），如果所有操作都往fsimage文件中添加，这样会导致系统运行得十分缓慢。

HDFS这种设计是先着手于：一是内存中数据更新、查询快，极大缩短了操作响应时间，二是内存中源数据丢失风险颇高，因此辅佐元数据镜像文件（fsimage） +编辑日志文件（edits）的备份机制进行确保源数据的安全。

NameNode维护系统元数据，因此，元数据的准确管理，影响着HDFS提供文件存储服务的能力。

元数据管理相关目录文件

元数据存储目录

在Hadoop的HDFS首次部署好文件之后不能马上启动，而是先要对文件系统进行格式化操作：hdfs namenode -format

这里注意两个概念：一个是format之前，hdfs在物理上还是不存在的，二是就在此处的format不是我们理解的本地磁盘的格式化，而是一些清除与准备工作。其中就会创建元数据本地存储目录和一些初始化的元数据相关文件。

NameNode元数据存储目录由参数： dfs.namenode.name.dir指定，格式化完成之后就会在$$dfs.namenode.name.dir/current目录下创建文件，其中的dfs.namenode.name.dir是在hdfs-site.xml文件中配置的。

dfs.namenode.name.dir属性可以配置多个目录，各个目录存储的文件结构和内容都完全一样，相当于备份，这样子做的好处是当其中一个目录损坏了，也不会影响到hadoop的元数据，特别是当其中一个目录是NFS（网络文件系统 Network File System）之上，俗称这台机器损坏了，元数据也得到了保存

元数据的相关文件

VERSION

查看VERSION

• clusterID/namespaceID/blockpoolID 是集群的唯一标识符，标识符被用来防止DataNodes被意外地注册到另一个集群的NameNode上，这些表示在联邦（federation）部署中特别重要。在联邦模式下会有多个NameNode独立工作，每个的NameNode提供唯一的命名空间(namespaceID)并管理一组唯一的文件块池(blockpoolID)。clusterID将整个集群集合在一起作为单独的逻辑单元，在集群中的所有节点上都是一样的。

• storageType，说明这个文件存储的是什么进程的数据结构类型，如果是DataNode，storageType=DATA_NODE
  NameNode节点的图->
  
  DataNode结点的图：
  

• cTime NameNode存储系统创建时间，首次格式化文件系统这个属性是0，当文件系统升级后，该值会更新到升级之后的时间戳

• layoutVersion，HDFS元数据格式的版本，添加需要修改源数据格式的新功能时，需要修改此处的数字。当前HDFS软件使用比当前版本更新的布局版本是需要升级HDFS。

seen_txid

包括最后一个checkpoint的最后一个事务ID，这不是NameNode接受的最后一个事务ID，该文件不会再每个事务上更新，而只会在checkpoint或者编辑日志记录上更新，改文件的目的是尝试识别edits启动期间是否丢失的文件，如果edits目录被意外删除，然后自上一个checkpoint以来的所有事物都将消失，NameNode仅从最近的一次fsimage加载启动，为了防止这种情况，NameNode启动还会检查seen_txid以确定他至少还可以加载该属数目的食物，如果无法验证装入事务，他将终止启动。

fsimage相关

元数据镜像文件，每个fsimage文件还有一个对应的.md5文件，其中包含md5校验和，HDFS使用该文件放置磁盘损坏文件异常。

edits log 相关

已完成且不可修改的编辑日志，这些文件中的每一个文件都包含文件名定义的范围内的所有编辑日志事务，在HA高可用部署中，主备NameNode之间可以通过Edits log进行数据同步

Fsimage、editslog查看

Fsimage

fsimage文件时Hadoop文件系统元数据的一个永久性的检查点，包括Hadoop文件系统中的所有目录和文件idnode的序列化信息，对于文件来说，包含的信息有修改的时间、访问时间、块大小和组成一个文件信息等，而对于目录来说，包含的信息主要有修改时间、访问控制权限等信息。

oiv是offline image viewer的缩写，用于将fsimage文件的内容转储到指定文件中以便于阅读，该工具还提供了只读的WebHDFS API以允许离线分析和检查hadoop集群的命名空间。

hdfs oiv -i fsimage文件名 -p XML -o 自定义.xml

Edits Log

Edits Log文件存放的是Hadoop文件系统的所有更新操作记录日志，文件系统客户端执行的所有写操作手贱会被记录到edits文件中。。

NameNode启动之后，HDFS中的更新操作会重新写到Edits问文件中，因为fsimage文件很大，如果所有的更新操作都写入到fsimage文件中，这会导致系统启动非常缓慢，但是如果往edits文件里面写入就不会这样子，每次执行写入操作之后，且在向客户端发送成功代码之前，edit文件都需要同步更新，如果一个文件比较大，使得写操作需要向多台机器进行操作，只有当所有的写操作都执行完之后写操作才会返回成功，这样子的好处就是任何的操作都不会因为机器的故障而造成源数据不同步。

oev是offline edits viewer(离线edits查看器)的缩写。

hdfs oev -i edits_00000000000000000468-00000000000000000470 -o edits.xml

SecondaryNameNode

SNN的职责

NameNode的职责是管理员数据信息，DataNode的职责是负责数据具体的存储，那么SecondaryNameNode的作用是什么？

HDFS集群运行一段时间会存在很多问题：

1. edits logs会变得非常的大，fsimage就变得非常的旧。
2. NameNode重启会花费很长时间，因为很多改动需要合并到fsiamge文件上
3. 如果频繁的进行fsimage持久化，又会影响到NameNode正常服务，毕竟是IO操作，会消耗内存

为了解决这个问题，需要一种易于管理的机制帮助我们减小edits logs文件的大小和得到一个最新的fsimage文件，这样子会减小NameNode的压力

SNN的职责就是帮忙解决上述问题的，他的职责是帮助合并NameNode的edits logs 到fsimage文件中去。

SNN Checkpoint 机制

概述

checkpoint核心是吧fsimage与edits log合并以生成新的fsimage，此过程有两个好处：fsimage不会太旧，edits log文件不会太大

流程

• 当出发checkpoint的操作条件时，SNN发生请求给NN滚动edits log，然后NN会生成一个新的编辑日志文件 edits new，便于后续的操作记录
• 同时SNN会将edits文件和fsimage文件复制到本地（使用HTTP Get方式）
• SNN首先将fsimage载入到内存，然后一条一条的执行edits文件中的操作，使得内存中的fsimage不断更新，这个过程就是edits和fsimage文件合并，合并结束后，ssn将内存中的数据dump生成一个新的fsimage文件。
• SSN 将生成的Fsimage new文件复制到NN节点
• 至此刚好是一个新的轮回，等待下一次Checkpoint出发SecondaryNameNode进行工作。

触发机制

CheckPoint触发条件收到了两个参数控制，可以通过core-site.xml进行配置：

存在默认值

1. 时间间隔1h
2. 最大没有执行事务的数量，满足将强制执行紧急checkpoint，即使未达到检查点的斗气，默认为100w事务数量

<property>
<name>dfs.namenode.checkpoint.periodname>
<value>3600svalue>
<final>falsefinal>
<source>hdfs-default.xmlsource>
property>

<property>
<name>dfs.namenode.checkpoint.txnsname>
<value>1000000value>
<final>falsefinal>
<source>hdfs-default.xmlsource>
property>

可见SecondaryNameNode根本不是NameNode的一个热备，只是将fsimage和edits合并的秘书

NameNode元数据恢复

NameNode存储多目录

NameNode元数据存储目录由参数dfs.namenode.name.dir指定，dfs.namenode.name.dir属性可以配置多个目录，各个目录的文件结构和内容都完全一样，相当于备份，这样做的好处是当其中一个目录文件损坏了，也不会影响到hadoop的元数据，特别是当其中一个目录是NFS之上，即使机器损坏，元数据也得到了保存。

从SecondaryNameNode恢复

SecondaryNameNode在checkpoint的时候会将fsimage和edits log下载到自己的本机上本地目录下，并且在checkpoint之后也不会删除。

如果NameNode中的fsimage文件真的出现了问题，还是可以用SecondaryNameNode中的fsimage替换一下NameNode下的fsimage，虽然不是最新的fsimage，但是能够将损失降到最低