一、HDFS简介

  在现代的企业环境中，单机容量往往无法存储大量数据，需要跨机器存储。统一管理分布在集群上的文件系统称为分布式文件系统。而一旦在系统中，引入网络，就不可避免地引入了所有网络编程的复杂性，例如挑战之一是如果保证在节点不可用的时候数据不丢失。
  传统的网络文件系统（NFS）虽然也称为分布式文件系统，但是其存在一些限制。由于NFS中，文件是存储在单机上，因此无法提供可靠性保证，当很多客户端同时访问NFS Server时，很容易造成服务器压力，造成性能瓶颈。另外如果要对NFS中的文件进行操作，需要首先同步到本地，这些修改在同步到服务端之前，其他客户端是不可见的。某种程度上，NFS不是一种典型的分布式系统，虽然它的文件的确放在远端（单一）的服务器上面。

NFS存储

NFS存储

从NFS的协议栈可以看到，它事实上是一种VFS（操作系统对文件的一种抽象）实现。

  HDFS，是Hadoop Distributed File System的简称，是Hadoop抽象文件系统的一种实现。Hadoop抽象文件系统可以与本地系统、Amazon S3等集成，甚至可以通过Web协议（webhsfs）来操作。HDFS的文件分布在集群机器上，同时提供副本进行容错及可靠性保证。例如客户端写入读取文件的直接操作都是分布在集群各个机器上的，没有单点性能压力。

二、HDFS设计原则

HDFS设计之初就非常明确其应用场景，适用与什么类型的应用，不适用什么应用，有一个相对明确的指导原则。

1. 设计目标

存储非常大的文件：这里非常大指的是几百M、G、或者TB级别。实际应用中已有很多集群存储的数据达到PB级别。根据Hadoop官网，Yahoo！的Hadoop集群约有10万颗CPU，运行在4万个机器节点上。更多世界上的Hadoop集群使用情况，参考Hadoop官网.
采用流式的数据访问方式: HDFS基于这样的一个假设：最有效的数据处理模式是一次写入、多次读取数据集经常从数据源生成或者拷贝一次，然后在其上做很多分析工作 分析工作经常读取其中的大部分数据，即使不是全部。 因此读取整个数据集所需时间比读取第一条记录的延时更重要。
运行于商业硬件上: Hadoop不需要特别贵的、reliable的（可靠的）机器，可运行于普通商用机器（可以从多家供应商采购） ，商用机器不代表低端机器。在集群中（尤其是大的集群），节点失败率是比较高的HDFS的目标是确保集群在节点失败的时候不会让用户感觉到明显的中断。

2. HDFS不适合的应用类型

有些场景不适合使用HDFS来存储数据。下面列举几个：
1） 低延时的数据访问
对延时要求在毫秒级别的应用，不适合采用HDFS。HDFS是为高吞吐数据传输设计的,因此可能牺牲延时HBase更适合低延时的数据访问。
2）大量小文件
文件的元数据（如目录结构，文件block的节点列表，block-node mapping）保存在NameNode的内存中， 整个文件系统的文件数量会受限于NameNode的内存大小。
经验而言，一个文件/目录/文件块一般占有150字节的元数据内存空间。如果有100万个文件，每个文件占用1个文件块，则需要大约300M的内存。因此十亿级别的文件数量在现有商用机器上难以支持。
3）多方读写，需要任意的文件修改
HDFS采用追加（append-only）的方式写入数据。不支持文件任意offset的修改。不支持多个写入器（writer）。

三、HDFS核心概念

1. Blocks

  物理磁盘中有块的概念，磁盘的物理Block是磁盘操作最小的单元，读写操作均以Block为最小单元，一般为512 Byte。文件系统在物理Block之上抽象了另一层概念，文件系统Block物理磁盘Block的整数倍。通常为几KB。Hadoop提供的df、fsck这类运维工具都是在文件系统的Block级别上进行操作。
  HDFS的Block块比一般单机文件系统大得多，默认为128M。HDFS的文件被拆分成block-sized的chunk，chunk作为独立单元存储。比Block小的文件不会占用整个Block，只会占据实际大小。例如， 如果一个文件大小为1M，则在HDFS中只会占用1M的空间，而不是128M。

HDFS的Block为什么这么大？
  是为了最小化查找（seek）时间，控制定位文件与传输文件所用的时间比例。假设定位到Block所需的时间为10ms，磁盘传输速度为100M/s。如果要将定位到Block所用时间占传输时间的比例控制1%，则Block大小需要约100M。 但是如果Block设置过大，在MapReduce任务中，Map或者Reduce任务的个数 如果小于集群机器数量，会使得作业运行效率很低。

