hdfs存储模型

❶ Hadoop系列之HDFS架构

    本篇文章翻译了Hadoop系列下的 HDFS Architecture ，原文最初经过笔者翻译后大概有6000字，之后笔者对内容进行了精简化压缩，从而使笔者自己和其他读者们阅读本文时能够更加高效快速的完成对Hadoop的学习或复习。本文主要介绍了Hadoop的整体架构，包括但不限于节点概念、命名空间、数据容错机制、数据管理方式、简单的脚本命令和垃圾回收概念。

    PS：笔者新手一枚，如果看出哪里存在问题，欢迎下方留言！

    Hadoop Distributed File System（HDFS）是高容错、高吞吐量、用于处理海量数据的分布式文件系统。

    HDFS一般由成百上千的机器组成，每个机器存储整个数据集的一部分数据，机器故障的快速发现与恢复是HDFS的核心目标。

    HDFS对接口的核心目标是高吞吐量而非低延迟。

    HDFS支持海量数据集合，一个集群一般能够支持千万以上数量级的文件。

    HDFS应用需要对文件写一次读多次的接口模型，文件变更只支持尾部添加和截断。

    HDFS的海量数据与一致性接口特点，使得迁移计算以适应文件内容要比迁移数据从而支持计算更加高效。

    HDFS支持跨平台使用。

    HDFS使用主从架构。一个HDFS集群由一个NameNode、一个主服务器（用于管理系统命名空间和控制客户端文件接口）、大量的DataNode（一般一个节点一个，用于管理该节点数据存储）。HDFS对外暴露了文件系统命名空间并允许在文件中存储用户数据。一个文件被分成一个或多个块，这些块存储在一组DataNode中。NameNode执行文件系统命名空间的打开关闭重命名等命令并记录着块和DataNode之间的映射。DataNode用于处理客户端的读写请求和块的相关操作。NameNode和DataNode一般运行在GNU/Linux操作系统上，HDFS使用Java语言开发的，因此NameNode和DataNode可以运行在任何支持Java的机器上，再加上Java语言的高度可移植性，使得HDFS可以发布在各种各样的机器上。一个HDFS集群中运行一个NameNode，其他机器每个运行一个（也可以多个，非常少见）DataNode。NameNode简化了系统的架构，只用于存储所有HDFS元数据，用户数据不会进入该节点。下图为HDFS架构图：

    HDFS支持传统的分层文件管理，用户或者应用能够在目录下创建目录或者文件。文件系统命名空间和其他文件系统是相似的，支持创建、删除、移动和重命名文件。HDFS支持用户数量限制和访问权限控制，不支持软硬链接，用户可以自己实现软硬链接。NameNode控制该命名空间，命名空间任何变动几乎都要记录到NameNode中。应用可以在HDFS中对文件声明复制次数，这个次数叫做复制系数，会被记录到NameNode中。

    HDFS将每个文件存储为一个或多个块，并为文件设置了块的大小和复制系数从而支持文件容错。一个文件所有的块（除了最后一个块）大小相同，后来支持了可变长度的块。复制系数在创建文件时赋值，后续可以更改。文件在任何时候只能有一个writer。NameNode负责块复制，它周期性收到每个数据节点的心跳和块报告，心跳表示数据节点的正常运作，块报告包含了这个DataNode的所有块。

    副本存储方案对于HDFS的稳定性和性能至关重要。为了提升数据可靠性、灵活性和充分利用网络带宽，HDFS引入了机架感知的副本存储策略，该策略只是副本存储策略的第一步，为后续优化打下基础。大型HDFS集群一般运行于横跨许多支架的计算机集群中，一般情况下同一支架中两个节点数据传输快于不同支架。一种简单的方法是将副本存放在单独的机架上，从而防止丢失数据并提高带宽，但是增加了数据写入的负担。一般情况下，复制系数是3，HDFS存储策略是将第一份副本存储到本地机器或者同一机架下一个随机DataNode，另外两份副本存储到同一个远程机架的不同DataNode。NameNode不允许同一DataNode存储相同副本多次。在机架感知的策略基础上，后续支持了 存储类型和机架感知相结合的策略 ，简单来说就是在机架感知基础上判断DataNode是否支持该类型的文件，不支持则寻找下一个。

    HDFS读取数据使用就近原则，首先寻找相同机架上是否存在副本，其次本地数据中心，最后远程数据中心。

    启动时，NameNode进入安全模式，该模式下不会发生数据块复制，NameNode接收来自DataNode的心跳和块报告，每个块都有一个最小副本数量n，数据块在NameNode接受到该块n次后，认为这个数据块完成安全复制。当完成安全复制的数据块比例达到一个可配的百分比值并再过30s后，NameNode退出安全模式，最后判断是否仍然存在未达到最小复制次数的数据块，并对这些块进行复制操作。

    NameNode使用名为EditLog的事务日志持续记录文件系统元数据的每一次改动（如创建文件、改变复制系数），使用名为FsImage的文件存储全部的文件系统命名空间（包括块到文件的映射关系和文件系统的相关属性），EditLog和FsImage都存储在NameNode本地文件系统中。NameNode在内存中保存着元数据和块映射的快照，当NameNode启动后或者某个配置项达到阈值时，会从磁盘中读取EditLog和FsImage，通过EditLog新的记录更新内存中的FsImage，再讲新版本的FsImage刷新到磁盘中，然后截断EditLog中已经处理的记录，这个过程就是一个检查点。检查点的目的是确保文件系统通过在内存中使用元数据的快照从而持续的观察元数据的变更并将快照信息存储到磁盘FsImage中。检查点通过下面两个配置参数出发，时间周期（dfs.namenode.checkpoint.period）和文件系统事务数量（dfs.namenode.checkpoint.txns），二者同时配置时，满足任意一个条件就会触发检查点。

    所有的HDFS网络协议都是基于TCP/IP的，客户端建立一个到NameNode机器的可配置的TCP端口，用于二者之间的交互。DataNode使用DataNode协议和NameNode交互，RPC包装了客户端协议和DataNode协议，通过设计，NameNode不会发起RPC，只负责响应来自客户端或者DataNode的RPC请求。

    HDFS的核心目标是即使在失败或者错误情况下依然能够保证数据可靠性，三种常见失败情况包括NameNode故障、DataNode故障和network partitions。

    网络分区可能会导致部分DataNode市区和NameNode的连接，NameNode通过心跳包判断并将失去连接的DataNode标记为挂掉状态，于是所有注册到挂掉DataNode的数据都不可用了，可能会导致部分数据块的复制数量低于了原本配置的复制系数。NameNode不断地追踪哪些需要复制的块并在必要时候进行复制，触发条件包含多种情况：DataNode不可用、复制乱码、硬件磁盘故障或者认为增大负值系数。为了避免DataNode的状态不稳定导致的复制风暴，标记DataNode挂掉的超时时间设置比较长（默认10min），用户可以设置更短的时间间隔来标记DataNode为陈旧状态从而避免在对读写性能要求高的请求上使用这些陈旧节点。

    HDFS架构兼容数据各种重新平衡方案，一种方案可以在某个DataNode的空闲空间小于某个阈值时将数据移动到另一个DataNode上；在某个特殊文件突然有高的读取需求时，一种方式是积极创建额外副本并且平衡集群中的其他数据。这些类型的平衡方案暂时还未实现（不太清楚现有方案是什么...）。

    存储设备、网络或者软件的问题都可能导致从DataNode获取的数据发生乱码，HDFS客户端实现了对文件内容的校验，客户端在创建文件时，会计算文件中每个块的校验值并存储到命名空间，当客户端取回数据后会使用校验值对每个块进行校验，如果存在问题，客户端就会去另一个DataNode获取这个块的副本。

    FsImage和EditLog是HDFS的核心数据结构，他们的错误会导致整个HDFS挂掉，因此，NameNode应该支持时刻维持FsImage和EditLog的多分复制文件，它们的任何改变所有文件应该同步更新。另一个选择是使用 shared storage on NFS 或者 distributed edit log 支持多个NameNode，官方推荐 distributed edit log 。

    快照能够存储某一特殊时刻的数据副本，从而支持HDFS在发生错误时会滚到上一个稳定版本。

    HDFS的应用场景是大的数据集下，且数据只需要写一次但是要读取一到多次并且支持流速读取数据。一般情况下一个块大小为128MB，因此一个文件被切割成128MB的大块，且每个快可能分布在不同的DataNode。

    当客户端在复制系数是3的条件下写数据时，NameNode通过目标选择算法收到副本要写入的DataNode的集合，第1个DataNode开始一部分一部分的获取数据，把每个部分存储到本地并转发给第2个DataNode，第2个DataNode同样的把每个部分存储到本地并转发给第3个DataNode，第3个DataNode将数据存储到本地，这就是管道复制。

    HDFS提供了多种访问方式，比如 FileSystem Java API 、 C language wrapper for this Java API 和 REST API ，而且还支持浏览器直接浏览。通过使用 NFS gateway ，客户端可以在本地文件系统上安装HDFS。

    HDFS使用目录和文件的方式管理数据，并提供了叫做 FS shell 的命令行接口，下面有一些简单的命令：

    DFSAdmin命令集合用于管理HDFS集群，这些命令只有集群管理员可以使用，下面有一些简单的命令：

