node分布式存储
① 试述HDFS联邦能够解决什么问题
HDFS联邦能够解决对文件系统数据的流式处理访问。HDFS 提供文件权限和身份验证。
HDFS的简介：
HDFS（Hadoop Distributed File System）是hadoop项目的核心子项目，是分布式计算中数据存储管理的基础。是基于流数据模式访问和处理超大文件的需求而开发的， 可以运行于廉价的商用服务器上。
它所具有的高容错、 高可靠性、 高可扩展性、 高获得性、 高吞吐率等特征为海量数据提供了不怕故障的存储， 为超大数据集（Large Data Set） 的应用处理带来了很多便利。
HDFS是开源的，存储着Hadoop应用将要处理的数据，类似于普通的Unix和linux文件系统，不同的是它是实现了google的GFS文件系统的思想，是适用于大规模分布式数据处理相关应用的、可扩展的分布式文件系统。
HDFS的功能：
1）数据的分布式存储和处理。
2）Hadoop 提供了一个命令接口来与 HDFS 进行交互。
3）namenode 和 datanode 的内置服务器可帮助用户轻松检查群集的状态。
4）对文件系统数据的流式处理访问。
5）HDFS 提供文件权限和身份验证。
② 什么是HDFS
HDFS，全称Hadoop Distributed File System，意思是分布式文件系统。
Hadoop分布式文件系统是指被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。
③ 第三章 大数据存储
一，HDFS的基本特征与构架
1.基本特征
（1）大规模数据分布存储能力：以分布式存储能力和良好的可扩展性。（基于大量分布节点上的本地文件系统，构建一个逻辑上具有巨大容量的分布式文件系统，并且整个文件系统的容量可随集群中节点的增加而线性扩展）
（2）高并发访问能力：提供很高的数据访问宽带（高数据吞吐率），并且可以把带宽的大小等比例扩展到集群中的全部节点上
（3）强大的容错能力：（设计理念中硬件故障被视作常态）保证在经常有节点发生硬件故障的情况下正确检测硬件故障，并且能自动从故障中快速恢复，确保数据不丢失（采用多副本数据块形式存储）
（4）顺序式文件访问：（大数据批处理都是大量简单数据记录的顺序处理）对顺序读进行了优化，支持大量数据的快速顺序读出，代价是对于随机的访问负载较高
（5）简单的一致性模型（一次写多次读）：支持大量数据的一次写入，多次读取；不支持已写入数据的更新操作，但允许在文件尾部添加新的数据
（6）数据块存储模式：默认的块大小是64MB。好处：减少元数据的数量，允许这些数据块通过随机方式选择节点，分布存储在不同地方
2.基本框架与工作过程
（1）基本组成结构与文件访问过程
[1]HDFS；一个建立在一组分布式服务器节点的本地文件系统之上的分布式文件系统（采用经典主-从结构）
[2]主控节点NameNode:
1）是一个主服务器，用来管理整个文件系统的命名空间和元数据,以及处理来自外界的文件访问请求
2）保存了文件系统的三中元数据
命名空间：整个分布式文件系统的目录结构
数据块与文件名的映射表
每个数据块副本的位置信息，每一个数据块默认有3个副本
[3]从节点DataNode：
1）用来实际存储和管理文件的数据块
2）为了防止数据丢失，每个数据块默认有3个副本，且3个副本会分别复制在不同节点上，以避免一个节点失效造成一个数据块的彻底丢失
[4]程序访问文件时，实际文件数据流并不会通过NameNode传送，而是从NameNode获得所需访问数据块的存储位置信息后，直接去访问对应的DataNode获取数据
[5]设计好处：
1）可以允许一个文件的数据能同时在不同DataNode上并发访问，提高数据访问的速度
2）减少NameNode的负担，避免使NameNode成为数据访问瓶颈
[6]基本访问过程：
1）首先，用户的应用程序通过HDFS的客户端程序将文件名发送至NameNode
2）NameNode接收到文件名之后，在HDFS目录中检索文件名对应的数据块，再根据数据块信息找到保存数据块的DataNode地址，讲这些地址回送到客户端
3）客户端接收到这些DataNode地址之后，与这些DataNode并行的进行数据传输操作，同时将操作结果的相关日志提交到NameNode
2.数据块
（1）为了提高硬盘的效率，文件系统中最小的数据读写单元是数据块
（2）HDFS数据块的默认大小是64MB，实际部署中，可能会更多
（3）将数据块设置大的原因是减少寻址开销的时间
（4）当应用发起数据传输请求：
[1]NameNode首先检索文件对应的数据块信息，找到数据块对应的DataNode
[2]DataNode根据数据块信息在自身的存储中寻找相应的文件，进而与应用程序之间交换数据
[3]因为检索过程是但进行，所以要增加数据块大小，这样就可以减少寻址的频度和时间开销
3.命名空间
（1）文件命名遵循“目录/子目录/文件”格式
（2）通过命令行或者是API可以创建目录，并且将文件保存在目录中。可以对文件进行创建，删除，重命名操作
（3）命令空间由NameNode管理。所有对命名空间的改动都会被记录
（4）允许用户配置文件在HDFS上保存的副本数量，保存的副本数称作“副本因子”
4.通信协议
（1）采用TCP协议作为底层的支撑协议
（2）应用协议
[1]应用可以向NameNode主动发起TCP连接
[2]应用和NameNode交互协议称为Client协议
[3]NameNode和DataNode交互的协议称为DataNode协议
（3）用户和DataNode的交互是通过发起远程调用（RPC），并由NameNode响应来完成的。另外，NameNode不会主动发起远程过程调用请求
5.客户端：是用户和HDFS通信最常见的渠道，部署的HDFS都会提供客户端
二，HDFS可靠性设计
1.HDFS数据块多副本存储设计
（1）采用了在系统中保存多个副本的方式保存数据，且同一个数据块的多个副本会存放在不同节点上
（2）优点：
[1]采用多副本，可以让客户从不同数据块中读取数据，加快传输速度
[2]HDFS的DataNode之间通过网络传输数据，如果采用多个副本可以判断数据传输是否出错
[3]多副本可以保证某个DataNode失效的情况下，不会丢失数据
2.可靠性的设计实现
（1）安全模式：
[1]HDFS启动时，NameNode进入安全模式
[2]处于安全模式的NameNode不能做任何文本操作，甚至内部的副本创建不允许
[3]NameNode需要和各个DataNode通信，获得其中保存的数据块信息，并对数据块信息进行检查
[4]只有通过了NameNode检查，一个数据块被认为安全。当被认为安全的数据块所占比例达到某个阈值，NameNode退出
（2）SecondaryNmaeNode
[1]使用它来备份NameNode元数据，以便在其失效时能从中恢复出其上的元数据
[2]它充当NameNode的一个副本，本身并不处理任何请求。
[3]作用：周期性保存NameNode的元数据
（3）心跳包和副本重新创建
[1]心跳包：位于HDFS核心的NameNode，通过周期性的活动检查DataNode的活动
[2]检测到DataNode失效，保存在其上的数据不可用。则其上保存的副本需要重新创建这个副本，放到另外可用的地方
（4）数据一致性
[1]采用了数据校验和机制
[2]创建文件时，HDFS会为这个文件生成一个校验和，校验和文件和文件本身保存在同一空间上，
[3]传输数据时会将数据与校验和一起传输，应用收到数据后可以进行校验
（5）租约
[1]防止同一个文件被多个人写入数据
[2]NameNode保证同一个文件只会发放一个允许的租约，可以有效防止出现多人写入的情况
（6）回滚
三，HDFS文件存储组织与读写
1.文件数据的存储组织
（1）NameNode目录结构
[1]借助本地文件系统来保存数据，保存文件夹位置由配置选项（{dfs.name.dir}/{/tmp/dfs/name}）决定
[2]在NameNode的${dfs.name.dir}之下有3个文件夹和1个文件：
1）current目录：
文件VERSION:保存了当前运行的HDFS版本信息
FsImages:是整个系统的空间镜像文件
Edit：EditLog编辑文件
Fstime：上一次检查点时间
2）previous.checkpoint目录：和上一个一致，但是保存的是上一次检查点的内容
3）image目录：旧版本的FsImage存储位置
4）in_use.look:NameNode锁，只在NameNode有效（启动并且能和DataNode正常交互）时存在。
（2）DataNode目录结构
[1]借助本地文件系统来保存数据。保存文件夹位置由配置选项{dfs.data.dir}决定
[2]在其之下有4个子目录和2个文件
1）current目录：已经成功写入的数据块，以及一些系统需要的文件
a)文件VERSION：保存了当前运行的HDFS版本信息
b)subdirXX:当同一目录下文件超过一定限制，新建一个目录，保存多出来的数据块和元数据
2）tmp目录和blockBeingWritten目录：正在写入的数据块，是HDFS系统内部副本创建时引发的写入操作对应的数据块
3）detach目录：用于DataNode升级
4）Storage目录：防止版本不同带来风险
5）in_user.lock文件：DataNode锁。只有在DataNode有效时存在。
（3）CheckPointNode目录结构：和上一个基本一致
2.数据的读写过程
（1）数据读取过程
[1]首先，客户端调用FileSystem实例的open方法，获得这个文件对应的输入流，在HDFS中就是DFSInputStream
[2]构造第一步的输入流时，通过RPC远程调用NameNode可以获得NameNode中此文件对应的数据块保存位置，包括这个文件副本的保存位置（注：在输入流中会按照网络拓扑结构，根据与客户端距离对DataNode进行简单排序）
[3]-[4]获得此输入流后，客户端调用READ方法读取数据。输入流选择最近的DFSInputStream会根据前面的排序结果，选择最近的DataNode建立连接并读取数据。
[5]如果已达到数据块末端，关闭这个DataNode的连接，然后重新查找下一个数据块
[6]客户端调用close，关闭输入流DFSInputStream
（2）数据输入过程
[1]-[2]:客户端调用FileSystem实例的create方法，创建文件。检查后，在NameNode添加文件信息，创建结束之后，HDFS会返回一个输出流DFSDataOutputStream给客户端
[3]调用输出流的write方法向HDFS中对应的文件写入数据。
数据首先会被分包，这些分包会写入一个输出流的内部队列Data队列中，接收完整数据分包，输出流回想NameNode申请保存文件和副本数据块的若干个DataNode
[4]DFSDataOutputStream会（根据网络拓扑结构排序）将数据传输给距离上最短的DataNode，这个节点接收到数据包后传给下一个。数据在各节点之间通过管道流通，减少传输开销
[5]数据节点位于不同机器上，数据需要通过网络发送。（为保证数据节点数据正确，接收到数据的节点要向发送者发送确认包）
[6]执行3-5知道数据全部写完，DFSDataInputStream继续等待知道所有数据写入完毕并确认，调用complete方法通知NameNode文件写入完成
[7]NameNode接收到complete消息之后，等待相应数量的副本写入完毕后，告知客户端
传输过程，当某个DataNode失效，HDFS执行：
1）关闭数据传输的管道
2）将等待ACK队列的数据放到Data队列头部
3）更新正常DataNode中所有数据块版本。当失效的DataNode重启，之前的数据块会因为版本不对被清除
4）在传输管道中删除失效的DataNode,重新建立管道并发送数据包
4.HDFS文件系统操作命令
（1）HDFS启动与关闭
[1]启动过程：
1）进入到NameNode对应节点的Hadoop安装目录
2）执行启动脚本:bin/start-dfs.sh
[2]关闭过程:bin/stop-dfs.sh
（2）文件操作命令格式与注意事项
[1]基本命令格式：
1）bin/hadoop dfs-cmd <args> args-> scheme://authority/path
2）args参数基本格式前面是scheme，authority是机器地址和对应端口
a)本地文件，scheme是file
b)HDFS上文件，scheme是hdfs
（3）文件操作基本格式
[1]hadoop dfs-cat URL [URL ...]
[2]作用：将参数所指示文件内容输出到stdout
④ HDFS 为何在大数据领域经久不衰
大数据中最宝贵、最难以代替的就是数据，一切都围绕数据。
HDFS是最早的大数据存储系统，存储着宝贵的数据资产，各种新算法、框架要想得到广泛使用，必须支持HDFS，才能获取已存储在里面的数据。所以大数据技术越发展，新技术越多，HDFS得到的支持越多，越离不开HDFS。 HDFS也许不是最好的大数据存储技术，但依然是最重要的大数据存储技术 。
HDFS是如何实现大数据高速、可靠的存储和访问的呢？
Hadoop分布式文件系统HDFS的设计目标是管理数以千计的服务器、数以万计的磁盘，将大规模的服务器计算资源当作一个单一存储系统进行管理，对应用程序提供数以PB计的存储容量，让应用程序像使用普通文件系统一样存储大规模的文件数据。
文件以多副本的方式进行存储：
缺点：
优点：
HDFS的大容量存储和高速访问的实现。
RAID将数据分片后，在多块磁盘上并发进行读写访问，提高了存储容量、加快了访问速度，并通过数据冗余校验提高了数据可靠性，即使某块磁盘损坏也不会丢数据。将RAID的设计理念扩大到整个分布式服务器集群，就产生了分布式文件系统，这便是Hadoop分布式文件系统的核心原理。
和RAID在多个磁盘上进行文件存储及并行读写的思路一样，HDFS是在一个大规模分布式服务器集群上，对数据分片后进行并行读写及冗余存储。因为HDFS可部署在一个大的服务器集群，集群中所有服务器的磁盘都可供HDFS使用，所以整个HDFS的存储空间可以达到PB级。
HDFS是主从架构。一个HDFS集群会有一个NameNode（命名节点，简称NN），作为主服务器（master server）。
HDFS公开了文件系统名称空间，允许用户将数据存储在文件中，就好比我们平时使用os中的文件系统一样，用户无需关心底层是如何存储数据的。 在底层，一个文件会被分成一或多个数据块，这些数据库块会被存储在一组数据节点中。在CDH中数据块的默认128M。 在NameNode，可执行文件系统的命名空间操作，如打开，关闭，重命名文件等。这也决定了数据块到数据节点的映射。
HDFS被设计为可运行在普通的廉价机器上，而这些机器通常运行着一个Linux操作系统。一个典型的HDFS集群部署会有一个专门的机器只能运行 NameNode ，而其他集群中的机器各自运行一个 DataNode 实例。虽然一台机器上也可以运行多个节点，但不推荐。
负责文件数据的存储和读写操作，HDFS将文件数据分割成若干数据块（Block），每个DataNode存储一部分Block，这样文件就分布存储在整个HDFS服务器集群中。
应用程序客户端（Client）可并行访问这些Block，从而使得HDFS可以在服务器集群规模上实现数据并行访问，极大提高访问速度。
HDFS集群的DataNode服务器会有很多台，一般在几百台到几千台，每台服务器配有数块磁盘，整个集群的存储容量大概在几PB~数百PB。
负责整个分布式文件系统的元数据（MetaData）管理，即文件路径名、数据块的ID以及存储位置等信息，类似os中的文件分配表（FAT）。
HDFS为保证数据高可用，会将一个Block复制为多份（默认3份），并将多份相同的Block存储在不同服务器，甚至不同机架。当有磁盘损坏或某个DataNode服务器宕机，甚至某个交换机宕机，导致其存储的数据块不能访问时，客户端会查找其备份Block访问。
HDFS中，一个文件会被拆分为一个或多个数据块。默认每个数据块有三个副本，每个副本都存放在不同机器，而且每一个副本都有自己唯一的编号：
文件/users/sameerp/data/part-0的复制备份数设为2，存储的BlockID分别为1、3：
上述任一台服务器宕机后，每个数据块都至少还有一个备份存在，不会影响对文件/users/sameerp/data/part-0的访问。
和RAID一样，数据分成若干Block后，存储到不同服务器，实现数据大容量存储，并且不同分片的数据能并行进行读/写操作，实现数据的高速访问。
副本存放：NameNode节点选择一个DataNode节点去存储block副本的过程，该过程的策略是在可靠性和读写带宽间权衡。
《Hadoop权威指南》中的默认方式：
Google大数据“三驾马车”的第一驾是GFS（Google 文件系统），而Hadoop的第一个产品是HDFS，分布式文件存储是分布式计算的基础。
这些年来，各种计算框架、各种算法、各种应用场景不断推陈出新，但大数据存储的王者依然是HDFS。
磁盘介质在存储过程中受环境或者老化影响，其存储的数据可能会出现错乱。
HDFS对存储在DataNode上的数据块，计算并存储校验和（CheckSum）。在读数据时，重新计算读取出来的数据的校验和，校验不正确就抛异常，应用程序捕获异常后就到其他DataNode上读取备份数据。
DataNode监测到本机的某块磁盘损坏，就将该块磁盘上存储的所有BlockID报告给NameNode，NameNode检查这些数据块还在哪些DataNode上有备份，通知相应的DataNode服务器将对应的数据块复制到其他服务器上，以保证数据块的备份数满足要求。
DataNode会通过心跳和NameNode保持通信，如果DataNode超时未发送心跳，NameNode就会认为这个DataNode已经宕机失效，立即查找这个DataNode上存储的数据块有哪些，以及这些数据块还存储在哪些服务器上，随后通知这些服务器再复制一份数据块到其他服务器上，保证HDFS存储的数据块备份数符合用户设置的数目，即使再出现服务器宕机，也不会丢失数据。
NameNode是整个HDFS的核心，记录着HDFS文件分配表信息，所有的文件路径和数据块存储信息都保存在NameNode，如果NameNode故障，整个HDFS系统集群都无法使用；如果NameNode上记录的数据丢失，整个集群所有DataNode存储的数据也就没用了。
所以，NameNode高可用容错能力非常重要。NameNode采用主从热备的方式提供高可用服务：
集群部署两台NameNode服务器：
两台服务器通过Zk选举，主要是通过争夺znode锁资源，决定谁是主服务器。而DataNode则会向两个NameNode同时发送心跳数据，但是只有主NameNode才能向DataNode返回控制信息。
正常运行期，主从NameNode之间通过一个共享存储系统shared edits来同步文件系统的元数据信息。当主NameNode服务器宕机，从NameNode会通过ZooKeeper升级成为主服务器，并保证HDFS集群的元数据信息，也就是文件分配表信息完整一致。
软件系统，性能差点，用户也许可接受；使用体验差，也许也能忍受。但若可用性差，经常出故障不可用，就麻烦了；如果出现重要数据丢失，那开发摊上大事。
而分布式系统可能出故障地方又非常多，内存、CPU、主板、磁盘会损坏，服务器会宕机，网络会中断，机房会停电，所有这些都可能会引起软件系统的不可用，甚至数据永久丢失。
所以在设计分布式系统的时候，软件工程师一定要绷紧可用性这根弦，思考在各种可能的故障情况下，如何保证整个软件系统依然是可用的。
## 6 保证系统可用性的策略
任何程序、任何数据，都至少要有一个备份，也就是说程序至少要部署到两台服务器，数据至少要备份到另一台服务器上。此外，稍有规模的互联网企业都会建设多个数据中心，数据中心之间互相进行备份，用户请求可能会被分发到任何一个数据中心，即所谓的异地多活，在遭遇地域性的重大故障和自然灾害的时候，依然保证应用的高可用。
当要访问的程序或者数据无法访问时，需要将访问请求转移到备份的程序或者数据所在的服务器上，这也就是 失效转移 。失效转移你应该注意的是失效的鉴定，像NameNode这样主从服务器管理同一份数据的场景，如果从服务器错误地以为主服务器宕机而接管集群管理，会出现主从服务器一起对DataNode发送指令，进而导致集群混乱，也就是所谓的“脑裂”。这也是这类场景选举主服务器时，引入ZooKeeper的原因。ZooKeeper的工作原理，我将会在后面专门分析。
当大量的用户请求或者数据处理请求到达的时候，由于计算资源有限，可能无法处理如此大量的请求，进而导致资源耗尽，系统崩溃。这种情况下，可以拒绝部分请求，即进行 限流 ；也可以关闭部分功能，降低资源消耗，即进行 降级 。限流是互联网应用的常备功能，因为超出负载能力的访问流量在何时会突然到来，你根本无法预料，所以必须提前做好准备，当遇到突发高峰流量时，就可以立即启动限流。而降级通常是为可预知的场景准备的，比如电商的“双十一”促销，为了保障促销活动期间应用的核心功能能够正常运行，比如下单功能，可以对系统进行降级处理，关闭部分非重要功能，比如商品评价功能。
HDFS是如何通过大规模分布式服务器集群实现数据的大容量、高速、可靠存储、访问的。
1.文件数据以数据块的方式进行切分，数据块可以存储在集群任意DataNode服务器上，所以HDFS存储的文件可以非常大，一个文件理论上可以占据整个HDFS服务器集群上的所有磁盘，实现了大容量存储。
2.HDFS一般的访问模式是通过MapRece程序在计算时读取，MapRece对输入数据进行分片读取，通常一个分片就是一个数据块，每个数据块分配一个计算进程，这样就可以同时启动很多进程对一个HDFS文件的多个数据块进行并发访问，从而实现数据的高速访问。关于MapRece的具体处理过程，我们会在专栏后面详细讨论。
3.DataNode存储的数据块会进行复制，使每个数据块在集群里有多个备份，保证了数据的可靠性，并通过一系列的故障容错手段实现HDFS系统中主要组件的高可用，进而保证数据和整个系统的高可用。
⑤ Hadoop分布式文件系统（HDFS）会不会被淘汰
首先我们应该更具体的理解这样一个现象，为什么流行的技术闭闭敏框架会被淘汰。谈到淘汰，常见两种情况：
第一：应用模式被淘汰了，例如：BB机，功能机，最终被智能机淘汰，胶卷被数码相机淘汰，即便诺基亚的功能机做得再完美，也会被淘汰。软件方面例如：终端的字处理，邮件收发等应用软件被视窗应用软件淘汰。
第二：技术升级，新技术弥补了老技术的缺陷，并且引入了更多有优势的功能。例如：Springframework的横空出世，配合Hibernate，在具有同样功效的情况下，解决了EJB的部署复杂，体态臃肿，计算效率低，用灵活性，面向程序员的友好性，淘汰了曾经企业级经典的EJB。
那么对于Hadoop分布式文件系统（HDFS），我们要讨论它的淘汰可能性，淘汰时间，首先我们就要看它为什么要被淘汰的因素。从模式上，分布式文件系统是大数据存储技术极为重要的一个领域，我们还看不到分布式文件系统有被淘汰的任何理由，那么我就再看技术升级是否有淘汰它的可能性。
谈技术升级，首先要看HDFS的缺点，然后再看这种缺点的解决办法，是否会带来新的技术框架，然后让HDFS埋进历史的垃圾堆。
HDFS为集中式态桥协调架构，namenode若是单节点，部署并不复杂，但是namenode作为单节点无法可靠的运行在生产环境，必须对namenode实现双机HA，那么部署复杂度就变得极高，这时候需要在namenode，datanode的基础上再引入namenode active，namenode standby的概念，需要引入QJM的元数据共享存储并基于Paxos做一致性协调，另外需要引入ZKFC和ZooKeeper，解决主备选举，健康探测，主备切换等操作。
因此HDFS的部署复杂度完全是因为namenode HA导致的。这是集中式管理的分布式架构一个原生问题，如果在这个地方进行优化的话，那么就是简化QJM，ZKFC，ZooKeeper的多组服务，用一组服务来代替，但是namenode和datanode的分布式数据块的读写，复制，恢复机制，目前看非常成熟，高效，这是核心问题，并不是缺点，不需要更具颠覆性的优化。
由于namenode在内存中记录了所有数据块（block 默认128M）的信息，索引了数据块与datanode的关系，并且构建了文件系统树，因此可想而知namenode的元数据内存区是大量占用内存，这是没有上限的。对于较大型数据存储项目，例如上百个datanode节点和上千万个数据块的容量来说，元数据在namenode的内存大概能控制在32G以内，这是还没问题的，但是对于构建海量数据中心的超大型项目，这个问题就好像达摩克斯之剑，首先堆内存超过临界范围导致的内存寻址性能问题不说，一旦namenode内存超限到单机内存可承载的物理上最大承受范围，整个hdfs数据平台将面临停止服务。
这个问题的本质还是Google设计GFS时候采用粗放的实用主义，先把元数据都交给主节点在内存中节制，超大问题以后再解决。目前Google的GFS2设计上，已经将元数据在内存中迁移至了BigTable上，那么问题就来了：“BigTable基于GFS，而GFS2的元数据基于BigTable”？有点鸡生蛋还是蛋生鸡的自相矛盾。是的，看似矛盾实质轿枝上是架构的嵌套复用，可以这么去解读：GFS2是基于<基于GFS的BigTable的元数据存储>的下一代GFS架构。用BigTable的k-v存储模型放GFS2的元数据，虽然没有内存高效，但是够用，而且可以无限存储，用BigTable专门存储元数据形成的k-v记录最终保存成GFS数据块，因此在GFS的元数据内存中只需少量的内存占用，就能支撑天量的真正应用于数据块存储的GFS2元数据。
基于GFS2的设计思想，我相信下一代HDFS应该也是这样的方案去解决元数据的内存瓶颈问题，也就是基于<基于HDFS的HBase的元数据存储>的下一代HDFS架构。那么HDFS的元数据瓶颈问题将被彻底解决，很难看到比这更具优势的替代性技术框架了。
如下图所示：
副本数默认为3最大的问题就是占空间，这几乎是所有传统分布式文件系统（DFS）的通病。因此HDFS集群的默认空间利用率只有33.3%，这么低的利用率显然不符合一些场景，例如长期的冷数据备份，那么有没有更好的方式呢？是有的，目前比较成熟的方案就是纠删码技术，类似raid5，raid6，HDFS 3.0版本以后支持这种模式，叫做Erasure Coding(EC)方案。
HDFS是怎么通过EC方案解决磁盘利用率的问题呢？我们先聊点比较硬的原理，说说EC方案之一的条形布局：
首先数据文件写的时候会向N个节点的块(Block)依次写入，N个Block会被切成多组条(stripe 1... stripe n)，如果分布式环境有五个存储节点(DataNode)，那么就把stripe切成3个单元(cell)，然后再根据这3个cell计算出2个校验cell，然后这5个cell（3个data+2个parity）分别写入5个Block中。数据条就这么依次轮巡的方式，将校验块的位置轮换存储在不同Block上，直至写满，这样校验块的分布可以更均匀。
其次再说取数据，取数据每次只从3个DataNode中各取出1个cell，如果这3个cell都是数据cell，那么就成功拿到一组数据条stripe，如果有一个cell是校验cell，那么就能通过校验cell和另外2个数据cell计算出第3个数据cell，完成数据条stripe的组合。这种情况下，即便是5个datanode节点有2个datanode宕机了，另外3个datanode也能通过校验码计算完成剩余2个节点的数据，这就是利用纠删码技术实现数据冗余的原理。
通过这种方式，我们就比传统2副本50%，3副本33.3%的多副本模式要省空间，EC中2+1可以达到66.7%的磁盘利用率，例子是3+2可以达到60%的磁盘利用率
但是其问题是特别消耗CPU计算，上面那种读取情况，五分之三的读取数据条时间都要进行校验码计算。因此可以利用Intel CPU推出的ISA-L底层函数库专门用于提升校纠删码算法的编解码性能。通常情况下，纠删码用于冷数据的冗余，也就是不经常访问，但又必须联机存储以备查询的数据。除了磁盘利用率，多副本方式用空间换效率的方式肯定是最好，没什么问题。