HDFS分布式文件系统架构

HDFS分布式文件系统架构

1.HDFS概论与基础框架结构

HDFS基础介绍

一、文件系统概述

• 文件系统是操作系统用于明确存储设备（常见的是磁盘，也有基于NANDFlash的固态硬盘）或区分上的文件的方法和数据结构；即在存储设备上组织文件的方法。
  
  ​ 文件系统定义： 文件系统是一种存储和组织计算机数据的方法，它使得对其访问和查找变得容易。

​ 文件名： 在文件系统中，文件名是用于定位存储位置。

​ 元数据（Metadata）： 保存文件属性的数据，如文件名，文件长度，文件所属用户组，文件存储位置等。

​ 数据块（Block）： 存储文件的最小单元。对存储介质划分了固定的区域，使用时按这些区域分配使用。

二、文件系统组成与功能

• 文件系统的组成主要包括以下几个主要部分：

• 文件名：文件的名称
• 数据：文件内部的实际数据，一般是存储在存储空间中，由文件系统进行调度和管理
• 元数据：文件的属性信息，主要记录了文件的存储位置、创建修改时间等内容

• 文件系统的功能包括：管理和调度文件的存储空间，提供文件的逻辑结构、物理结构和存储方法;实现文件从标识到实际地址的映射，实现文件的控制操作和存取操作，实现文件信息的共享并提供可靠的文件保密和保护措施，提供文件的安全措施。

以块形式存储是目前最常用的一种数据存储方式，我们在进行数据存储时，使用的是元数据加数据的形式，元数据相当于是数据的一个摘要信息，保存着文件的属性、长度、存储位置、类型等信息，类似于字典中的索引和正文的关系，数据块作为文件存储的最小的单位，对存储区域进行了区域划分，在写入数据时按需分配。

我们可以按照字典的方式进行类比：文件系统就相当于是字典，元数据相当于索引目录，数据相当于是正文，我们查字典就和查找数据一样，首先需要访问文件系统，然后根据元数据找到对应的数据位置和相关的属性信息，最后根据元数据的描述找到数据。

三、文件系统类型

• 目前常见的文件系统的类型有但不只包括以下类型：
  • FAT：FAT是早期Windows系统使用的文件系统，计算机将信息保存在硬盘上称为“簇”的区域内。使用的簇越小，保存信息的效率就越高。
  • NTFS：NTFS文件系统是一个基于安全性的文件系统，是WindowsNT所采用的独特的文件系统结构，它是建立在保护文件和目录数据基础上，同时照顾节省存储资源、减少磁盘占用量的一种先进的文件系统。
  • exFAT：ExtendedFileAllocationTableFileSystem，扩展FAT，即扩展文件分配表
  • EXT：Linux系统常用文件系统，主要分为EXT2——EXT4

四、HDFS文件系统概述

• HDFS(HadoopDistributedFileSystem)基于Google发布的GFS论文设计开发，运行在通用硬件上的分布式文件系统。