Block抽象的好处
  block的拆分使得单个文件大小可以大于整个磁盘的容量，构成文件的Block可以分布在整个集群， 理论上，单个文件可以占据集群中所有机器的磁盘。
  Block的抽象也简化了存储系统，对于Block，无需关注其权限，所有者等内容（这些内容都在文件级别上进行控制）。
  Block作为容错和高可用机制中的副本单元，即以Block为单位进行复制。

四、Namenode与Datanode

  整个HDFS集群由Namenode和Datanode构成master-worker（主从）模式。Namenode负责构建命名空间，管理文件的元数据等，而Datanode负责实际存储数据，负责读写工作。

1. Namenode

Namenode存放文件系统树及所有文件、目录的元数据。元数据持久化为2种形式：

namespcae image
edit log

  但是持久化数据中不包括Block所在的节点列表，及文件的Block分布在集群中的哪些节点上，这些信息是在系统重启的时候重新构建（通过Datanode汇报的Block信息）。
  在HDFS中，Namenode可能成为集群的单点故障，Namenode不可用时，整个文件系统是不可用的。HDFS针对单点故障提供了2种解决机制：
1）备份持久化元数据
将文件系统的元数据同时写到多个文件系统， 例如同时将元数据写到本地文件系统及NFS。这些备份操作都是同步的、原子的。
2）Secondary Namenode
  Secondary节点定期合并主Namenode的namespace image和edit log， 避免edit log过大，通过创建检查点checkpoint来合并。它会维护一个合并后的namespace image副本， 可用于在Namenode完全崩溃时恢复数据。
  Secondary Namenode通常运行在另一台机器，因为合并操作需要耗费大量的CPU和内存。其数据落后于Namenode，因此当Namenode完全崩溃时，会出现数据丢失。 通常做法是拷贝NFS中的备份元数据到Second，将其作为新的主Namenode。
  在HA（High Availability高可用性）中可以运行一个Hot Standby，作为热备份，在Active Namenode故障之后，替代原有Namenode成为Active Namenode。

2.Datanode

  数据节点负责存储和提取Block，读写请求可能来自namenode，也可能直接来自客户端。数据节点周期性向Namenode汇报自己节点上所存储的Block相关信息。

五、Block Caching

  DataNode通常直接从磁盘读取数据，但是频繁使用的Block可以在内存中缓存。默认情况下，一个Block只有一个数据节点会缓存。但是可以针对每个文件可以个性化配置。
  作业调度器可以利用缓存提升性能，例如MapReduce可以把任务运行在有Block缓存的节点上。
  用户或者应用可以向NameNode发送缓存指令（缓存哪个文件，缓存多久）， 缓存池的概念用于管理一组缓存的权限和资源。

六、HDFS基本原理

1. HDFS运行原理：

1、NameNode和DataNode节点初始化完成后，采用RPC进行信息交换，采用的机制是心跳机制，即DataNode节点定时向NameNode反馈状态信息，反馈信息如:是否正常、磁盘空间大小、资源消耗情况等信息，以确保NameNode知道DataNode的情况；

2、NameNode会将子节点的相关元数据信息缓存在内存中，对于文件与Block块的信息会通过fsImage和edits文件方式持久化在磁盘上，以确保NameNode知道文件各个块的相关信息；

3、NameNode负责存储fsImage和edits元数据信息，但fsImage和edits元数据文件需要定期进行合并，这时则由SecondNameNode进程对fsImage和edits文件进行定期合并，合并好的文件再交给NameNode存储。

HDFS运行原理

2. HDFS数据合并原理

1、NameNode初始化时会产生一个edits文件和一个fsimage文件，edits文件用于记录操作日志，比如文件的删除或添加等操作信息，fsImage用于存储文件与目录对应的信息以及edits合并进来的信息，即相当于fsimage文件在这里是一个总的元数据文件，记录着所有的信息；

2、随着edits文件不断增大，当达到设定的一个阀值的时候，这时SecondaryNameNode会将edits文件和fsImage文件通过采用http的方式进行复制到SecondaryNameNode下，同时NameNode会产生一个新的edits文件替换掉旧的edits文件，这样以保证数据不会出现冗余；

3、SecondaryNameNode拿到这两个文件后，会在内存中进行合并成一个fsImage.ckpt的文件，合并完成后，再通过http的方式将合并后的文件fsImage.ckpt复制到NameNode下，NameNode文件拿到fsImage.ckpt文件后，会将旧的fsimage文件替换掉，并且改名成fsimage文件。

HDFS数据合并原理

3. HDFS写原理