正常的HDFS安装都会配置一个web服务，通过可配的TCP端口对外暴露命名空间，从而使得用户可以通过web浏览器查看文件内容。

如果垃圾回收配置打开，通过FS shell移除的文件不会立刻删除，而是会移动到一个垃圾文件专用的目录（/user/<username>/.Trash），类似回收站，只要文件还存在于那个目录下，则随时可以被回复。绝大多数最近删除的文件都被移动到了垃圾目录（/user/<username>/.Trash/Current），并且HDFS每个一段时间在这个目录下创建一个检查点用于删除已经过期的旧的检查点，详情见 expunge command of FS shell 。在垃圾目录中的文件过期后，NameNode会删除这个文件，文件删除会引起这个文件的所有块的空间空闲，需要注意的是在文件被删除之后和HDFS的可用空间变多之间会有一些时间延迟（个人认为是垃圾回收机制占用的时间）。下面是一些简单的理解删除文件的例子：

    当文件复制系数减小时，NameNode会选择多余的需要删除的副本，在收到心跳包时将删除信息发送给DataNode。和上面一样，这个删除操作也是需要一些时间后，才能在集群上展现空闲空间的增加。

HDFS Architecture

❷ Hadoop分布式存储

为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离它最近的副本。如果在读取程序的同一个机架上有一个副本，那么就读取该副本。如果一个HDFS集群跨越多个数据中心，那么客户端也将首先读本地数据中心的副本