• 其除具备其它分布式文件系统相同特性外，还有自己特有的特性：

  • 高容错性：认为硬件总是不可靠的
  • 高吞吐量：为大量数据访问的应用提供高吞吐量支持
  • 大文件存储：支持存储TB-PB级别的数据、

  HDFS（HadoopDistributionFileSystem）是运行在通用硬件（所谓通用硬件就是指软件对于底层的硬件平台的配置和设备没有需求，可以随意搭建并且兼容，对于HDFS文件系统包括整体的Hadoop组件来说，这样做就可以达到完美的拓展性，由于本身设备对于硬件没有要求之后，那么我们就可以按照无限堆积硬件的方式进行性能的拓展，直到满足大数据处理系统的需求，这样做可以减小在实际操作中的成本，并且可以提供更好的容错性，如果我们对于设备的型号或者性能有需求那么不免我们会在搭建时使用相同的设备来进行操作，这样的话，如果某一厂商的设备存在有BUG，那么就会在一批设备上出现相同的问题，造成整体性能的下降或者系统的安全性危机）上的分布式文件系统，它具有高容错性，高吞吐量并且支持大文件存储。

  HDFS支持的主要是大文件的流数据，对于离散的小文件的支持性较弱，尤其是对延迟比较敏感的应用，由于HDFS要支持高吞吐量，所以势必要以牺牲延迟作为代价。

  注：由于HDFS的文件系统是需要将元数据加载在内存中进行维护的，我们又将该维护进程称之为Namenode，系统需要为每一个数据文件维护约150字节的元数据，所以存储小文件和大文件都是消耗同样的元数据空间，这样的话，在支持性上，小文件过多就会影响最终数据的存储容量，对于相同的元数据空间，我们所能存储的单位数据越大，那么大数据文件系统的支持性也就越强，所以HDFS在相同的文件数目下，存储大文件和小文件的开销相同，那么存储大文件就更加合理。并且作为大数据主要使用的文件系统，HDFS主要提供的是文件的读操作，所以它整个分布式进程中只有一个写进程，其他的进程全部都是读进程，并且该写进程是在所有进程的最末尾的。设计者针对于大数据操作系统的处理特点，为了保护数据的一致性和读写的性能，就提出了WORM模型作为HDFS整体的系统设计目标，WORM-writeoncereadmany，WORM的最开始是使用在存储系统中，用于对关键数据进行保护的，比如政府，法院的判决文件等，这些文件可以允许进行读取，但是由于需要保护其不受篡改所以就需要WORM来进行保证，当一个文件写入到文件系统中之后，在更改期限内，我们还可以进行改写操作，当进入到保护周期之后，就只能进行读取，无法进行写操作了，这里说的写操作是任何写都不能执行。当文件大小为0字节，也就是指该文件为空文件时，那么文件在保护期内还有一次追加写的机会。这是在存储中的WORM的特点，在HDFS中，由于我们的设计目标并不是为了防止文件的篡改，而是为了保证高效率的读取，所以我们并没有将WORM设计的很严格。我们写入的文件是不再允许修改的，但是我们可以在文件末尾进行无限的追加写操作。

五、HDFS文件系统特点

• HDFS适合做以下类型工作：

  • 大文件存储
  • 流式数据访问

• HDFS应用类型举例：

  • 气象系统数据存储
  • 用户行为数据存储
  • 其他以海量大文件，读操作为主的业务

• HDFS不适合做以下类型工作：

  • 大量小文件存储

  • 随机写入

  • 低延迟读取

不适用场景：

p[1]低时间延迟数据访问的应用，例如几十毫秒范围。

原因：HDFS是为高数据吞吐量应用优化的，这样就会造成以高时间延迟为代价。

p[2]大量小文件。

原因：NameNode启动时，将文件系统的元数据加载到内存，因此文件系统所能存储的文件总数受限于NameNode内存容量。根据经验，每个文件，目录和数据块的存储信息大约占150字节，如果一百万个文件，且每个文件占一个数据块，那至少需要300MB的内存空间，但是如果存储十亿个文件，那么需要的内存空间将是非常大的。

p[3]多用户写入，任意修改文件。

原因：现在HDFS文件只有一个writer，而且写操作总是写在文件的末尾。

HDFS设计架构

• 在大数据的组件架构中，HDFS提供的是整个结构最底层的文件存储功能，他组织了文件形式，将数据切分为数据块存储起来，并且记载和维护元数据。
• HDFS分为三个组件：Namenode，Datanode，Client
  

HDFS设计结构—NameNode

• Namenode：用于存储生成元数据，运行一个实例。该进程是由HDFS调入到内存中运行的。NameNode作为元数据的维护进程，为了能够提升整体读取的效率，所以我们将元数据的维护进程搭载在内存中进行运行，但是内存中的数据是易失的，所以平时元数据还是在DataNode中进行维护的。当系统启动之后，服务器会拉起HDFS进程，然后将NameNode加载到内存中，然后NameNode会加载元数据镜像文件到自身内存中。