1、HDFS客户端提交写操作到NameNode上，NameNode收到客户端提交的请求后，会先判断此客户端在此目录下是否有写权限，如果有，然后进行查看，看哪几个DataNode适合存放，再给客户端返回存放数据块的节点信息，即告诉客户端可以把文件存放到相关的DataNode节点下；

2、客户端拿到数据存放节点位置信息后，会和对应的DataNode节点进行直接交互，进行数据写入，由于数据块具有副本replication，在数据写入时采用的方式是先写第一个副本，写完后再从第一个副本的节点将数据拷贝到其它节点，依次类推，直到所有副本都写完了，才算数据成功写入到HDFS上，副本写入采用的是串行，每个副本写的过程中都会逐级向上反馈写进度，以保证实时知道副本的写入情况；

3、随着所有副本写完后，客户端会收到数据节点反馈回来的一个成功状态，成功结束后，关闭与数据节点交互的通道，并反馈状态给NameNode,告诉NameNode文件已成功写入到对应的DataNode。

HDFS写原理

4. HDFS读原理

1、HDFS客户端提交读操作到NameNode上，NameNode收到客户端提交的请求后，会先判断此客户端在此目录下是否有读权限，如果有，则给客户端返回存放数据块的节点信息，即告诉客户端可以到相关的DataNode节点下去读取数据块；

2、客户端拿到块位置信息后，会去和相关的DataNode直接构建读取通道，读取数据块，当所有数据块都读取完成后关闭通道，并给NameNode返回状态信息，告诉NameNode已经读取完毕。

HDFS读原理

七、HDFS文件存储格式

1. HDFS文件存储格式分为两大类

行存储和列存储:
行存储,将一整行存储在一起,是一种连续的存储方式,例如SequenceFile,MapFile,缺点是如果只需要行中的某一列也必须把整行都读入内存当中。
列存储列存储会把文件切割成若干列,每一列存储在一起,是需要那一列读取那一列,不需要的不用读取,例如parquet ORCfile,RCfile,列存储不适合流式写入,写入失败当前文件无法恢复因此flume采用行存储,列存储由于每一列中的数据类型相同所以可以根据数据类型选择适合的编码和压缩格式。

SequenceFile:Hadoop提供的一个行存储结构,Hadoop适合处理大文件而不适合处理小文件,所以sequencefile是为小文件提供的一种容器,将小文件包装起来形成一个SequenceFile类, 它用一种<key,value>的形式序列化数据导文件中。
MapFile:MapFile可以看做有序的SequenceFile,是排过序的SequenceFile,它有索引可以按照索引查找,索引作为一个单独的文件存储,一般128个记录存储一个索引,索引可以载入内存,方便快速查找。

HDFS最开始只有行存储的这两种形式 SequenceFile和macFile,除此之外还有text文本,但是之后再hive中丰富了存储结构包括如下几种：
RCFile:hive的RCfile 是将数据按照行分组 ,组内在按照列划分储存。
ORCfile:是RCfile的升级版,将数据划分为默认大小为250MB的stripe(条带),每个stripe包含索引,数据和footer,ORCfile包换索引比RCfile更加高效。
Parquet:parquet基于Google的dremel,擅长处理深度嵌套的数据(有点类似于嵌套多层的json格式),parquet会将嵌套结构整合为平面列存储。

2. SequenceFile

SequenceFile文件是Hadoop用来存储二进制形式的<key,value>对而设计的一种平面文件(Flat File)。
可以把SequenceFile当做一个容器，把所有文件打包到SequenceFile类中可以高效的对小文件进行存储和处理。
SequenceFile文件并不按照其存储的key进行排序存储，SequenceFile的内部类Writer提供了append功能。
SequenceFile中的key和value可以是任意类型Writable或者是自定义Writable类型。

3. SequenceFile压缩

SequenceFile的内部格式取决于是否启用压缩，如果是，要么是记录压缩，要么是块压缩。
三种类型：
A．无压缩类型：如果没有启用压缩（默认设置），那么每个记录就由它的记录长度（字节数）、键的长度，键和值组成。长度字段为四字节。
B．记录压缩类型：记录压缩格式与无压缩格式基本相同，不同的是值字节是用定义在头部的编码器来压缩。注意，键是不压缩的。
C．块压缩类型：块压缩一次压缩多个记录，因此它比记录压缩更紧凑，而且一般优先选择。当记录的字节数达到最小大小，才会添加到块。该最小值由io.seqfile.compress.blocksize中的属性定义。默认值是1000000字节。格式为记录数、键长度、键、值长度、值。
无压缩格式与记录压缩格式

无压缩格式与记录压缩格式

块压缩格式:

块压缩格式

HDFS端口：

MR端口

其它端口
参数