Namenode启动后会进入一个称为安全模式的特殊状态。处于安全模式的Namenode是不会进行数据块的复制的。Namenode从所有的 Datanode接收心跳信号和块状态报告。块状态报告包括了某个Datanode所有的数据块列表。每个数据块都有一个指定的最小副本数。当Namenode检测确认某个数据块的副本数目达到这个最小值，那么该数据块就会被认为是副本安全(safely replicated)的；在一定百分比（这个参数可配置）的数据块被Namenode检测确认是安全之后（加上一个额外的30秒等待时间），Namenode将退出安全模式状态。接下来它会确定还有哪些数据块的副本没有达到指定数目，并将这些数据块复制到其他Datanode上

所有的HDFS通讯协议都是建立在TCP/IP协议之上。客户端通过一个可配置的TCP端口连接到Namenode，通过ClientProtocol协议与Namenode交互。而Datanode使用DatanodeProtocol协议与Namenode交互。一个远程过程调用(RPC)模型被抽象出来封装ClientProtocol和Datanodeprotocol协议。在设计上，Namenode不会主动发起RPC，而是响应来自客户端或 Datanode 的RPC请求

❸ hadoop文件格式和压缩

Hadoop中的文件格式大致上分为面向行和面向列两类：

面向行：TextFile、SequenceFile、MapFile、Avro Datafile

二进制格式文件大小比文本文件大。

生产环境常用，作为原始表的存储格式，会占用更多磁盘资源，对它的 解析开销一般会比二进制格式高 几十倍以上。

Hadoop API 提供的一种二进制文件，它将数据以<key,value>的形式序列化到文件中。这种二进制文件内部使用Hadoop 的标准的Writable 接口实现序列化和反序列化。它与Hadoop API中的MapFile 是互相兼容的。

MapFile即为排序后的SequeneceFile，它会额外生成一个索引文件提供按键的查找。文件不支持复写操作，不能向已存在的SequenceFile(MapFile)追加存储记录，在执行文件写操作的时候，该文件是不可读取的。

Avro是一种用于支持数据密集型的二进制文件格式。它的文件格式更为紧凑，若要读取大量数据时，Avro能够提供更好的序列化和反序列化性能。并且Avro数据文件天生是带Schema定义的，所以它不需要开发者在API 级别实现自己的Writable对象。最近多个Hadoop 子项目都支持Avro 数据格式，如Pig 、Hive、Flume、Sqoop和Hcatalog。

面向列：Parquet 、RCFile、ORCFile

