分布式存储系统HDFS

3.1 HDFS简介

Hadoop平台解决两大核心问题：

• 分布式存储
• 分布式处理
  HDFS就是解决海量数据分布式存储

背景：大数据时代，对于海量的数据，单个计算机无法处理，只能借助整个集群来处理海量数据。

---

文件系统结构（主从结构）：

主节点：承担起目录作用，比如元数据服务。
从节点：实现数据存取的任务。

概念：HDFS是分布式文件系统，即文件通过网络在多个主机共享的文件系统，让多个机器的多个用户分享文件和存储空间。
特点：通透性：DFS是通过网络完成访问文件的动作，由用户和程序来看就像访问本地磁盘一样。
HDFS架构：采用master/salve结构，是管理者-工作者模式。
实现目标：

• 兼容廉价的硬件设备
• 实现流数据读写（对于数据整个读写或者大部分读写，不会访问某一个子集，或一个块），满足海量数据批处理需求
• 支持大数据集
• 支持简单的文件模型，牺牲一些相关的性能，但是获取批量数据的特性，只允许追加不允许修改
• 强大的跨平台兼容性，基于java语言开发的，java具有良好的跨平台特性

自身局限性：

• 不适合低延迟数据访问，只能批量的读取数据，不能精确的定位到某一条数据，不能满足实时的处理需求（HBS可以）
• 无法高效存储大量小文件，如果小文件太多，索引节点太多，索引效率过低
• 不支持多用户写入和任意修改文件（设计的时候就是只允许追加不允许修改）

---

3.2 HDFS相关概念

块
（1）联系：为了分摊磁盘的读写开销
（2）区别：比普通的文件（64M）系统块大很多
（3）设计目的：

• 支持面向大规模数据存储
• 降低分布式节点的寻址开销：三级寻址（元数据目录，数据节点，块）

（4）缺点：如果块太大会导致Mapredecu就一两个任务在执行，完全牺牲了Mapreduce的并行度，发挥不了分布式并行处理的效果

使用块的好处：
（1）支持大规模文件存储：把大文件进行切割，分布式的存储到不同机器上
（2）简化系统设计：块大小是固定的，文件除以块的大小，可以算出块需要多少，元数据设计简单
（3）适合数据备份：一个块存储到多个荣誉的节点上

---

HDFS组件：

• 名称节点：
  （1）名称节点是一个中心服务器，负责管理文件系统的命名空间
  （2）协调客户端对文件的访问
  （3）执行对命名空间的操作
  （4）记录每个文件数据块在数据节点的位置和副本信息
• 数据节点：
  （1）负责所在物理节点的管理，是真正数据存储的地方
  （2）负责处理客户端的文件读写请求
  （3）在名称节点的指挥下负责数据块的创建、删除、复制
  （4）周期性的向名称节点汇报数据块信息
• 客户端节点：
  （1）把文件切分成一个个数据包
  （2）访问或命令行管理HDFS
  （3）与名称节点交互，获取文件位置信息
  （4）与数据节点交互，读取和写入数据

元数据信息：

• 文件是什么
• 文件被分成多少块
• 每个块和文件是怎么映射的
• 每个块 被存储在哪个服务器上

名称节点的数据结构：

• FsImage：保存系统文件树
• EditLog：记录对数据进行的诸如创建、删除、重命名等操作

FsImage负责：

• 块大小以及组成文件的块
• 文件的复制等级
• 修改和访问时间
• 访问权限

其中数据块存放在哪些节点不是通过FsImage，而是以下过程
过程：
当数据节点加入到一个集群中去，数据节点像名称节点汇报自己节点上保存了哪些数据块，名称节点就可以自己构建一个清单，这些信息保存在内存中。

---