HDFS设计结构—DataNode

• Datanode：用于存储实际的数据，每个Datanode会将自己维护的数据块信息上报到Namenode，运行多个实例。HDFS默认最小的存储空间为block，每个block默认的大小为128MB。DataNode除了需要维护数据之外，还需要留有一部分的空间用于存储元数据镜像文件Fsimage。如果NameNode和DataNode是部署在一起的，那么Fsimage就在DataNode上，其实相当于是在服务器的存储介质上。如果NameNode和DataNode是分开部署的，那么就相当于Fsimage是存储在部署NameNode的服务器上的。如下图所示：

HDFS设计结构—Client

• Client：支持业务访问HDFS，并从Namenode和Datanode中获取数据，返回给用户，多个业务和实例一起运行。这里所说的Client并不是指实际的用户应用，而是HDFS本身自带的进程，通过该进程我们可以访问HDFS，相当于HDFS是一间房，Client为我们提供了进入的门，Client提供的接口主要有JDBC和ODBC接口。
• Client建议部署在以下任意节点上：

2.HDFS系统设计

HDFS—HA

一、HDFS高可用性概述

• HDFS为了达成高可用性进群，设计了以下几个组件来保证可靠性。由于HDFS认为硬件总是不可靠的，所以为了保证自身业务的正常执行和数据的安全性，那么就需要有对应的保护机制来保证整体业务的运行。在HA中，我们提供的主要是进程的安全性保障。

二、HDFS高可用性组件功能

• zookeeper：分布式协调进程，用来存储HA下的状态文件，主备信息，zk建议为三个或三个以上的奇数个。Zookeeper进程主要提供的是对NameNode进程的保护，这里所谓的保护其实是用于裁决NameNode的主备状态，并且存储NameNode的状态信息。
• Namenode主备：在主备模式中，主节点提供服务，备节点合并元数据并作为主节点的热备。NameNode为了能够保护自身的可靠性，维护元数据和业务的持续运行，这里设计了两个进程来进行保护，一个进程用于正常提供业务，另一个进程作为备进程，但是备进程并不是冷备，而是处于热备状态，一旦进程出现故障，那么备进程可以立即受到消息，然后切换状态。
• ZKFC（zookeeperFailoverController）：用于控制在故障时Namenode的主备状态，进行故障切换。该进程的作用是为了保障当主NameNode出现故障的时候可以及时的进行故障切换，将业务切换到备NameNode中进行运行，保障业务的连续性，所以ZKFC需要及时检测主备NameNode的状态，并且将心跳信息及时上报给Zookeeper，所以ZKFC进程和NameNode进程一样多，并且需要和NameNode部署在一起。
• JN（JournalNode）：用于共享Namenode生成的Editlog文件。Editlog文件是我们对HDFS的操作的日志文件，这些信息并未写入到FSimage的元数据镜像文件中，所以我们需要进行持久化，保障整体的元数据镜像在HDFS进程在重启的时候可以正常加载。

HDFS—数据保护

• 在HDFS中，为了保证数据的绝对安全性，我们默认会存储三份副本数据，所以和源数据一起，一个数据会被存储4份，我们认为A数据和B数据在一个服务器内的时候，距离为0，A数据和B数据在同一机架内的时候距离为2，认为A数据和B数据不在同一机架内的时候距离为4。
• 由于HDFS认为硬件总是不可靠的，所以HDFS就需要负责进程和数据的可靠性保证，HA提供的是进程的可靠性保证，那么数据的可靠性保证就可以通过两种方式进行保护，目前业内主要使用的保护机制有两种，一种是RAID技术，主要通过硬件RAID卡进行操作保护，但是一旦RAID卡损坏，就会导致RAID组全部数据失效。而本身HDFS认为硬件不可靠，所以数据的保护机制就没有使用RAID的保护机制，而是交给自身的软件进行保护，使用的副本机制进行保护。这样的话，当某一个节点出现故障之后，就可以直接使用其他副本的数据，避免了像RAID中出现降级重构或者预拷贝而导致的性能影响问题。
• HDFS存储的距离公式为：
  • Distance（R1/D1,R1/D1）=0
  • Distance（R1/D1，R1/D*）=2*
  • Distance（R1/D1,R/D*）=4
  • R：机架编号；D：服务器编号
