Hadoop之详解HDFS架构weixin43800761的博客-

在之前的博客里已经基本上介绍了Hadoop的基本架构，Hadoop包含三大基本组件：

• HDFS——分布式文件系统，用于数据存储
• YARN——统一资源管理和调度系统，用于管理集群的计算资源并根据计算框架的需求进行调度，支持包含MapReduce、Spark、Flink等多种计算框架。MRv2(Hadoop 2.x)之后的新特性。
• MapReduce——分布式计算框架，运行于YARN之上

这篇博客主要是对Hadoop三大基本组件之一的HDFS进行深入的学习。

一、HDFS概述

1.1 HDFS产生背景

  随着数据量越来越大，在一一个操作系统存不下所有的数据，那么就分配到更多的操作系统管理的磁盘中，但是不方便管理和维护，迫切需要一种系统来管理多台机器上的文件，这就是分布式文件管理系统。HDFS只是分布式文件管理系统中的一种。

1.2 HDFS定义

  HDFS（Hadoop Distributed File System）：是Hadoop的分布式文件系统的实现。它的设计目标是存储海量的数据，并为分布在网络中的大量客户端提供数据访问。
  HDFS是高容错性的，可以部署在低成本的硬件之上，HDFS提供高吞吐量地对应用程序数据访问。
  HDFS的使用场景：适合一次写入，多次读出的场景，且不支持文件的修改。适合用来做数据分析，并不适合用来做网盘应用。

1.1 HDFS特性

1. 能够保存PB级的数据量，将数据散布在大量的计算机（节点）上，支持更大的文件。
2. 使用数据备份的方法解决文件存储的可靠性，如果集群中单个节点故障则启用备份。
3. 很好的与Map-Reduce集成，为减小计算时的数据交互，HDFS允许数据在本地计算。

1.2 HDFS局限性

• 针对高速流式读取进行优化，查询性能低下（可利用Hive查询）
• 一次写入多次读取，不支持并发写入，并发读取性能很高
• 不支持文件修改
• 不支持缓存，每次读取文件须从硬盘上重新读取，当然对于大文件顺序读取性能影响不大
• 不适合存储小文件

二、HDFS架构思路解析

2.1 HDFS架构思路解析1

HDFS是一种分布式文件系统，将文件存储到不同的计算机节点中。如何将文件保存到不同节点中？

HDFS是基于何种思路来设计目前的架构？

2.2 HDFS架构思路解析2

• 将文件保存在不同的节点(Node)中：
  
• 问题： 可靠性差，节点损坏会导致节点内数据丢失。
• 解决方案，将一份数据备份到多个节点。
  
  采用这种方法存在以下两种优点：
  1、可靠性高，一个节点坏掉，启用备份
  2、读取速度快，同一份数据多个备份同时读
  那又存在什么局限性呢？
  大文件保存和读取困难（如：单个100G文件）。

2.3 HDFS架构思路解析3

• 解决方案： 将所有文件以固定大小分割为块(Block)，节点只保存固定大小的块。
  

2.4 HDFS架构思路解析4

• 在思路解析3中还存在数据读取的问题

1. 如何知道系统中有哪些文件？
   节点中只存储了文件的Block，文件的原始信息丢失
2. 如何知道某个原始文件的Block对应于哪些节点？
   逐个节点去查找？
   还是建立一个管理节点，专门来管理各个节点的信息？

最终解决方案：

• 存储数据时，将文件的原始信息，以及对应的Block信息存储到“管理节点”中保存。
• 读取数据时，先查询原始文件记录和对应的Block信息就知道本系统有哪些原始文件，这些文件有哪些Block，以及这些Block存储在哪些节点中。

二、HDFS组成架构

主从模式

• 整个Hadoop被构建在集群上，集群由各个节点（Node）构成。
• 将集群中的节点分为NameNode（管理者）和DataNode（工作者）。

文件被拆分为多个Block（块）放到不同的DataNode中，在HDFS 1.x 中每个块默认大小为64MB，HDFS 2.x 中每个块默认大小为128MB，同一个块会备份到多个DataNode中存储。

2.1 HDFS组成架构介绍

  HDFS组成架构如下所示：

1. NameNode（nn）：也就是Master，它是一个主管、管理者。使用NameNode存储元数据信息，保存文件名以及文件的块(Block)存储在哪些DataNode中。每个存活的DataNode定时向NameNode发送心跳信息，如果未收到DataNode的心跳，NameNode将认定其已失效，不再向其派发任何文件读请求。NameNode会将失效的DataNode中的块(Block)备份到其他存活的DataNode中。简单来说就是：
   （1）管理HDFS的名称空间;
   （2）配置副本策略;
   （3）管理数据块(Block) 映射信息;
   （4）处理客户端读写请求。
2. DataNode：就是Slave，NameNode下达命令，DataNode执行实际操作。
   （1）存储实际的数据块
   （2）执行数据块的读/写操作
3. Client：就是客户端。
   （1）文件切分。文件上传HDFS的时候， Client将文件切分成一 个个的Block， 然后进行上传
   （2）与NameNode交互，获取文件的位置信息
   （3）与DataNode交互，读取或者写入数据
   （4）Client提供一 些命 令来管理HDFS,比如NameNode格式化
   （5）Client可以通过一些命令来访问HDFS,比如对HDFS增删查改操作
4. Secondany NameNode：并非NameNode的热备。当NameNode挂掉的时候， 它并不能马上替换NameNode并提供服务。
   （1）辅助NameNode,分担其工作量，比如定期台并fsimage和edits,并推送给NameNode ;
   （2）在紧急情况下，可辅助恢复NameNode。

2.2 Namenode的元数据管理机制

整个系统的元数据都保存在NameNode中

