概述：hdfs即hadoop distributed file system分布式文件系统，它的设计目标是把超大数据集存储到分布在网络中的多台普通商用计算机上，并且能够提供高可靠性和高吞吐量的服务。分布式文件系统要比普通磁盘文件系统复杂，因为它要引入网络编程，分布式文件系统要容忍节点故障也是一个很大的挑战。
专为存储超大文件而设计：hdfs应该能够支持gb级别大小的文件；它应该能够提供很大的数据带宽并且能够在集群中拓展到成百上千个节点；它的一个实例应该能够支持千万数量级别的文件。
适用于流式的数据访问：hdfs适用于批处理的情况而不是交互式处理；它的重点是保证高吞吐量而不是低延迟的用户响应
容错性：完善的冗余备份机制
支持简单的一致性模型：hdfs需要支持一次写入多次读取的模型，而且写入过程文件不会经常变化
移动计算优于移动数据：hdfs提供了使应用计算移动到离它最近数据位置的接口
兼容各种硬件和软件平台
大量小文件：文件的元数据都存储在namenode内存中，大量小文件会占用大量内存。
低延迟数据访问：hdfs是专门针对高数据吞吐量而设计的
多用户写入，任意修改文件
hdfs主要由3个组件构成，分别是namenode、secondarynamenode和datanode，hsfs是以master/slave模式运行的，其中namenode、secondarynamenode 运行在master节点，datanode运行slave节点。
磁盘数据块是磁盘读写的基本单位，与普通文件系统类似，hdfs也会把文件分块来存储。hdfs默认数据块大小为64mb，磁盘块一般为512b，hdfs块为何如此之大呢？块增大可以减少寻址时间与文件传输时间的比例，若寻址时间为10ms，磁盘传输速率为100mb/s，那么寻址与传输比仅为1%。当然，磁盘块太大也不好，因为一个mapreduce通常以一个块作为输入，块过大会导致整体任务数量过小，降低作业处理速度。
数据块是存储在datanode中的，为了能够容错数据块是以多个副本的形式分布在集群中的，副本数量默认为3，后面会专门介绍数据块的复制机制。
hdfs按块存储还有如下好处：
文件可以任意大，也不用担心单个结点磁盘容量小于文件的情况
简化了文件子系统的设计，子系统只存储文件块数据，而文件元数据则交由其它系统（namenode）管理
有利于备份和提高系统可用性，因为可以以块为单位进行备份，hdfs默认备份数量为3。
有利于负载均衡
当一个客户端请求一个文件或者存储一个文件时，它需要先知道具体到哪个datanode上存取，获得这些信息后，客户端再直接和这个datanode进行交互，而这些信息的维护者就是namenode。
namenode管理着文件系统命名空间，它维护这文件系统树及树中的所有文件和目录。namenode也负责维护所有这些文件或目录的打开、关闭、移动、重命名等操作。对于实际文件数据的保存与操作，都是由datanode负责。当一个客户端请求数据时，它仅仅是从namenode中获取文件的元信息，而具体的数据传输不需要经过namenode，是由客户端直接与相应的datanode进行交互。
namenode保存元信息的种类有：
文件名目录名及它们之间的层级关系
文件目录的所有者及其权限
每个文件块的名及文件有哪些块组成
需要注意的是，namenode元信息并不包含每个块的位置信息，这些信息会在namenode启动时从各个datanode获取并保存在内存中，因为这些信息会在系统启动时由数据节点重建。把块位置信息放在内存中，在读取数据时会减少查询时间，增加读取效率。namenode也会实时通过心跳机制和datanode进行交互，实时检查文件系统是否运行正常。不过namenode元信息会保存各个块的名称及文件由哪些块组成。
一般来说，一条元信息记录会占用200byte内存空间。假设块大小为64mb，备份数量是3 ，那么一个1gb大小的文件将占用16*3=48个文件块。如果现在有1000个1mb大小的文件，则会占用1000*3=3000个文件块（多个文件不能放到一个块中）。我们可以发现，如果文件越小，存储同等大小文件所需要的元信息就越多，所以，hadoop更喜欢大文件。
在namenode中存放元信息的文件是 fsimage。在系统运行期间所有对元信息的操作都保存在内存中并被持久化到另一个文件edits中。并且edits文件和fsimage文件会被secondarynamenode周期性的合并（合并过程会在secondarynamenode中详细介绍）。
运行namenode会占用大量内存和i/o资源，一般namenode不会存储用户数据或执行mapreduce任务。
为了简化系统的设计，hadoop只有一个namenode，这也就导致了hadoop集群的单点故障问题。因此，对namenode节点的容错尤其重要，hadoop提供了如下两种机制来解决：
将hadoop元数据写入到本地文件系统的同时再实时同步到一个远程挂载的网络文件系统（nfs）。
运行一个secondary namenode，它的作用是与namenode进行交互，定期通过编辑日志文件合并命名空间镜像，当namenode发生故障时它会通过自己合并的命名空间镜像副本来恢复。需要注意的是secondarynamenode保存的状态总是滞后于namenode，所以这种方式难免会导致丢失部分数据（后面会详细介绍）。
datanode是hdfs中的worker节点，它负责存储数据块，也负责为系统客户端提供数据块的读写服务，同时还会根据namenode的指示来进行创建、删除、和复制等操作。此外，它还会通过心跳定期向namenode发送所存储文件块列表信息。当对hdfs文件系统进行读写时，namenode告知客户端每个数据驻留在哪个datanode，客户端直接与datanode进行通信，datanode还会与其它datanode通信，复制这些块以实现冗余。
namenode和datanode架构图
需要注意，secondarynamenode并不是namenode的备份。我们从前面的介绍已经知道，所有hdfs文件的元信息都保存在namenode的内存中。在namenode启动时，它首先会加载fsimage到内存中，在系统运行期间，所有对namenode的操作也都保存在了内存中，同时为了防止数据丢失，这些操作又会不断被持久化到本地edits文件中。
edits文件存在的目的是为了提高系统的操作效率，namenode在更新内存中的元信息之前都会先将操作写入edits文件。在namenode重启的过程中，edits会和fsimage合并到一起，但是合并的过程会影响到hadoop重启的速度，secondarynamenode就是为了解决这个问题而诞生的。
secondarynamenode的角色就是定期的合并edits和fsimage文件，我们来看一下合并的步骤：
合并之前告知namenode把所有的操作写到新的edites文件并将其命名为edits.new。
secondarynamenode从namenode请求fsimage和edits文件
secondarynamenode把fsimage和edits文件合并成新的fsimage文件
namenode从secondarynamenode获取合并好的新的fsimage并将旧的替换掉，并把edits用第一步创建的edits.new文件替换掉
更新fstime文件中的检查点
最后再总结一下整个过程中涉及到namenode中的相关文件
fsimage ：保存的是上个检查点的hdfs的元信息
edits ：保存的是从上个检查点开始发生的hdfs元信息状态改变信息
fstime：保存了最后一个检查点的时间戳
hdfs通过备份数据块的形式来实现容错，除了文件的最后一个数据块外，其它所有数据块大小都是一样的。数据块的大小和备份因子都是可以配置的。namenode负责各个数据块的备份，datanode会通过心跳的方式定期的向namenode发送自己节点上的block 报告，这个报告中包含了datanode节点上的所有数据块的列表。
文件副本的分布位置直接影响着hdfs的可靠性和性能。一个大型的hdfs文件系统一般都是需要跨很多机架的，不同机架之间的数据传输需要经过网关，并且，同一个机架中机器之间的带宽要大于不同机架机器之间的带宽。如果把所有的副本都放在不同的机架中，这样既可以防止机架失败导致数据块不可用，又可以在读数据时利用到多个机架的带宽，并且也可以很容易的实现负载均衡。但是，如果是写数据，各个数据块需要同步到不同的机架，会影响到写数据的效率。
而在hadoop中，如果副本数量是3的情况下，hadoop默认是这么存放的，把第一个副本放到机架的一个节点上，另一个副本放到同一个机架的另一个节点上，把最后一个节点放到不同的机架上。这种策略减少了跨机架副本的个数提高了写的性能，也能够允许一个机架失败的情况，算是一个很好的权衡。
关于副本的选择，在读的过程中，hdfs会选择最近的一个副本给请求者。
关于安全模式，当 hadoop的namenode节点启动时，会进入安全模式阶段。在此阶段，datanode会向namenode上传它们数据块的列表，让 namenode得到块的位置信息，并对每个文件对应的数据块副本进行统计。当最小副本条件满足时，即一定比例的数据块都达到最小副本数，系统就会退出安全模式，而这需要一定的延迟时间。当最小副本条件未达到要求时，就会对副本数不足的数据块安排datanode进行复制，直至达到最小副本数。而在安全模式下，系统会处于只读状态，namenode不会处理任何块的复制和删除命令。
所有的hdfs中的沟通协议都是基于tcp/ip协议，一个客户端通过指定的tcp端口与namenode机器建立连接，并通过clientprotocol协议与namenode交互。而datanode则通过datanode protocol协议与namenode进行沟通。hdfs的rcp(远程过程调用)对clientprotocol和datanode protocol做了封装。按照hdfs的设计，namenode不会主动发起任何请求，只会被动接受来自客户端或datanode的请求。
可以允许datanode失败。datanode会定期（默认3秒）的向namenode发送心跳，若namenode在指定时间间隔内没有收到心跳，它就认为此节点已经失败。此时，namenode把失败节点的数据（从另外的副本节点获取）备份到另外一个健康的节点。这保证了集群始终维持指定的副本数。
可以检测到数据块损坏。在读取数据块时，hdfs会对数据块和保存的校验和文件匹配，如果发现不匹配，namenode同样会重新备份损坏的数据块。
了解客户端与namenode和datanode的交互过程十分重要，有助于加深我们对hdfs架构设计的理解。
hdfs有一个filesystem实例，客户端通过调用这个实例的open()方法就可以打开系统中希望读取的文件。hdfs通过rpc调用namenode获取文件块的位置信息，对于文件的每一个块，namenode会返回含有该块副本的datanode的节点地址，另外，客户端还会根据网络拓扑来确定它与每一个datanode的位置信息，从离它最近的那个datanode获取数据块的副本，最理想的情况是数据块就存储在客户端所在的节点上。
hdfs会返回一个fsdatainputstream对象，fsdatainputstream类转而封装成dfsdatainputstream对象,这个对象管理着与datanode和namenode的i/o，具体过程是：
当fsdatainputstream与datanode通信时遇到错误，它会选取另一个较近的datanode，并为出故障的datanode做标记以免重复向其读取数据。fsdatainputstream还会对读取的数据块进行校验和确认，发现块损坏时也会重新读取并通知namenode。
这样设计的巧妙之处：
让客户端直接联系datanode检索数据，可以使hdfs扩展到大量的并发客户端，因为数据流就是分散在集群的每个节点上的，在运行mapreduce任务时，每个客户端就是一个datanode节点。
namenode仅需相应块的位置信息请求（位置信息在内存中，速度极快），否则随着客户端的增加，namenode会很快成为瓶颈。
在海量数据处理过程中，主要限制因素是节点之间的带宽。衡量两个节点之间的带宽往往很难实现，在这里hadoop采取了一个简单的方法，它把网络拓扑看成是一棵树，连个节点的距离=它们到最近共同祖先距离的总和，而树的层次可以这么划分：
同一节点中的进程
同一机架上的不同节点
同一数据中心不同机架
不同数据中心的节点
若数据中心d1中一个机架r1中一个节点n1表示为d1/r1/n1,则：
hdfs有一个distributedfilesystem实例，客户端通过调用这个实例的create()方法就可以创建文件。distributedfilesystem会发送给namenode一个rpc调用，在文件系统的命名空间创建一个新文件，在创建文件前namenode会做一些检查，如文件是否存在，客户端是否有创建权限等，若检查通过，namenode会为创建文件写一条记录到本地磁盘的editlog，若不通过会向客户端抛出ioexception。创建成功之后distributedfilesystem会返回一个fsdataoutputstream对象，客户端由此开始写入数据。
同读文件过程一样，fsdataoutputstream类转而封装成dfsdataoutputstream对象,这个对象管理着与datanode和namenode的i/o，具体过程是：
上面第四步描述的flush过程实际处理过程比较负杂，现在单独描述一下：
hdfs文件删除过程一般需要如下几步：