• 副本放置的机制遵循如下公式：
  • 副本1：Distance=0
  • 副本2：Distance=4
  • 副本3：通过检测，查看两个副本是否在同一个机架上，如果是，则选择在不同机架上，否则选择在和副本相同机架的不同节点上。
  • 副本4+：随机选择

第一份副本会存储在和源数据同一位置的服务器上，所以距离为0，第二份数据随机进行存储，存储在除源数据服务器以外的任意一个位置，第三份副本通过检测，查看两个副本是否在同一个机架上，如果是，则选择在不同机架上，否则选择在和副本相同机架的不同节点上。第四份副本随机选择位置，我们默认是3副本机制，也可以设置多副本。副本的位置前三份必须要满足距离0/2/4的需求，从第4份以及之后的副本，那么就随机选取位置，当然选择的副本数量越多。越安全，但是占用的空间就越大。

HDFS元数据持久化

• 进行HDFS的操作时，数据都是存储在内存中的。在对操作进行记录的时候，一方面记录了Editlog，另一方面记录了Fsimage文件，但是Fsimage文件是在内存中维护的。所以关机之后，当前正在使用的在内存中的Fsimage文件就会丢失，服务器中存储的Fsimage文件就是上一次开机时加载的文件。从时效性上来说，当下一次开机时，加载旧的Fsimage文件之后，元数据是处于不可用的状态的。因为元数据和数据是不一致状态的，所以在开机进行加载时就需要通过Editlog来对元数据进行进一步的恢复性加载。这个时候需要耗费过长的时间来进行。也就影响了整体进程的加载速度。
• 因此提出元数据持久化来解决该问题

我们在进行HDFS的操作时，数据都是存储在内存中的。这样的话，数据在内存中维护，我们在对操作进行记录的时候，一方面记录了Editlog，另一方面记录了Fsimage文件，但是Fsimage文件是在内存中维护的，所以关机之后，当前正在使用的在内存中的Fsimage文件就会丢失，那么服务器中存储的Fsimage文件就是上一次开机时加载的文件，从时效性上来说，就会很落后。当下一次开机时，我们加载旧的Fsimage文件之后，元数据其实是处于不可用的状态的。因为元数据和数据是不一致状态的，这时候如果进行写操作或者读操作，就会读取出错误的文件，或者是无法读取文件。这个时候我们在开机进行加载的时候就需要通过Editlog来对元数据进行进一步的恢复性加载。这个时候需要耗费过长的时间来进行。也就影响了整体进程的加载速度。

并且同时为了保证数据的安全性（比如在突然断电的情况下，Editlog和Fsimage就可以出现数据丢失的情况），我们也需要元数据持久化，主要是为了更新Namenode中的Editlog（操作记录日志文件）和Fsimage（文件系统镜像）两个文件，保证两个文件在主备节点中的同步，最终当出现故障的时候，可以进行Failover操作，保证整体大数据平台的可用性。而且，做Editlog和Fsimage的合并也有利于在进程重启之后，可以尽快的进行元数据的加载操作。那么为了达成这个目的，我们就需要通过元数据持久化这个操作来保证主备之间关于Editlog和Fsimage这两个文件的可用性和实时性。并且我们需要将Fsimage文件进行操作文件和元数据的整合，这个操作也同样保证了Namenode中的元数据能够保持一个长可用性。我们默认当时间为1小时或者Editlog文件大小达到64M时，启动一次元数据持久化操作。