• 内存元数据：meta data，用于元数据查询
• 硬盘元数据镜像文件：fsimage，持久化存储元数据
• 数据操作日志：edits，HDFS文件增删会造成元数据更改，将更改记录到edits，可运算出元数据

NameNode元数据管理过程

1. 系统启动时，读取fsimage和edits至内存，形成内存元数据meta data。
2. client向NameNode发起数据增删查请求
3. NameNode接收到请求后，在内存元数据中执行增删查操作，并向client返回操作结果。
4. 如果是增删操作，则同时记录数据操作日志edits。
5. 使用Secondary NameNode，在适当的时机将操作日志合并到fsimage中（CheckPoint过程）

2.3 三个问题

为什么块的大小不能设置太小，也不能设置太大?

1. HDFS的块设置太小，会增加寻址时间，程序一直在找块的开始位置;
2. 如果块设置的太大，从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。导致程序在处理这块数据时，会非常慢。
   总结: HDFS块的大小设置主要取决于磁盘传输速率。

为什么文件操作不直接写入fsimage，而要写入单独的edits文件？

1. fsimage记录了整个大数据系统的元数据，非常庞大
2. fsimage是一个流式的文本文件，新增记录只需在文件末尾新增数据，速度快；删除记录时，需要删除文件中间的某些记录，文件越大执行效率越低
3. edits文件一般很小，通常超过64mb就会被执行合并，批量合并的操作效率比频繁修改高多了

为什么要使用Secondary NameNode合并操作日志？

1. 提高性能：NameNode是唯一面向Client的管理节点，承受Client的并发访问，性能非常重要，而合并edits和fsimage需要较大计算量
2. 提高可靠性：Secondary NameNode在合并edits 和fsimage时，会做数据备份，如果NameNode中的fsimage丢失，可从Secondary NameNode恢复

2.4 Checkpoint过程

1. SN(Secondary NameNode)向NameNode(NN)发起询问，是否需要checkpoint
2. NN读取fstime中的上次checkpoint时间，结合edits文件大小等因素，决定开始checkpoint
3. NN新建一个edits文件(如：edits.new)，让新操作写入到edits.new中(避免在checkpoint过程中，edits发生改变)
4. SN向NN请求(http协议)获取fsimage和edits文件
5. SN将edits与fsimage合并，生成新的fsimage.checkpoint文件
6. SN将fsimage.checkpoint发送给NN
7. NN收到fsimage.checkpoint后，将其与旧的fsimage替换，更新fstime文件记录本次checkpoint操作

2.5 NameNode单点故障恢复

NameNode单点故障会导致整个Hadoop崩溃

1. 利用SN(Secondary NameNode)的备份恢复NN (NameNode)元数据
   SN与NN并不是时刻同步的，checkpoint有时间间隔，这会导致恢复后有数据丢失
2. NFS方案(NFS灾备)，对NN中元数据进行即时备份，避免元数据丢失
   NSF(Network File System，网络文件系统)可与网络中的主机相互传输文件
   NN可配置NFS灾备服务器，在写入fsimage、fstime、edits、edits.new等文件时，同步写入到NSF服务器中，进而避免NN数据丢失

HDFS高可用性

• 允许配置两个相同的NameNode一个为active mode处于活动模式，另一个为standby mode处于待机模式
• 两个NameNode数据保持一致，一旦活动节点失效，则由待机节点切换为活动节点，保证Hadoop的正常运行
• 两个NameNode的共享同一个NFS以进行数据同步

三、HDFS数据写入机制

0：NameNode需要通过心跳机制收集DataNode的生存状态和存储状态；用以在第3步时，分配最佳的block存储位置。

1. 用户客户端请求Hadoop客户端，并执行文件上传
2. 上传的文件写入到Hadoop客户端的临时目录中，每当写入的数据量越过块(block)边界时(hadoop 1.x缺省64mb，hadoop2.x缺省128mb)，请求NameNode申请数据块
3. NameNode向Hadoop客户端返回block的位置
4. Hadoop客户端直接将block写入指定的DataNode

四、HDFS数据读取机制

0：NameNode需要通过心跳机制收集DataNode的生存状态；在第3步时，不会将失效的DataNode位置返回给客户端

1. 用户客户端请求Hadoop客户端，请求返回指定文件
2. Hadoop客户端向NameNode发起读文件请求
3. NameNode查询meta data并返回文件对应的block位置
4. Hadoop客户端直接向DataNode请求block数据，获取到所有block后合并成文件

五、涉及概念（总结）

• Block
    所有的文件将被拆分为若干block(缺省每个block大小为64mb)，以存放在不同的DataNode中(每个block将有3个备份保存到不同DataNode)

• DataNode
    用于存储block， block以文件的形式随机存储在集群的各个DataNode上
    DataNode不知道数据的内容，提取数据时无法知道每个Block该哪个DataNode上提取，于是需要记录每个Block存储在何处（NameNode上的元数据）。

• NameNode
    记录文件的元数据，NameNode知道所有的文件对应哪些Block以及这些Block都存放在何处
    与各个DataNode通信并管理DataNode

• 元数据（ Metadata ）
    描述数据的数据（data about data）
    包含了：每个文件的文件名、文件位置、访问权限和各个块的名称和位置
    大量小文件会生成过多元数据记录，降低NameNode查询效率(小文件定义：远远小于block边界大小的文件)。
  例：64Mb的文件分配1个block，占用1条元数据记录；而同样大小的1024个64Kb的文件，须分配1024个block，占用1024条元数据记录

• 心跳
     NameNode记录了所有的DataNode，但如果DataNode突然失效，NameNode需要迅速的知道；于是需要每个DataNode定期（默认每3秒）向NameNode发送心跳信息

• 客户端(Client)
     代表用户通过与NameNode和DataNode交互来访问整个文件系统.