大数据的存储与处理，GFS和HDFS技术简介-新盟教育-思科华为网络工程师认证-HCIE/CCIE|HCIP/CCNP|HCIA/CCNA线上培训机构

新闻资讯资讯详情

大数据的存储与处理，GFS和HDFS技术简介

发布作者：新盟教育发布日期：2022-01-27 浏览人数：44318人

小白轻松学

一、GFS

Google需要一个支持海量存储的文件系统

方法一：
购置昂贵的分布式文件系统与硬件？
方法二：
是否可以在一堆廉价且不可靠的硬件上构建可靠的分布式文件系统？
问题：为什么不使用当时现存的文件系统？
Google所面临的问题与众不同，不同的工作负载，不同的设计优先级（廉价、不可靠的硬件）需要设计与Google应用和负载相符的文件系统。
优点：在物理上分离，逻辑上统一，用数量上的多，来弥补单个机器的不足，三个臭皮匠赛过诸葛亮。

GFS传输过程

解析：

Client（客户端）：应用程序的访问接口。

Master（主服务器）：管理节点，在逻辑上只有一个，保存系统的元数据，负责整个文件系统的管理。

Chunk Server（数据块服务器）：负责具体的存储工作。数据以文件的形式存储在Chunk Server上。

应用程序——GFS服务器：文件名。
GFS服务器——GFS数据块服务器搜索文件。
GFS数据块服务器——GFS服务器返回chunk句柄和chunk文职。
应用程序——GFS数据块服务器 chunk句柄。
GFS数据块服务器——应用程序数据。
典型的数据流和控制流分离。

实现机制

1. 客户端首先访问Master节点，获取交互的Chunk Server信息，然后访问这些Chunk Server，完成数据存取工作。这种设计方法实现了控制流和数据流的分离。

2. Client与Master之间只有控制流，而无数据流，极大地降低了Master的负载。

3. Client与Chunk Server之间直接传输数据流，同时由于文件被分成多个Chunk进行分布式存储，Client可以同时访问多个Chunk Server，从而使得整个系统的I/O高度并行，系统整体性能得到提高。

master容错机制

GFS将服务器故障视为正常现象，并采用多种方法，从多个角度，使用不同的容错措施，确保数据存储的安全、保证提供不间断的数据存储服务。

① Name Space，即文件系统的目录结构。
② Chunk 与文件名的映射（因为一个文件会被划分成多个Chunk*，因此需要一个映射来告诉系统，这个文件对应哪几个chunk）。
③ Chunk副本的位置信息（一个chunk会存储三个副本*）。

①和②的容错是通过“操作日志”来完成的。也就说存在operation log里。当系统发生故障时，通过分析log就可以知道当时存了哪些文件，这些文件又被分成了哪些个chunks。

③是存储在Chunk Server上的，当发生故障时，进行磁盘恢复即可。

GFS还提供了Master远程的实时备份 secondNameNode,防止Master彻底死机的情况。

Chunk Server容错

采用副本方式实现Chunk Server容错。

1. 每一个Chunk有多个存储副本（默认为三个），分布存储在不同的Chunk Server上

2. 对于每一个Chunk，必须将所有的副本全部写入成功，才视为成功写入。

GFS中的每一个文件被划分成多个Chunk，Chunk的默认大小是64MB。

每个Chunk又划分为若干Block（64KB），每个Block对应一个32bit的校验码，保证数据正确（若某个Block错误，则转移至其他Chunk副本）。

尽管一份数据需要存储三份，好像磁盘空间的利用率不高，但综合比较多种因素，加之磁盘的成本不断下降，采用副本无疑是最简单、最可靠、最有效，而且实现的难度也最小的一种方法。

HDFS

逻辑示意图：

分布式文件系统在物理结构上是由计算机集群中的多个节点构成的，这些节点分为两类：

一类叫“主节点”(Master Node)或者也被称为“名称节点”(NameNode)。
另一类叫“从节点”（Slave Node）或者也被称为“数据节点”(DataNode)。

