HDFS系列(1)-架构

1. 设计初衷

分而治之：将大文件、大批量文件，分布式存放在大量服务器上，以便于采取分而治之的方式对海量数据进行运算分析。

2. 优缺点

2.1 优点

1. 高容错性
   1）数据自动保存多个副本。它通过增加副本的形式，提高容错性
   2）某一个副本丢失以后，它可以自动恢复，这是由 HDFS 内部机制实现的，我们不必关心。
2. 适合批处理
   1）它是通过移动计算而不是移动数据
   2）它会把数据位置暴露给计算框架。
3. 适合大数据处理
   1）处理数据达到 GB、TB、甚至PB级别的数据。
   2）能够处理百万规模以上的文件数量，数量相当之大。
   3）能够处理10K节点的规模
4. 流式文件访问
   1）一次写入，多次读取。文件一旦写入不能修改，只能追加。
   2）它能保证数据的一致性。
5. 可构建在廉价机器上
   1）它通过多副本机制，提高可靠性。
   2）它提供了容错和恢复机制。比如某一个副本丢失，可以通过其它副本来恢复。

2.2 缺点

1. 低延时数据访问
   1）比如毫秒级的来存储数据，这是不行的，它做不到。
   2）它适合高吞吐率的场景，就是在某一时间内写入大量的数据。但是它在低延时的情况下是不行的，比如毫秒级以内读取数据，这样它是很难做到的。
2. 小文件存储
   1）存储大量小文件的话，它会占用 NameNode大量的内存来存储文件、目录和块信息。这样是不可取的，因为NameNode的内存总是有限的。
   2）小文件存储的寻道时间会超过读取时间，它违反了HDFS的设计目标。
3. 并发写入、文件随机修改
   1）一个文件只能有一个写，不允许多个线程同时写。
   2）仅支持数据 append（追加），不支持文件的随机修改。

3. HDFS体系架构

3.1 体系架构

HDFS架构图.png

HDFS主要有以下组件组成：

1. Client客户端
2. NameNode管理者
3. DataNode数据节点
4. SecondaryNameNode节点，辅助NameNode完成一些工作

3.2 Client客户端

客户端是用户和HDFS进行交互的手段，HDFS提供了各种各样的客户端，包括命令行接口、Java API, Thrift接口、C语言库、用户空间文件系统〔Filesystem in Userspace,FUSE)等
主要工作内容：

1. 文件切分。文件上传 HDFS 的时候，Client 将文件切分成 一个一个的Block，然后进行存储。
2. 与 NameNode 交互，获取文件的位置信息。
3. 与 DataNode 交互，读取或者写入数据。
4. Client 提供一些命令来管理 HDFS，比如启动或者关闭HDFS。
5. Client 可以通过一些命令来访问 HDFS。

3.3 NameNode管理节点

NameNode就是HDFS的Master架构，主要负责HDFS文件系统的管理工作，具体包括名称空间(namespace)管理，文件Block管理。

1. 名称空间(namespace)管理：它维护着文件系统树(filesystem tree)以及文件树中所有的文件和文件夹的元数据(metadata)。管理这些信息的文件有两个，分别是Namespace 镜像文件(fsimage)和操作日志文件(edit log)，这些信息被Cache在RAM中以及持久化存储在本地硬盘。
   fsimage：metadata存储到磁盘中的镜像文件
   editlog：记录对medadata的操作日志
2. 文件Block管理：Namenode记录着每个文件中各个块所在的数据节点的位置信息（元数据信息），从NameNode中你可以获得每个文件的每个块所在的DataNode。但是他并不持久化存储这些信息，因为这些信息NameNode会在每次启动系统时动态地重建这些信息。
   元数据信息，包括：
   1）文件owership和permissions
   2）文件包含哪些Block
   3）Block保存在哪个DataNode（由DataNode启动时上报）
3. 接收客户端读写请求
4. 配置副本策略

3.4 DataNode数据节点

3.4.1 功能