• 持久化流程如下：
  • 首先备节点会下发一个请求到主节点，之后主节点会生成一个临时文件Editlog.new文件（一个新文件，不包含原Editlog文件中的任何信息）继续使用，并将原先的Editlog和Fsimage文件发送到备节点中。
  • 备节点会对Editlog和Fsimage两个文件做合并，生成一个名为Fsimage.ckpt的文件，并将该文件发送给主端。
  • 主节点在收到Fsimage.ckpt文件之后，会用这个文件将原先的Fsimage文件进行回滚。
  • 最终主节点将Editlog.new更名为Editlog。

HDFS数据写入流程

• HDFS数据写入流程

  • 客户端请求写入文件，Client通过DistributedFileSystem进程向Namenode发起RPC请求。

  • 收到请求后，Namenode在NameSpace中创建一个文件信息

  • 创建完成之后，DistributedFileSystem会在Client本地返回一个FSDataOutputStream进程

  • 业务会在本地调用writeAPI接口，将数据写入到Client进程中。

  • Client联系对应进程将数据写入，数据在写入成功之后，将会由DataNode向Client返回确认信息

  • 业务调用close关闭进程,flush后HDFSClient联系NameNode，确认数据写完成，NameNode更新元数据

（1）首先，客户端请求写入一个文件，Client通过自身的DistributedFileSystem进程向Namenode发起RPC请求。

这里说的Client并不是指客户的应用程序，而是本身HDFS自带的进程，该进程提供了对外的访问接口，和对内其他组件之间的交互接口。RPC远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

（2）收到RPC请求之后，Namenode会在自己的NameSpace中创建一个文件信息

该过程的主要作用就是创建元数据，如果执行的是改写的操作，那么元数据本身就存在与NameNode上，这个时候就不需要执行相关的创建操作了，如果是新写入数据，那么就需要我们执行这个创建元数据的操作。创建元数据操作主要的作用是分配写空间。

（3）创建完成之后，DistributedFileSystem会在Client本地返回一个

FSDataOutputStream进程

元数据创建完成之后，我们需要提供一个接口用于连接DataNode并且进行相关的数据写入操作，这个时候我们使用的就是流式数据导入进程。那么FsDataOutputStream提供的还是一个访问接口，但是数据这次在进行写入的时候，就是通过流式写入的。我们写入数据的时候还是需要调用接口的。

（4）业务会在本地调用writeAPI接口，将数据写入到Client进程中。

（5） Client收到数据之后，会将数据通过FSDataOutputStream进程进行包装，包装为DFSOutputStream，联系DataNode，并和需要写入数据的DataNode建立起流水线。完成后，Client再通过自有协议，按照从DistributedFileSystem获取到的数据写入的数据块编号和位置信息（也就相当于是元数据创建时分配的写空间），写入数据到DataNode1，再由DataNode1复制到DataNode2,DataNode3

（创建数据副本机制，数据副本机制是节点之间的数据传输，所以相当于在进行实际的数据写入时，Client只写了一份数据，其他的副本数据是由DataNode之间进行拷贝和传输的）

（6）数据在写入成功之后，将会由DataNode向Client返回确认信息

（7）所有数据确认完成后，文件写入成功，业务调用HDFSClient关闭文件的写入进程。

（8）业务调用close关闭进程,flush后HDFSClient联系NameNode，确认数据写完成，NameNode更新元数据

HDFS数据读取流程

• HDFS数据读取流程

  • 客户端请求读取文件，Client通过自身的Distributed FileSystem进程向Namenode发起RPC请求
  • HDFSClient联系NameNode，获取到文件信息（数据块、DataNode位置信息）。
  • 业务应用调用readAPI读取文件。DistributedFile System通过对NameNode发出RPC请求，确定要读取文件的block的位置
  • HDFSClient根据从NameNode获取到的信息，(Client采用就近原则读取数据)。由FSDataInputStream包装一个DFSInputStream，用来与DataNode和NameNode的I/O通信。
  • HDFSClient会与多个DataNode通讯获取数据块。数据读取完成后，业务调用close关闭连接。

  根据数据的读进程，我们可以关注到如下的几个问题，首先第一个就是我们在进行读取的时候还是通过流式数据访问进程进行的读操作，这里就体现了HDFS的流式访问，也体现了HDFS的高吞吐量的特点，第二个就是关于数据副本机制的问题，数据副本机制其实可以理解为一个数据的多个副本没有主备关系，互为副本，实际在进行读取操作的时候，Client会选择读取就近的DataNode上的数据，这样可以极大的减小数据传输对于网络的影响。另外一个就是我们在进行读取操作的时候，不仅仅是只读一个副本的数据，读取是一个并发的读操作，所以各个副本都会进行数据的读取传输，这样就可以提升整体的数据传输效率，减小读取消耗的时间。