RCFile是Hive推出的一种专门面向列的数据格式。 它遵循“先按列划分，再垂直划分”的设计理念。当查询过程中，针对它并不关心的列时，它会在IO上跳过这些列。

ORCFile （Optimized Record Columnar File)提供了一种比RCFile更加高效的文件格式。其内部将数据划分为默认大小为250M的Stripe。每个Stripe包括索引、数据和Footer。索引存储每一列的最大最小值，以及列中每一行的位置。

Parquet 是一种支持嵌套结构的列式存储格式。Parquet 的存储模型主要由行组（Row Group）、列块（Column Chuck）、页（Page）组成。

1、行组，Row Group：Parquet 在水平方向上将数据划分为行组，默认行组大小与 HDFS Block 块大小对齐，Parquet 保证一个行组会被一个 Mapper 处理。

2、列块，Column Chunk：行组中每一列保存在一个列块中，一个列块具有相同的数据类型，不同的列块可以使用不同的压缩。

3、页，Page：Parquet 是页存储方式，每一个列块包含多个页，一个页是最小的编码的单位，同一列块的不同页可以使用不同的编码方式。

一般原始表数据使用文本格式存储，其他的都是列式存储。

目前在Hadoop中常用的几种压缩格式：lzo，gzip，snappy，bzip2,主要特性对比如下：

其性能对比如下：

2.1 lzo

hadoop中最流行的压缩格式，压缩/解压速度也比较快，合理的压缩率，支持split。适用于较大文本的处理。

对于lzo压缩，常用的有LzoCodec和lzopCodec，可以对sequenceFile和TextFile进行压缩。对TextFile压缩后，mapred对压缩后的文件默认是不能够进行split操作，需要对该lzo压缩文件进行index操作，生成lzo.index文件，map操作才可以进行split。如果设置LzoCodec，那么就生成.lzo后缀的文件，可以用LzoIndexer 进行支持split的index计算，如果设置LzopCodec，那么生成.lzo_deflate后缀的文件，不支持建立index。

❹ HDFS的数据存储之block

HDFS被设计成支持非常大的文件，与HDFS兼容的应用是那些处理大数据集的应用。这些应用程序处理非常大的文件在具有只被创建和写入一次，被读取一次或多次的特性，即HDFS中存储的大文件是一次写入多次读取不支持修改的，同时要求HDFS满足应用程序以流读取速度的要求。

正是因为大数据系统对所需的文件系统有这些要求，就决定了HDFS在存储模型上具有以下特点:

❺ HDFS由什么组成

大数据平台包含了采集层、存储层、计算层和应用层，是一个复杂的IT系统，需要学会Hadoop等分布式系统的开发技能。
1.1采集层：Sqoop可用来采集导入传统关系型数据库的数据、Flume对于日志型数据采集，另外使用Python一类的语言开发网络爬虫获取网络数据；
1.2储存层：分布式文件系统HDFS最为常用；采用了主从（Master/Slave）结构模型，一个HDFS集群是由一个NameNode和若干个DataNode组成的。其中NameNode作为主服务器，管理文件系统的命名空间和客户端对文件的访问操作；集群中的DataNode管理存储的数据。
1.3计算层：有不同的计算框架可以选择，常见的如MapRece、Spark等，一般来讲，如果能使用计算框架的“原生语言”，运算效率会最高（MapRece的原生支持Java，而Spark原生支持Scala）；
1.4应用层：包括结果数据的可视化、交互界面开发以及应用管理工具的开发等，更多的用到Java、Python等通用IT开发前端、后端的能力；

❻ Hadoop生态系统-新手快速入门（含HDFS、HBase系统架构）

Hadoop是一个由Apache基金会所开发的分布式系统基础架构。

用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。

Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。

Hadoop的框架最核心的设计就是：HDFS和MapRece。HDFS为海量的数据提供了存储，而MapRece则为海量的数据提供了计算。

广义的Hadoop，一般称为Hadoop生态系统，如下所示。

Hadoop生态系统中这些软件的作用：

HDFS 采用了主从（Master/Slave）结构模型，一个HDFS集群包括一个名称节点（NameNode）和若干个数据节点（DataNode）。

HDFS采用Java语言开发，因此任何支持JVM的机器都可以部署名称节点和数据节点。

在配置好Hadoop 集群之后，可以通过浏览器访问 http://[NameNodeIP]:9870，查询HDFS文件系统。通过该Web界面，可以查看当前文件系统中各个节点的分布信息。