1. 存储数据：一个数 据块Block会在多个DataNode中进行冗余备份；而一个DataNode对于一个块最多只包含一个备份。所以可以简单地认为DataNode上存储了数据块ID和数据块内容，以及它们的映射关系。
2. 启动DN线程的时候会向NN汇报block信息
3. 通过心跳定时和NameNode进行通信发送所存储的文件块信息(3秒一次)，并在心跳通信应答中接受NameNode的指令，如删除数据库或者把数据块复制到另一个DataNode（如果NN 10分钟没有收到DN的心跳，则认为其已经lost，并copy其上的block到其他DN）
4. 作为服务器接受来自客户端的访问，处理数据块读/写请求（DataNode之间还会相互通信，执行数据块复制任务，同时，在客户端执行写操作的时候，DataNode之间需要相互配合，以保证写操作的一致性）

3.4.2 数据块block

3.4.2.1 block配置

HDFS中的文件在物理上是分块存储（block），块的大小可以通过配置参数( dfs.blocksize)来规定，默认大小在hadoop2.x版本中是128M，老版本中是64M

3.4.2.2 文件读取时间

文件查找时间主要分为两个阶段：磁盘寻址开销时间和磁盘传输时间

1. 为了最小化磁盘寻址时间，会设置block的物理块大于磁盘块大小，如果块设置得足够大，从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。因而，传输一个由多个块组成的文件的时间取决于磁盘传输速率。
2. 如果寻址时间（找到物理位置）约为10ms，而传输速率为100MB/s，为了使寻址时间仅占传输时间的1%（最佳状态），我们要将块大小设置约为100MB。默认的块大小实际为64MB，但是很多情况下HDFS使用128MB的块设置。
   块的大小：10ms100100M/s = 100M

image

3.1.3 block副本

HDFS中为了保证数据高可用性及容错性，会另外存储block的副本文件到其他节点上

1. 副本数设置
   在dfs-site.xml里设置

 
    dfs.replication 
    3 

比如这里设置成3个副本数，这时候就会按照以下机架策略进行分配节点数据

2. 机架存储策略

   
   
   机架存储策略.jpg
   
   

   若存在多个机架，副本存储策略如下：
   1）本机架A一个数据节点存储一份
   2）另外一个机架B挑选一个数据节点存储一份
   3）最后一份仍在机架B上挑选不同的数据节点进行存储

3.5 SecondNameNode

主要是定时对NameNode的数据snapshots进行备份，这样可尽量降低NameNode崩溃之后导致数据丢失的风险。
主要工作内容：

1. 从NameNode获得fsimage和edits后把两者重新合并发给NameNode，这样可以减轻NameNode的工作负担，又可以安全的进行备份（通常SecondNameNode会单独部署在新的物理机上）
2. 一旦NameNode挂掉，SecondeNameNode会辅助进行数据恢复（但由于SNN上的数据同步会有一定的延迟，不可避免的会存在一些数据丢失的情况，所以目前更多采用的是NameNode HA的集群部署方式）

3.5.1 目录结构

1. NameNode目录结构
   ${dfs.name.dir}/current
   ................................./VERSION
   ................................./edits
   ................................./fsimage
   ................................./fstime
2. SecondNameNode目录结构
   ${fs.checkpoint.dir}/current
   ...................................../VERSION
   ...................................../edits
   ...................................../fsimage
   ...................................../fstime
   ............................./previous.checkpoint
   ...................................../VERSION
   ...................................../edits
   ...................................../fsimage
   ...................................../fstime

5.3.2 工作原理

image.png

概念：
edit log：当客户端执行写操作，则NameNode会在edit log记录下来，并在内存中保存一份文件系统的元数据。
fsimage：是文件系统元数据的持久化检查点，不会在写操作后马上更新，因为fsimage写非常慢
目的：
由于Edit log不断增长，在NameNode重启时，会造成长时间NameNode处于安全模式，不可用状态，是非常不符合Hadoop的设计初衷。所以要周期性合并Edit log，但是这个工作由NameNode来完成，会占用大量资源，这样就出现了Secondary NameNode，它可以进行image检查点的处理工作。
工作步骤：

1. Secondary NameNode请求NameNode进行edit log的滚动（即创建一个新的edit log），将新的编辑操作记录到新生成的edit log文件；
2. 通过http get方式，读取NameNode上的fsimage和edits文件，到Secondary NameNode上；
3. 读取fsimage到内存中，即加载fsimage到内存，然后执行edits中所有操作，并生成一个新的fsimage文件，即这个检查点被创建；
4. 通过http post方式，将新的fsimage文件传送到NameNode；
5. NameNode使用新的fsimage替换原来的fsimage文件，让（1）创建的edits替代原来的edits文件；并且更新fsimage文件的检查点时间。