分布式文件系统：

分布式文件系统管理的屋里存储资源不一定直接在本地节点上，而是通过计算机网络与节点相连。

分布式文件系统的基于客户机/服务器模式。通常，一个分布式文件系统提供多个供公户访问的服务器。

分布式文件系统一般都会提供备份和容错功能。

分布式文件系统一般都基于操作系统的本地文件系统

 

分布式文件系统的优点：

传统 文件系统最大问题是容量和吞吐量的限制。

多用户多应用的并行读写是分布式文件系统产生的根源。

扩充存储空间的成本低廉

可提供冗余备份

可以为分布式计算提供基础

 

HDFS是一个使用java实现的，分布式的，可横向扩展的文件系统。

       HDFS= Hadoop Distributed File System

是hadoop的核心组件

基于linux


HDFS设计目标：

基于廉价的普通硬件，可以容忍硬件出错

系统中的某一台或几台服务器出现故障的时候，系统仍可用且数据保持完整。

大数据集（大文件）

适合存储大量文件总存储量可以达到PB,EB级

适合存储大文件，单个文件大小一般在百MB级之上

文件数目适中

简单的一致性模型

应用程序需要一次写入，多次读取一个文件的访问模式

支持追加操作，但无法更改已写入数据

顺序的数据流访问

适合用于处理批量数据，而不适合用于随机定位访问

侧重高吞吐量的数据访问，可以容忍数据访问的高延迟

为 把“计算”移动到“数据”提供基础和便利。


HDFS基本概念：

块

元数据

     -namenode

     -datanode

客户端

块（block）的概念

在传统的块存储介质中，块是读写的最先数据单位（扇区）

传统文件系统基于存储块进行操作

也使用了块的概念，但是默认大小设为64M字节

将一个文件分为一个或数个块来存储

与传统文件系统不同的是，如果实际数据没有达到块大小，则并不实际占用磁盘空间

使用块的优点：

当一个文件大于进群中的任意一个磁盘的时候，文件系统可以充分利用集群中的所有的磁盘

管理块是底层的存储子系统相对简单

块更加适合备份，从而为容错和高可用性的实现带来方便

HDFS的元数据（数据信息）：

元数据包括

，文件系统和目录树信息

，文件和块的对应关系

，块的存放位置

对元数据和实际数据采取 分别存储的方法

，元数据存储在一台指定的服务器上（namenode）

，实际数据存储在集群的其他机器的本地文件系统中（DataNode）

块的冗余备份：

每个块在集群上回存储多分（replica）

，默认复制分数为3

，可针对每个文件配置，

，可针对每个文件配置，由客户端指定

，可动态修改

某个块的所有备份都是同一个ID

系统可以根据机架的配置自动分配备份位置

，第一份在集群的某个几家的某台机器上

，其他两份在另外的一个几家的两台机器上

，机架信息需要手工配置

 

NameNode：

是用来管理文件系统命名空间的组件

一个HDFS集群只有一台Namenode

上存放了HDFS的元数据

元数据保存在namenode的内存当中，以便快速查询

内存大致可以存放1000000个块对应的元数据信息

，按缺省每块64M计算，大致对应64T实际数据

DataNode：

块的实际数据存放在DataNode上

每个块会在本地产生两个文件，一个是实际的数据文件，另一个是块的附加信息文件，其中还包括数据的校验和生成时间。

通过心跳包（heartbeat）与 namenode通讯

客户端读取/写入数据的时候直接与DataNode通信

元数据的持久化：

里使用两个非常重要的本地文件来保存元数据信息：

，fsimage：保存了文件系统目录树信息，保存了文件和块的对应关系

，edits：保存文件系统的更改记录，客户端对文件进行写操作时，操作首先记入edits，成功后才会更改内存中的数据，并不会立刻更改硬盘上的fsimage

块的位置信息并不做持久化


元数据的载入和更新：

启动时：

1，通过fsimage读取元数据，载入内存

，执行edits中的记录，在内存中生成最新的元数据

，清空edits，保存最新的元数据到fsimage

，收集DataNode汇报的块的位置信息

运行时：

1，对文件创建和写操作记录到edits

，更新内存中的元数据

，收集DataNode汇报块的创建和复制信息

 

HDFS创建文件流程：

客户端：1，客户端请求namenode在命名空间中建立新的文件元信息

，如果不能创建文件则namenode会返回失败

，如创建成功，客户端得到此文件的 写保护锁

：

，namonode检查集群和文件状态

，创建写保护锁保证只有一个客户端在操作该文件

，建立该文件的元信息

，把创建文件这个事件加入edits

，位该文件分配块，以及块的冗余备份位置

 

HDFS写操作流程（重点）：

客户端个文件并不是直接写到HDFS上

客户端接收用户数据，并把内容缓存到本地

当本地缓存收集足够一个HDFS块大小的时候，客户端同namenode通讯注册一个新的块

注册块成功后，namenode会给客户端返回一个DataNode的列表（块的位置，冗余备份）

客户端向列表第一个DataNode写入块

收到DataNode的确认信息后，客户端删除本地缓存

客户端继续 发送下一个块，重复以上步骤

当所有数据发送完成后，写操作完成

 

HDFS的读操作流程：

客户端与namenode通讯获取文件的块位置信息，其中包括了块的所有冗余备份的位置信息，DataNode的列表

客户端回去文件位置信息后直接同有文件块的DataNode通讯，读取文件

如果第一个DataNode无法连接，客户端将自动联系下一个DataNode

如果块数据的校验值出错，则客户端需要向namenode报告，并自动联系下一个DataNode

HDFS追加写（append）的操作流程：

客户端与namenode通讯，获得文件的写保护锁及文件最后一个块的位置（DataNode）

客户端挑选一个DataNode作为主写入点，并对其余节点上的该数据块加锁。

开始写入数据：与普通写入流程类似，依次更新各个DataNode数据

最后一个块写满，并且所有备份块后写入完成后，向namenode申请下一个数据块

secondary namenode：

不是备份节点

的主要工作是阶段性的合并fsimage和edits文件，以此来控制edits的文件大小在合理的范围（缩短重启时namenode重建fsimage时间，做数据恢复，但不是全部）

运行在不同于namenode的主机上，内存需求和namenode一样。