HBase系统架构如下所示，包括客户端、Zookeeper服务器、Master主服务器、Region服务器。一般而言，HBase会采用HDFS作为底层数据存储。

在HBase服务器集群中，包含了一个Master和多个Region服务器，Master是HBase集群的“总管”，它必须知道Region服务器的状态。

HBase中可以启动多个Master，但是Zookeeper 可以帮助选举出一个Master 作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，这样可以避免Master单点失效的问题。

Region服务器是HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求。

Store是Region服务器的核心。每个Store对应了表中的一个列族的存储。每一个Store包含了一个MemStore缓存和若干个StoreFile文件。

HBase采用HLog来保证系统发生故障时，能够恢复到正确的状态。HLog是磁盘上面的记录文件，它记录着所有的更新操作。

HBase系统为每个Region服务器配置了一个HLog文件，它是一种预写式日志（Write Ahead Log），也就是说，用户更新数据必须首先被记入日志后，才能写入MemStore缓存。

此外，Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单。 Sqoop则为HBase提供了方便的RDBMS数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。

注意：Hadoop 安装完成之后，只包含HDFS和MapRece，并不含HBase，因此需要在Hadoop 之上继续安装HBase。

❼ hadoop项目孵化时主要包括哪两个项目

Hadoop的两个核心组成：
HDFS:分布式文件系统，存储海量的数据。
MapRece:并行处理框架，实现任务分解和调度。
Hadoop由以下几个项目构成
1、HadoopCommon：Hadoop体系最底层的一个模块，为Hadoop各子项目提供各种工具，如：配置文件和日志操作等。
2、HDFS：分布式文件系统，提供高吞吐量的应用程序数据访问，对外部客户机而言，HDFS就像一个传统的分级文件系统。可以创建、删除、移动或重命名文件，等等。但是HDFS的架构是基于一组特定的节点构建的，这是由它自身的特点决定的。这些节点包括NameNode（仅一个），它在HDFS内部提供元数据服务；DataNode，它为HDFS提供存储块。
由于仅存在一个NameNode，因此这是HDFS的一个缺点（单点失败）。存储在HDFS中的文件被分成块，然后将这些块复制到多个计算机中（DataNode）。这与传统的RAID架构大不相同。块的大小（通常为64MB）和复制的块数量在创建文件时由客户机决定。NameNode可以控制所有文件操作。HDFS内部的所有通信都基于标准的TCP/IP协议。
3、MapRece：一个分布式海量数据处理的软件框架集计算集群。
4、Avro：dougcutting主持的RPC项目，主要负责数据的序列化。有点类似Google的protobuf和Facebook的thrift。avro用来做以后hadoop的RPC，使hadoop的RPC模块通信速度更快、数据结构更紧凑。
5、Hive：类似CloudBase，也是基于hadoop分布式计算平台上的提供datawarehouse的sql功能的一套软件。使得存储在hadoop里面的海量数据的汇总，即席查询简单化。hive提供了一套QL的查询语言，以sql为基础，使用起来很方便。
6、HBase：基于HadoopDistributedFileSystem，是一个开源的，基于列存储模型的可扩展的分布式数据库，支持大型表的存储结构化数据。
7、Pig：是一个并行计算的高级的数据流语言和执行框架，SQL-like语言，是在MapRece上构建的一种高级查询语言，把一些运算编译进MapRece模型的Map和Rece中，并且用户可以定义自己的功能。
8、ZooKeeper：Google的Chubby一个开源的实现。它是一个针对大型分布式系统的可靠协调系统，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
9、Chukwa：一个管理大型分布式系统的数据采集系统由yahoo贡献。
10、Cassandra：无单点故障的可扩展的多主数据库。
11、Mahout：一个可扩展的机器学习和数据挖掘库。

❽ 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底层函数库专门用于提升校纠删码算法的编解码性能。通常情况下，纠删码用于冷数据的冗余，也就是不经常访问，但又必须联机存储以备查询的数据。除了磁盘利用率，多副本方式用空间换效率的方式肯定是最好，没什么问题。

❾ 关于hbase存储模型的描述正确的是

关于hbase存储模型的描述正确的有四个。
1、应用在FusionInsightHD的上层备裂应用。
2、HFS封装了Hbase与HDFS的接口。
3、为上层应用仿枣闭提供文件存储、岩弯读取、删除等功能。
4、HFS是：Hbase的独立模块。