HDFS入门
写在前面
在前面对HDFS相关内容进行了简要学习，接下来开始学习HDFS入门相关的内容，具体包括：（1）HDFS产生背景；（2）HDFS简介；（3）HDFS缺点；（4）HDFS设计目标；（5）HDFS一些概念；（6）HDFS架构。
认识HDFS
HDFS产生背景
前面也说了，由于现在每天产生的数据量很大，平常使用的操作系统无法满足数据量的存储和处理，如果将多个操作系统综合为一个大的操作系统，方法是可行，但是却不便于管理和维护，鉴于此就诞生了分布式文件管理系统（Distributed File System），简称DFS。
说白了分布式文件系统就是允许一个文件通过网络在多台主机上以多副本的方式进行存储（可提供容错性），实际上是通过网络来访问文件，这样使得用户看起来就像是在访问本地磁盘中的文件一样。
HDFS简介
Hadoop Distributed File System，简称HDFS，它是Hadoop项目的核心子项目，用于分布式计算中的数据存储。
Hadoop官方的描述是：HDFS可以运行在廉价的服务器上，为海量数据存储提供了高容错、高可靠、高扩展性、高获得性和高吞吐率等特征。Hadoop其实就是谷歌GFS的开源实现。
Hadoop整合了众多的底层文件系统，如本地文件系统、HDFS文件系统、S3文件系统，并提供了一个文件系统抽象类org.apache.hadoop.fs.FileSystem，其对应的具体实现类如下表所示：
可以看到Hadoop提供了很多系统的接口，用户可以使用URI方案选取合适的文件系统来实现交互。
HDFS优点
（1）处理超大文件。注意这里的超大文件是指MB到TB级别的数据文件，Hadoop的优势就是处理大文件，如果Hadoop中存在众多的小文件，那么反而会导致Hadoop集群性能下降。说白了，人家天生就是处理超大文件。
（2）可运行于廉价机器。这个是Hadoop被大家认可的重要原因，企业看重的是成本，且Hadoop自身的高可用、高可靠使得Hadoop可运行在廉价机器上。
（3）流式地访问数据。HDFS提供一次写入、多次读取的服务。举个例子，开发者一开始在HDFS上存储了一个要处理的问题，之后可能还会有多个作业都需要使用到这份数据，那么只需通过集群来读取之前已经存储好的数据即可。HDFS起初不支持对已有文件进行内容的追加，但是现在可以了。
HDFS缺点
俗话说的好，凡事有利自然也有弊，HDFS也不例外。
（1）不支持低延迟数据访问。所谓的低延迟是指对数据实时性要求很高，注意此时不能使用HDFS，因为HDFS是为解决存储大数据而设计的。对于那些实时性、低延迟的查询，推荐使用HBase，前面也说了HBase中rowkey的设计会决定开发者查询性能的好坏。
（2）无法高效存储大量小文件。要理解这个，就必须知道HDFS中的元数据。元数据信息包括两部分：一部分是“文件和目录自身的属性信息”，如文件名称、目录名、父目录信息、文件大小、创建时间、修改时间等；另一部分是“记录与文件内容存储相关的信息”，如文件块情况、副本个数、每个副本存放地址等。
HDFS中的元数据存放在NameNode中，因此HDFS所能容纳的文件数目由NameNode的内存大小来决定。一旦集群中的小文件过多，会导致NameNode的压力徒增，进而影响到集群的性能，因此可以使用SequenceFiled等方式对小文件进行合并，或者使用NameNodeFederation的方式来改善。
HDFS设计目标
由于HDFS设计目标较为繁多，这里只挑选几个比较重要的设计目标进行介绍：
（1）硬件错误。请注意硬件错误是常态而不是异常。HDFS可能由成百上千个服务器所构成，每个服务器上存储着文件系统的部分数据。因此肯定会出现一部分HDFS组件无法工作的情况，因此错误检测和快速自恢复也是HDFS在设计时需要考虑的核心问题。
（2）大规模数据集。运行在HDFS上的应用具有非常大的数据集，HDFS上一个典型文件的大小一般都在GB至TB级别，因此需要调节HDFS以支持大文件存储。这也就要求HDFS可以提供整体较高的数据传输带宽，能够在一个集群中扩展到数百个节点，即一个单一的HDFS实例应该能支撑数以千万计的文件。
（3）移动计算比移动数据代价低。我们知道，一个作业的计算，离它操作的数据越近，那么就越高效，这在数据量达到海量级别的时候，更是如此。因为这样能降低网络阻塞的影响，提高系统数据的吞吐量。将计算移动到数据附近，比将数据移动到应用附近是更合理的，因此HDFS应当为应用提供将计算移动到数据附近的接口。
HDFS一些概念
数据块(Block)
HDFS默认的最基本存储单位是数据块(Block)，默认的块大小(Block Size)是64MB，但是有些发行版可能存在128MB的情况。HDFS中文件被分成以Block Size为大小的数据块来存储，言外之意，如果一个文件大小小于一个数据块的大小，那么它并不会占用整个数据块存储空间，文件大小是多大就占用多大的存储空间。
HDFS与Block之间的关系如下图所示：
元数据节点(NameNode)
NameNode（简称NN）主要负责管理文件系统的命名空间，它将所有的文件和文件夹的元数据保存在一个文件系统树中，如一个文件包括哪些数据块，这些数据块分布在哪些数据节点上，这些信息都需要存储下来。
NameNode目录结构如下所示，
1 | ${dfs.namenode.name.dir}/current/VERSION |
其中（1）VERSION文件是存放版本信息的文件，它保存了HDFS的版本号；（2）edits，当文件系统客户端进行读写操作时，首先记录在修改日志中，元数据节点在内存中保存了文件系统的元数据信息。在记录了修改日志之后，元数据节点则修改内存中的数据结构。每次写操作成功之前，修改日志都会同步到文件系统；（3）fsimage文件就是名字空间文件。
数据节点(DataNode)
DataNode（简称DN）是文件系统中真正存储数据的地方，一个文件被拆分为多个Block之后，会将这些Block存储在对应的数据节点上。客户端向NameNode发起请求，然后到对应的数据节点上写入或者读出对应的数据Block。
DataNode目录结构如下所示，
1 | ${dfs.datanode.data.dir}/current/VERSION |
其中（1）blk_<id>保存的是HDFS的数据块，其实是具体的二进制数据；（2）blk_<id>.meta保存的是数据块的属性信息，如版本信息、类型信息和校验和等；（3）subdirxx则是当一个目录中的数据块达到一定数量的时候，则创建子文件夹来保存数据块及数据块属性信息。
从元数据节点(Secondary NameNode)
注意从元数据节点(Secondary NameNode，简称SNN)并是NameNode节点出现问题时的备用节点，它和元数据节点分别负责不同的功能。
从元数据节点(Secondary NameNode)的主要功能就是周期性的将NameNode元数据节点的namespace image和edit log进行合并，用来防止日志文件过大。合并之后的namespace image也在元数据节点保存了一份，以防在NameNode失效的时候进行恢复。
Secondary NameNode目录结构如下所示，
1 | ${dfs.secondarynamenode.name.dir}/current/VERSION |
Secondary NameNode用于帮助NameNode将内存中的元数据信息checkpoint到硬盘上。
HDFS架构
架构概述
HDFS采用主从（master/slave）架构。一个HDFS集群由一个NameNode和一定数量的DataNode组成。
NameNode是Master节点，也是一个中心服务器，负责管理文件系统的名称空间(namespace)以及客户端对文件的访问。
HDFS暴露了文件系统的名称空间，使得用户能以文件的形式在上面存储数据。从内部来看，一个文件其实被分成一个或多个数据块，这些块存储在一组DataNode上。NameNode执行文件系统的名字空间操作，如打开，关闭，重命名文件或目录，它也负责确定数据块到具体DataNode的映射。DataNode负责处理文件系统客户端的读写请求，在NameNode的统一调度下进行数据块的创建、删除和复制。
HDFS的架构如下所示：
架构组件功能
NameNode和DataNode被设计为可以运行在普通的安装GNU/Linux操作系统的机器上。由于HDFS采用了可移植性极强的Java语言，因此任何支持Java的机器都可以部署
NameNode或者DataNode。
一个典型的部署场景就是一台机器上只运行一个NameNode实例，而集群中的其他机器分别运行一个DataNode实例。当然也是可以在一个机器上运行多个DataNode实例，但是这种情况比较少见而已。
文件系统的名字空间，HDFS支持传统的层次型文件组织结构。用户或者应用程序可以创建目录，然后将文件保存在这些目录里。
文件系统名字空间的层次结构和大多数现有的文件系统类似，用户可以创建、删除、移动或者重命令文件。当前HDFS不支持用户磁盘配额和访问权限控制，也不支持硬链接和软连接，但是HDFS架构并不影响对于这些特性的实现。
NameNode负责维护文件系统的名字空间，任何对文件系统名字空间或者属性的修改都将被NameNode记录下来。应用程序可以设置HDFS保存的文件的副本数目，文件副本的数目被称为文件的副本系数，这个信息也是由NameNode来保存的。
那么本篇关于HDFS的入门学习就到此为止，后续学习其他内容。