在HDFS中，为了保证数据的绝对安全性，我们默认会存储三份副本数据，所以和源数据一起，一个数据会被存储4份，我们认为A数据和B数据在一个服务器内的时候，距离为0，A数据和B数据在同一机架内的时候距离为2，认为A数据和B数据不在同一机架内的时候距离为4。

3.HDFS高级特性

HDFS元数据持久化健壮机制

• 重建失效数据盘的副本机制
  • Datanode和Namenode之间需要通过心跳机制来保证数据状态，由Namenode来决定Datanode是否需要上报完整性，如果Datanode由于损坏无法进行完整性上报，那么Namenode就认为Datanode已经失效，并且发起恢复重建进程恢复丢失的数据。
  • 在这里，首先我们需要明确一个概念就是，心跳其实并没有按照心跳信息的形式去发送。虽然我们说NameNode和DataNode之间是通过心跳机制去保障数据状态的，但是他们之间发送的并不是心跳报文，而是周期性上报数据完整性的报文，那么NameNode一旦收到了数据完整性报文，那么就等同于收到了心跳报文，所以两个报文其实是整合为一个报文进行发送的，如果作为NameNode没有收到周期性发送的数据完整性报文，也就相当于DataNode出现了故障。
• 数据均衡机制
  • 集群数据均衡主要是通过该机制保证各个节点中的数据量基本均衡，保证各节点整体的利用率基本相同，不会因为某一个节点承载了过多的任务而导致压力过大。
    

集群数据均衡主要是通过该机制保证各个节点中的数据量基本均衡，保证各节点整体的利用率基本相同，不会因为某一个节点承载了过多的任务而导致压力过大。这里说到的集群的数据均衡主要是由两个形式进行保证的，第一个，在数据写入的时候，我们通过三副本机制，就可以进行一次数据的均衡操作，我们在写入数据之前，首先会获取到节点的综合负载，根据负载的情况，选择当前最小的负载的设备，将数据写入。这样做理论上就会保证数据的均衡，但是会有一种情况，导致不均衡的状态出现，就是节点扩容，新添加的节点内没有任何数据，这时候它与旧节点之间就出现了不均衡的情况。均衡首先需要均衡服务来进行相关的信息收集和评估，然后在根据评估的情况，进行数据的迁移操作。

①均衡服务要求Namenode获取Datanode数据分布汇总情况

由于NameNode本身需要周期性的获取DataNode的数据完整性信息，那么

NameNode本身就可以根据自身的机制从DataNode上获取数据的分布情况，所以本身就存在着获取数据分布的能力，然后NameNode作为元数据维护节点，自身还可以进行该信息的汇总收集和存储，一方面NameNode从DataNode上获取了数据的分布情况，另一方面NameNode也根据该信息可以维护更新元数据，另外DataNode上报该信息也相当于是上报了心跳信息，告知了NameNode自身数据的完整性。所以在这里RebalancingServer可以直接向NameNode获取该信息，而不再需要自身获取，自身汇总。减小了进程执行的开销。

②服务查询到待均衡的节点之后，向Namenode请求对应数据的分布情况

