一：GFS

Google需要一个支持海量存储的文件系统
方法一：购置昂贵的分布式文件系统与硬件？
方法二：是否可以在一堆廉价且不可靠的硬件上构建可靠的分布式文件系统？
问题：为什么不使用当时现存的文件系统？
Google所面临的问题与众不同 不同的工作负载，不同的设计优先级（廉价、不可靠的硬件）需要设计与Google应用和负载相符的文件系统

优点：在物理上分离，逻辑上统一，用数量上的多，来弥补单个机器的不足，三个臭皮匠赛过诸葛亮

1：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高度并行，系统整体性能得到提高。

2：master容错机制：

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

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

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

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

3： 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确保一个名称节点在对外服务
名称节点维护映射信息，数据节点同时向两个名称节点汇报信息