名称节点运行机制
首先将FsImage从磁盘读入到内存，和EditLog各项操作进行合并，FsImage存储是历史数据，通过EditLog记录的操作得到最新的元数据，把新版的FsImage保留下来，把旧版的删除，同时创建一个空的EditLog文件。
优点：FsImage对于大数据来讲规模非常大，每次不断改FsImage，会导致系统运行很慢。把更新的部分单独存储起来，EditLog规模很小，操作效率很高。
存在的问题：EditLog会不断增大，大到一定程度又会影响系统性能

第二名称节点
任务：
（1）名称节点的冷备份
（2）对EditLog不断增大的处理

第二名称节点运行机制：
定期地与名称节点通信，在阶段会请求名称节点停止使用EditLog文件，此时名称节点生成一个edit.new文件，把新到达地更新全部写到edit.new文件中，第二名称节点通过HTTPget方式把原来旧的FsImage和EditLog下载到本地，在第二名称对FsImage更新（FsImage和EditLog合并操作）得到一个新的FsImage，再发送个名称节点，edit.new更改为edit

数据节点
运行机制：
Blockreport：当数据节点启动后，扫描本地文件系统，生成HDFS数据块系统列表，像名称节点发送一个报告
过程：
Datanode启动后向名称节点注册，注册成功后，以后每一个周期上报自己所有数据块信息，然后每4秒给名称节点发送心跳，心跳返回名称节点给数据节点的命令，如果一段时间没有心跳认为该数据节点不可用。

---

3.3 HDFS体系结构（主从架构）

客户端读数据：先访问名称节点，知道文件存储在哪些数据节点，从而客户端去各个数据节点的位置获取数据

客户端写数据：先访问名称节点，知道文件存储到哪些数据节点，从而客户端去各个数据节点的位置存储数据

HDFS命名空间：
包括目录文件块
/+目录名称

通信协议：
HDFS的通信协议都是构建在TCP/IP上，客户端到名称节点使用TCP客户端协议，名称节点到数据节点使用专门数据协议
客户端取数据使用远程的RPC协议

局限性：

• 命名空间限制：名称节点是保存在内存中的，因此名称节点能容纳的对象（文件、块）的个数会受到空间大小限制
• 性能的瓶颈：整个分布式文件的吞吐量，受限于单个节点的吞吐量
• 隔离问题：由于集群中只有一个名称节点，只有一个命名空间，因此无法对不同的应用程序进行隔离
• 集群的可用性：一旦这个唯一的名称节点发生故障，会导致整个集群变得不可用。

关于第二名称节点：由于他是冷备份所以不能解决集群单点故障问题
冷备份：不能保证发生故障就可以立马代替故障节点，必须停止一段时间，慢慢恢复，再提供对外恢复。

---

3.4 HDFS存储原理

数据冗余保存（默认是3）
好处：

• 加快数据传输速度：同样的任务可以并行访问冗余的节点
• 容易检查错误数据：通过和备份的数据对比
• 保证数据可靠性：一但系统探测到副本发生故障，会自动复制，把整个副本数恢复到原来数目。

数据块存放：
首先对块复制三份，第一份放在上传文件的数据节点，如果提交数据的请求不是来自集群内布，HDFS随机挑选一个磁盘不太满，CPU不太忙的数据节点放置，第二节点放在与第一节点不同的机架上。第三个副本放在第一个副本相同机架的其他节点上

数据读取
就近读取：HDFS提供一个API可以确定一个数据节点所属的机架ID，客户端也可以调用自己API获取自己所属的机架ID。
过程：客户端从名称节点获得数据块不同副本的存放位置列表，列表中包含了副本所在的数据节点，调用API确定客户端和数据节点的机架ID，优先从ID相同的机架读取，如果没有就随机读取。

数据的错误和恢复
名称节点出错：
通过第二名称节点备份恢复（1.0）
数据节点：
定期向名称节点发送心跳信息，告诉自己活着，一旦一段时间名称节点收不到信息，知道它发送故障，将其标记为宕机，把凡是存储在故障机上的数据重新分发到其他可以的机器上。
数据出现错误：
磁盘损坏等。
客户端读取数据使用校验码校验，如果出现错误，就会发现不对。对冗余数据进行复制。