均衡服务会根据NameNode上报的数据分布汇总的情况，决定哪一些节点需要进行数据的均衡操作。然后在根据分析的情况再向NameNode请求详细的数据分布情况，之后根据NameNode反馈回来的详细的数据分布情况，RebalancingServer就会制定策略，指定哪一些数据块是需要做迁移操作的。然后开始下发迁移的请求。

③每迁移一个数据块，均衡服务都需要拷贝这个数据块做备份

在迁移的过程中，由于迁移相当于是剪切的操作也可以理解为移动move操作，所以在迁移的过程中，为了保证数据的安全性，我们的RebalancingServer就需要对迁移中的数据做保护。迁移中的数据会由RebalancingServer做备份。相当于除了迁移操作之外，RebalancingServer还会对每一个迁移的数据做一次拷贝操作，那么一旦数据迁移完成之后，备份的数据块就会被从Rebalancing

Server中删除。

④从源节点向目的节点拷贝数据

在均衡的过程中，我们需要考虑一个问题，就是迁移对网络的影响，由于迁移是跨设备的操作，而且设备与设备之间是通过网络进行的连接，所以在进行迁移的时候，我们需要注意的一个问题就是网络带宽对迁移的影响。由于在迁移的过程中，迁移数据会对业务有一些影响，因为在迁移的过程中，数据有一部分是无法访问的，所以我们需要在业务空窗期进行数据的迁移是最合适的，那么业务的空窗期例如在视频网站中，每晚的凌晨时间就是空窗期，那么空窗期是有时间范围的，所以我们如果必须要保障在空窗期内将数据迁移完成，那么就必须考虑网络带宽对迁移的影响了。迁移的数据量/迁移的空窗期=迁移的网络带宽。

⑤迁移完成后，修改Namenode中的元数据信息

⑥向源端返回确认消息

⑦向迁移服务返回均衡完成消息，均衡服务释放拷贝的数据。

HDFS联邦

• HDFS联邦机制
  • Federation支持上层应用使用多个独立的基于NameNode/Namespace的文件系统。这些NameNode之间相互独立且不需要互相协调，各自分工管理自己的区域。一个Namespace使用一个blockpool管理数据块，每个blockpool内部自治，不会与其他blockpool交流。
    

Federation支持上层应用使用多个独立的基于NameNode/Namespace的文件系统。这些NameNode之间相互独立且不需要互相协调，各自分工管理自己的区域。一个Namespace使用一个blockpool管理数据块，每个blockpool内部自治，不会与其他blockpool交流。同时Federation中存在多个命名空间，可以使用ClientSideMountTable对命名空间划分和管理。

扩展性：支持NameNode/Namespace水平扩展，后向兼容，结构简单。

性能：文件操作的性能不再制约于单个NameNode的吞吐量，支持多个NameNode。隔离性：可按照应用程序的用户和种类分离Namespacevolume，进而增强了隔离性。

• NameSpace（NS）：
  • 命名空间：HDFS的命名空间包含目录、文件和块。
• Pool：block pool.Federation
  • HDFS中有多个独立的命名空间（Namespace） ，并且每一个命名空间使用一个块池。Blockpool(块池)是属于单个命名空间的一组block(块)，每一个DataNode为所有的blockpool存储块。DataNode是一个物理概念，而blockpool是一个重新将block划分的逻辑概念。

HDFS数据存储策略

• 标签存储

  用户通过数据特征配置HDFS数据块存放策略，即为一个HDFS目录设置一个标签表达式，每个DataNode可以对应一个或多个标签；当基于标签的数据块存放策略为指定目录下的文件选择DataNode节点进行存放时，根据文件的标签表达式选择出将要存放的DataNode节点范围，然后在这个DataNode节点范围内，遵守下一个指定的数据块存放策略进行存放。

HDFSNameNode自动选择DataNode保存数据的副本。在实际业务中，存在以下场景：

DataNode上存在的不同的存储设备，数据需要选择一个合适的存储设备分级存储数据。

DataNode不同目录中的数据重要程度不同，数据需要根据目录标签选择一个合适的DataNode节点保存。

