hdfs架构
namenode
储存文件的元数据，如文件名，文件目录结构，文件属性（生成时间、副本数、文件权限）， 以及每一个文件的块列表和块所在的datanode
①fsimage:元数据镜像文件。存储某一时段NameNode内存元数据信息。
②edits:操作日志文件。
③fstime:保存最近一次checkpoint的时间
datanode
在文件系统储存文件块数据，以及数据的校验和
secondary namenode
用来监控hdfs的状态的辅助后台程序，每隔一段时间获取hdfs元数据的快照
元信息的持久化
在NameNode中存放元信息的文件是 fsimage。在系统运行期间所有对元信息的操作都保存在内存中并被持久化到另一个文件edits中。并且edits文件和fsimage文件会被SecondaryNameNode周期性的合并（合并过程会在SecondaryNameNode中详细介绍）。
NameNode特点
运行NameNode会占用大量内存和I/O资源，一般NameNode不会存储用户数据或执行MapReduce任务。
为了简化系统的设计，Hadoop只有一个NameNode，这也就导致了hadoop集群的单点故障问题。因此，
对NameNode节点的容错尤其重要，hadoop提供了如下两种机制来解决：
将hadoop元数据写入到本地文件系统的同时再实时同步到一个远程挂载的网络文件系统（NFS）。
运行一个secondary NameNode，它的作用是与NameNode进行交互，定期通过编辑日志文件合并命名
空间镜像，当NameNode发生故障时它会通过自己合并的命名空间镜像副本来恢复。需要注意的是
secondaryNameNode保存的状态总是滞后于NameNode，所以这种方式难免会导致丢失部分数据（后面会详细介绍）。
SecondaryNameNode
需要注意，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读操作
1.首先调用FileSystem对象的open方法，其实是一个DistributedFileSystem的实例。
2.DistributedFileSystem通过rpc获得文件的第一批block的locations，同一个block按照重复数会返回多个locations，这些locations按照hadoop拓扑结构排序，距离客户端近的排在前面。
3.前两步会返回一个FSDataInputStream对象，该对象会被封装DFSInputStream对象，DFSInputStream可 以方便的管理datanode和namenode数据流。客户端调用read方法，DFSInputStream最会找出离客户端最近的datanode 并连接。
4.数据从datanode源源不断的流向客户端。
5.如果第一块的数据读完了，就会关闭指向第一块的datanode连接，接着读取下一块。这些操作对客户端来说是透明的，客户端的角度看来只是读一个持续不断的流。
6.如果第一批block都读完了， DFSInputStream就会去namenode拿下一批block的locations，然后继续读，如果所有的块都读完，这时就会关闭掉所有的流。
如果在读数据的时候， DFSInputStream和datanode的通讯发生异常，就会尝试正在读的block的排序第二近的datanode,并且会记录哪个 datanode发生错误，剩余的blocks读的时候就会直接跳过该datanode。 DFSInputStream也会检查block数据校验和，如果发现一个坏的block,就会先报告到namenode节点，然后 DFSInputStream在其他的datanode上读该block的镜像。
该设计就是客户端直接连接datanode来检索数据并且namenode来负责为每一个block提供最优的datanode， namenode仅仅处理block location的请求，这些信息都加载在namenode的内存中，hdfs通过datanode集群可以承受大量客户端的并发访问。
hdfs写操作
1.客户端通过调用DistributedFileSystem的create方法创建新文件。
2.DistributedFileSystem通过RPC调用namenode去创建一个没有blocks关联的新文件，创建前， namenode会做各种校验，比如文件是否存在，客户端有无权限去创建等。如果校验通过， namenode就会记录下新文件，否则就会抛出IO异常。
3.前两步结束后，会返回FSDataOutputStream的对象，与读文件的时候相似， FSDataOutputStream被封装成DFSOutputStream。DFSOutputStream可以协调namenode和 datanode。客户端开始写数据到DFSOutputStream，DFSOutputStream会把数据切成一个个小的packet，然后排成队 列data quene。
4.DataStreamer会去处理接受data quene，它先询问namenode这个新的block最适合存储的在哪几个datanode里（比如重复数是3，那么就找到3个最适合的 datanode），把他们排成一个pipeline。DataStreamer把packet按队列输出到管道的第一个datanode中，第一个 datanode又把packet输出到第二个datanode中，以此类推。
5.DFSOutputStream还有一个对列叫ack quene，也是由packet组成，等待datanode的收到响应，当pipeline中的所有datanode都表示已经收到的时候，这时akc quene才会把对应的packet包移除掉。
如果在写的过程中某个datanode发生错误，会采取以下几步：
- pipeline被关闭掉；
2)为了防止防止丢包ack quene里的packet会同步到data quene里；
3)把产生错误的datanode上当前在写但未完成的block删掉；
4)block剩下的部分被写到剩下的两个正常的datanode中；
5)namenode找到另外的datanode去创建这个块的复制。当然，这些操作对客户端来说是无感知的。
6.客户端完成写数据后调用close方法关闭写入流。
7.DataStreamer把剩余得包都刷到pipeline里，然后等待ack信息，收到最后一个ack后，通知datanode把文件标视为已完成。
注意：客户端执行write操作后，写完的block才是可见的，正在写的block对客户端是不可见的，只有 调用sync方法，客户端才确保该文件的写操作已经全部完成，当客户端调用close方法时，会默认调用sync方法。是否需要手动调用取决你根据程序需 要在数据健壮性和吞吐率之间的权衡。
hdfs文件删除
hdfs文件删除过程一般需要如下几步：
- 一开始删除文件，NameNode只是重命名被删除的文件到/trash目录，因为重命名操作只是元信息的变动，所以整个过程非常快。在/trash中文件会被保留一定间隔的时间（可配置，默认是6小时），在这期间，文件可以很容易的恢复，恢复只需要将文件从/trash移出即可。
- 当指定的时间到达，NameNode将会把文件从命名空间中删除
- 标记删除的文件块释放空间，HDFS文件系统显示空间增加
hdfs文件恢复
和Linux系统的回收站设计一样，HDFS会为每一个用户创建一个回收站目录：/user/用户名/.Trash/，每一个被用户通过Shell删除的文件/目录，在系统回收站中都一个周期，也就是当系统回收站中的文件/目录在一段时间之后没有被用户回复的话，HDFS就会自动的把这个文件/目录彻底删除，之后，用户就永远也找不回这个文件/目录了。在HDFS内部的具体实现就是在NameNode中开启了一个后台线程Emptier，这个线程专门管理和监控系统回收站下面的所有文件/目录，对于已经超过生命周期的文件/目录，这个线程就会自动的删除它们，不过这个管理的粒度很大。另外，用户也可以手动清空回收站，清空回收站的操作和删除普通的文件目录是一样的，只不过HDFS会自动检测这个文件目录是不是回收站，如果是，HDFS当然不会再把它放入用户的回收站中了
根据上面的介绍，用户通过命令行即HDFS的shell命令删除某个文件，这个文件并没有立刻从HDFS中删除。相反，HDFS将这个文件重命名，并转移到操作用户的回收站目录中（如/user/hdfs/.Trash/Current, 其中hdfs是操作的用户名）。如果用户的回收站中已经存在了用户当前删除的文件/目录，则HDFS会将这个当前被删除的文件/目录重命名，命名规则很简单就是在这个被删除的文件/目录名后面紧跟一个编号(从1开始知道没有重名为止)。
当文件还在/user/hdfs/.Trash/Current目录时，该文件可以被迅速地恢复。文件在/user/hdfs/.Trash/Current中保存的时间是可配置的，当超过这个时间，Namenode就会将该文件从namespace中删除。 文件的删除，也将释放关联该文件的数据块。注意到，在文件被用户删除和HDFS空闲的增加之间会有一个等待时间延迟。
当被删除的文件还保留在/user/hdfs/.Trash/Current目录中的时候，如果用户想恢复这个文件，可以检索浏览/user/hdfs/.Trash/Current目录并检索该文件。/user/hdfs/.Trash/Current目录仅仅保存被删除 文件的最近一次拷贝。/user/dfs/.Trash/Current目录与其他文件目录没有什么不同，除了一点：HDFS在该目录上应用了一个特殊的策略来自动删除文件，目前的默认策略是 删除保留超过6小时的文件，这个策略以后会定义成可配置的接口。
还有，NameNode是通过后台线程(默认是org.apache.Hadoop.fs.TrashPolicyDefault.Emptier，也可以通过fs.trash.classname指定TrashPolicy类)来定时清空所有用户回收站中的文件/目录的,它每隔interval分钟就清空一次用户回收站。具体的操作步骤是，先检查用户回收站目录/user/用户名/.Trash下的所有yyMMddHHmm形式的目录，然后删除寿命超过interval的目录，最后将当前存放删除的文件/目录的回收站目录/user/用户名/.Trash/current重命名为一个/user/用户名/.Trash/yyMMddHHmm.
从这个回收线程(Emptier)的实现可以看出，被用户用命令删除的文件最多可在其回收站中保存2*interval分钟，最少可保存interval分钟，过了这个有效期，用户删除的文件就永远也不可能恢复了
配置
Hadoop回收站trash，默认是关闭的
1.修改conf/core-site.xml,增加
<property>
<name>fs.trash.interval</name>
<value>1440</value>
<description>Number of minutes between trash checkpoints.
If zero, the trash feature is disabled.
</description>
</property>
默认是0.单位分钟。这里我设置的是1天（60*24）
删除数据rm后，会将数据move到当前文件夹下的.Trash目录