---

3.5 HDFS读写过程

读过程：
（1）打开文件：
HDFS客户端发起，生成DistributedFileSystem类对象，创建一个FSDataInputStream
（2）获取数据块信息：
通过远程调用从名称节点获取数据块信息，名称节点会把文件开始的一部分文件信息返回
（3）读取请求：
客户端收到文件信息列表，执行read函数，从距离客户端最近的数据节点建立连接。读完以后关闭输入流和数据节点连接
（4）获取数据块信息：
再去输入流去获取文件的下一个数据块信息
（5）读取数据
…
（6）关闭文件

写过程：
（1）创建文件请求：
客户端节点创建文件请求，创建分布式文件系统和一个输出流
（2）创建文件元数据：
输出流调用名称节点，让名称节点在命名空间中新建一个文件，名称节点会检查文件是否存在，客户端是否有权限创建。如果都通过就会创建
（3）写数据：
把数据分成一个个分包，分别放入输出流的内部队列，输出流向名称节点申请保存这些数据块的数据节点，把分包发到第一个数据节点，第一个数据节点再发到第二个数据节点，第二个数据节点再发到第三个数据节点
（4）返回确认包：
由最后一个节点传给前一个节点，依次往前。
（5）关闭文件

---

3.6 HDFS的稳健性

1、故障类型

• 节点故障
• 通讯故障
• 数据损坏
  （1）数据在网络中损坏
  （2）数据存储在硬盘中损坏

2、故障检测

• 节点故障检测：
  数据节点每三秒发送一个心跳信号，如果名称节点10分钟没有接受到，就认为数据节点挂掉了。
• 网络故障检测：
  没测发送数据时，接收者会回复一个应答信号，如果没有收到应答信号（多次尝试），发送者就会认为主机已经挂掉，或者发送网络错误。
• 数据损坏故障检测：
  HDFS客户端实现对文件内容的校验和，HDFS写入的时候计算校验和，然后每次读的时候再计算校验和，硬盘存储数据的同时也会存储校验和
  
  

---

3.7 HDFS的可访问性

（1）提供一个命令行接口让用户和HDFS数据交互
（2）通过原生的FileSystem Java API接口访问
（3）通过浏览器的方式访问HDFS中的实例文件

---

3.8 HA架构

1、解决的问题：
为了解决名称节点单点故障的问题，为名称节点保存一个热备，两个独立的机器作为名称节点：Active Namenode,Standby Namenode。任何时候只有一个节点处于Active状态，另一个处于Standby状态。前者用于接受客户端请求，后者作为salve保持群的状态数据以备快速failover。

2、HA结构

3、快速failover
数据节点需要同时配置两个名称节点地址，同时建立心跳链接，并把块位置发给他们。当Active失效后，Standby切换成Active

4、两种常见方案

（1）NFS

• 实现机制：
  active和standby需要共享一个存储目录，active把数据变更日志保存在该目录，同时standby监视更新，保持数据同步，为了保证active挂了以后不再有新数据写入，Fencing逻辑切断所有与active连接。
• 局限性：
  1）只支持一个数据变更共享目录，导致HA能力受限于该目录。
  2）为防止共享目录的单点失效，对共享目录有额外的要求。
  3）NFS方式部署更复杂。

（2）QJM

• 实现机制：
  两个节点都与一组称为JNS的互相独立的进程保持通信，当active更新命名空间，把修改日志发送给JNS的多数派，standby从JNS读取edit，持续关注日志变更，把变更应用到自己的命名空间中。
  

5、两者比较
（1）共同点：

• 都是热备方案
• 都是一个active和一个standby
• 都使用ZK quorum和ZKFC实现自动恢复
• 在失效恢复时都需要配置fencing方法来断开active

（5）不同点

• 分享的数据方式不同
• 参与HA的不同角色

---

3.9 HDFS优缺点

（1）优点：

（2）缺点：

（3）主要问题：