DataNode集群使用了异构服务器，关键数据需要保存在具有高度可靠性的节点组中。

数据存储策略可以广泛的应用于各种业务，就像存储中使用的分级存储一样，在HDFS中，我们一样可以提供很高的一个存储的策略，用于做不同业务的数据保证，比如，作为一个视频网站，那么新上架一个电视剧，那么访问流量就会很大，这个时候就可以将数据放在内存虚拟硬盘或者是SSD中，电视剧结局之后，访问量就会逐渐减小，这个时候就会访问量逐渐较小，我们就可以将数据放在SAS硬盘中，随着时间增长，访问量很小的时候就可以将数据放在SATA硬盘或者进行归档。HDFS的策略和以上存储的策略比较类似，但是HDFS存放数据涉及的根据访问量迁移的情况不多，主要是在一开始就进行数据的相关存放操作，比如关键业务的数据就可以放在访问快可靠性高的介质中，普通业务就可以提供一个正常的保护策略

• 强制机架组存储约束：
  • 在使用约束之前，首先需要配置约束，我们需要为数据副本指定强制机架组。
  • 第一份副本将从强制机架组（机架组2）中选出，如果在强制机架组中没有可用节点，则写入失败。所以第一份副本是做强制保护的，必须保障写入成功。
  • 第二份副本将从本地客户端机器或机架组中的随机节点中(当客户端机器机架组不为强制机架组时)选出。

配置DataNode使用节点组存储：关键数据根据实际业务需要保存在具有高度可靠性的节点中，此时DataNode组成了异构集群。通过修改DataNode的存储策略，系统可以将数据强制保存在指定的节点组中。

节点组存储和标签存储最大的不同主要有以下的几个方面：

①节点组存储是由DataNode执行的，标签存储是由NameNode来做的。

②节点组存储的作用对象是副本数据。控制的源是第一份数据。标签存储作用对象是第一份数据的写入，控制的源是元数据中的目录标签。

③节点组存储保证的是数据的可靠性，标签存储保障的不仅是数据的可靠性还有安全性和可用性，所以标签存储的控制范围要比节点组存储的范围要大。

使用约束：在使用约束之前，首先需要配置约束，我们需要为数据副本指定强制机架组。

第一份副本将从强制机架组（机架组2）中选出，如果在强制机架组中没有可用节点，则写入失败。所以第一份副本是做强制保护的，必须保障写入成功。

第二份副本将从本地客户端机器或机架组中的随机节点中(当客户端机器机架组不为强制机架组时)选出。

强制机架组只会存放一份副本数据，所以当节点需要创建副本的时候，首先我们需要将数据写入到强制机架组中，当数据写第二份副本的时候，我们就需要检查节点所属的机架组是否是强制机架组，如果是，那么根据强制机架组只存放一份副本的强制策略，我们就不能再把数据写入到本机架组了，这个时候就需要随机选机架组写入。如果节点所属的机架组不是强制机架组，那么就正常的进行写入，第一份数据——强制机架组，

第二份数据——本地设备或本地机架组

第三份副本将从其他机架组中选出。各副本应存放在不同的机架组中。

份副本是做强制保护的，必须保障写入成功。

第二份副本将从本地客户端机器或机架组中的随机节点中(当客户端机器机架组不为强制机架组时)选出。

强制机架组只会存放一份副本数据，所以当节点需要创建副本的时候，首先我们需要将数据写入到强制机架组中，当数据写第二份副本的时候，我们就需要检查节点所属的机架组是否是强制机架组，如果是，那么根据强制机架组只存放一份副本的强制策略，我们就不能再把数据写入到本机架组了，这个时候就需要随机选机架组写入。如果节点所属的机架组不是强制机架组，那么就正常的进行写入，第一份数据——强制机架组，

第二份数据——本地设备或本地机架组

第三份副本将从其他机架组中选出。各副本应存放在不同的机架组中。

如果所需副本的数量大于可用的机架组数量，则会将多出的副本存放在随机机架组中