特点：

分布式文件系统
冗余存储（备份）
面向大文件存储设计
面向批量插入设计【大多是向后append而很少有中间插入】
基于普通廉价机器提供可靠的数据存储
容忍部分节点故障

局限性：

不适合低延迟数据访问【访问速度较慢】
无法高效存储大量小文件【以block为单位，block比较大】
不支持多用户写入及任意修改文件【在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作。目前HDFS还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改】

组成部分

块block

HDFS默认一个块128MB，一个文件被分成多个块，以块作为存储单位。

块的大小远远大于普通文件系统，可以最小化寻址开销[对于10MB文件，如果由KB文件组成，每一个文件都会寻址就很慢，整体就会很快]。

HDFS采用抽象的块概念可以带来以下几个明显的好处：

1. 支持大规模文件存储：

文件以块为单位进行存储，一个大规模文件可以被分拆成若干个文件块，不同的文件块可以被分发到不同的节点上，因此，一个文件的大小不会受到单个节点的存储容量的限制，可以远远大于网络中任意节点的存储容量。

2. 简化系统设计：

首先，大大简化了存储管理，因为文件块大小是固定的，这样就可以很容易计算出一个节点可以存储多少文件块；其次，方便了元数据的管理，元数据不需要和文件块一起存储，可以由其他系统负责管理元数据。

3. 适合数据备份：

每个文件块都可以冗余存储到多个节点上，大大提高了系统的容错性和可用性。

名称节点NameNode ：存储元数据

元数据（Metadata），又称中介数据、中继数据，为描述数据的数据（data about data），主要是描述数据属性的信息。

在HDFS中，名称节点（NameNode）负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构，即FsImage和EditLog。

FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据。

操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作。

名称节点的启动

在名称节点启动的时候，它会将FsImage文件中的内容加载到内存中，之后再执行EditLog文件中的各项操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作。

一旦在内存中成功建立文件系统元数据的映射，则创建一个新的FsImage文件和一个空的EditLog文件。

名称节点起来之后，HDFS中的更新操作会重新写到EditLog文件中，因为FsImage文件一般都很大（GB级别的很常见），如果所有的更新操作都往FsImage文件中添加，这样会导致系统运行的十分缓慢，但是，如果往EditLog文件里面写就不会这样，因为EditLog 要小很多。每次执行写操作之后，且在向客户端发送成功代码之前，edits文件都需要同步更新。

1. 缺陷：

名称节点运行期间EditLog不断变大的问题

在名称节点运行期间，HDFS的所有更新操作都是直接写到EditLog中，久而久之， EditLog文件将会变得很大。

虽然这对名称节点运行时候是没有什么明显影响的，但是，当名称节点重启的时候，名称节点需要先将FsImage里面的所有内容映像到内存中，然后再一条一条地执行EditLog中的记录，当EditLog文件非常大的时候，会导致名称节点启动操作非常慢，而在这段时间内HDFS系统处于安全模式，一直无法对外提供写操作，影响了用户的使用。

2. 如何解决？

答案是：SecondaryNameNode第二名称节点

第二名称节点是HDFS架构中的一个组成部分，它是用来保存名称节点中对HDFS 元数据信息的备份，并减少名称节点重启的时间。SecondaryNameNode一般是单独运行在一台机器上。

3. SecondaryNameNode的工作情况：

（1）SecondaryNameNode会定期和NameNode通信，请求其停止使用EditLog文件，暂时将新的写操作写到一个新的文件edit.new上来，这个操作是瞬间完成，上层写日志的函数完全感觉不到差别。

（2）SecondaryNameNode通过HTTP GET方式从NameNode上获取到FsImage和EditLog文件，并下载到本地的相应目录下。

（3）SecondaryNameNode将下载下来的FsImage载入到内存，然后一条一条地执行EditLog文件中的各项更新操作，使得内存中的FsImage保持最新；这个过程就是EditLog和FsImage文件合并。

（4）SecondaryNameNode执行完（3）操作之后，会通过post方式将新的FsImage文件发送到NameNode节点上。

（5）NameNode将从SecondaryNameNode接收到的新的FsImage替换旧的FsImage文件，同时将edit.new替换EditLog文件，通过这个过程EditLog就变小了。

从上述得出 SecondaryNameNode

第二名称节点用途：

不是热备份
主要是防止日志文件EditLog过大，导致名称节点失败恢复时消耗过多时间
附带起到冷备份功能

数据节点 DataNode

数据节点是分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表。

每个数据节点中的数据会被保存在各自节点的本地Linux文件系统中。

#HDFS体系结构的局限性

HDFS只设置唯一一个名称节点，这样做虽然大大简化了系统设计，但也带来了一些明显的局限性，具体如下：

（1）命名空间的限制：

名称节点是保存在内存中的，因此，名称节点能够容纳的对象（文件、块）的个数会受到内存空间大小的限制。

（2）性能的瓶颈：

整个分布式文件系统的吞吐量，受限于单个名称节点的吞吐量。

（3）隔离问题：

由于集群中只有一个名称节点，只有一个命名空间，因此，无法对不同应用程序进行隔离。

（4）集群的可用性：

一旦这个唯一的名称节点发生故障，会导致整个集群变得不可用。

HDFS存储原理

冗余数据作为一个分布式文件系统，为了保证系统的容错性和可用性，HDFS采用了多副本方式对数据进行冗余存储，通常一个数据块的多个副本会被分布到不同的数据节点上，数据块1被分别存放到数据节点A和C上，数据块2被存放在数据节点A和B上。

这种多副本方式具有以下几个优点：

（1）加快数据传输速度。

（2）容易检查数据错误。

（3）保证数据可靠性。

HDFS存储原理数据错误与恢复

HDFS具有较高的容错性，可以兼容廉价的硬件，它把硬件出错看作一种常态，而不是异常，并设计了相应的机制检测数据错误和进行自动恢复，主要包括以下几种情形：名称节点出错、数据节点出错和数据出错。

1. 名称节点出错

名称节点保存了所有的元数据信息，其中，最核心的两大数据结构是FsImage和Editlog，如果这两个文件发生损坏，那么整个HDFS实例将失效。因此，HDFS设置了备份机制，把这些核心文件同步复制到备份服务SecondaryNameNode上。

当名称节点出错时，就可以根据备份服务器SecondaryNameNode中的FsImage和Editlog数据进行恢复。

2. 数据节点出错

每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态。

当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自一些数据节点的心跳信息，这时，这些数据节点就会被标记为“宕机”，节点上面的所有数据都会被标记为“不可读”，名称节点不会再给它们发送任何I/O请求。

这时，有可能出现一种情形，即由于一些数据节点的不可用，会导致一些数据块的副本数量小于冗余因子。

名称节点会定期检查这种情况，一旦发现某个数据块的副本数量小于冗余因子，就会启动数据冗余复制，为它生成新的副本。

HDFS和其它分布式文件系统的最大区别就是可以调整冗余数据的位置。

3. 数据出错

网络传输和磁盘错误等因素，都会造成数据错误。

客户端在读取到数据后，会采用md5和sha1对数据块进行校验，以确定读取到正确的数据。

Hadoop框架自身的改进：从1.0到2.0：

HDFS HA

SecondaryNameNode无法解决单点故障问题(NameNode损坏，整个系统宕机)。

HDFS HA（High Availability）是为了解决单点故障问题。

HA集群设置两个名称节点，“活跃（Active）”和“待命（Standby）”。两种名称节点的状态同步，可以借助于一个共享存储系统来实现，一旦活跃名称节点出现故障，就可以立即切换到待命名称节点。

Zookeeper确保一个名称节点在对外服务。

名称节点维护映射信息，数据节点同时向两个名称节点汇报信息。

END