HDFS: 上传的数据经过切块分布式存储 并且每个块都有多个备份 保证性能和可靠性
优点：
支持超大文件
检测和快速应对硬件故障
流式数据访问
简化的一致性模型
高容错性
可构建在廉价机器上
缺点：
低延迟数据访问
大量的小文件
多用户写入文件、修改文件
不支持超强的事务
组成结构
NameNode
元数据的存储
SecondaryNameNode
帮助NameNode实现元数据的合并
DataNode
存储数据块(Block)
!!!!!!!技术细节
Block
最基本的存储单位。
128MB(64MB)
3个副本
如果某个块不足128MB 切出的块该是多大就是多大 128MB是块的最大大小
NameNode
存储的是元数据
元数据存储在NameNode的内存和磁盘(FsImage、Edits、FsTime)中
元数据信息包括：
内存中的元数据：
文件名及目录结构信息 副本数量 Block的编号 Block和DataNode的映射关系
文件中的元数据：
文件名及目录结构信息 副本数量 Block的编号
SecondaryNameNode
不是NameNode的热备 而是一个帮助者 帮助NameNode合并元数据
触发元数据合并的条件：
时间间隔达到：3600秒 距离上次合并的时间间隔
edits文件大小达到：64MB
不是NameNode的热备 但是其实具有一定的备份能力，因为在SNN里保存着上一次合并的元数据信息 当NN崩溃，元数据信息丢失时，
可以从SNN中找到上一次合并时的元数据 恢复出部分数据。
但是很有可能丢失部分最新的元数据。只能作为极端工具下无奈的选择。
DataNode
存储Block的节点
定时向NN发送心跳报告(3秒一次) 保持存活 向NN报告自己持有Block信息 接受NN的命令
如果连续10分钟NN都没有收到某个DataNode心跳信息 则NN会认为DataNode已经失去连接
合并元数据流程
当达到合并元数据的条件时，先产生新的edits.new文件，之后所有的更新写入此文件
SNN此时来复制NN中的fsimage和edits文件 复制完成后开始进行合并，合并为fsimage.ckpt
将此文件传送回NN，NN删除旧的fsimage将此文件更名为新的fsimage 再将edits.new更名为edits完成 元数据合并
这个过程中NN并不需要停止服务，可以持续工作，利用SNN减轻了NN的合并数据的工作压力。
读流程
使用HDFS提供的客户端开发库Client，向远程的Namenode发起RPC请求；
Namenode会视情况返回文件的部分或者全部block列表，对于每个block，Namenode都会返回有该block拷贝的DataNode地址；
客户端开发库Client会选取离客户端最接近的DataNode来读取block；如果客户端本身就是DataNode,那么将从本地直接获取数据.
读取完当前block的数据后，关闭与当前的DataNode连接，并为读取下一个block寻找最佳的DataNode；
当读完列表的block后，且文件读取还没有结束，客户端开发库会继续向Namenode获取下一批的block列表。
读取完一个block都会进行checksum验证，如果读取datanode时出现错误，客户端会通知Namenode，然后再从下一个拥有该block拷贝的datanode继续读。
当文件最后一个块也都读取完成后，datanode会连接namenode告知关闭文件。
写流程
使用HDFS提供的客户端开发库Client，向远程的Namenode发起RPC请求；
Namenode会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会为文件创建一个记录，否则会让客户端抛出异常；
当客户端开始写入文件的时候，client开发库会将文件切分成多个packets，并在内部以数据队列"data queue"的形式管理这些packets，
并向Namenode申请新的blocks。，获取用来存储replicas的合适的datanodes列表， 列表的大小根据在Namenode中对replication的设置而定
开始以pipeline（管道）的形式将packet写入所 有的replicas中。开发库把packet以流的方式写入第一个datanode，
该datanode把该packet存储之后，再将其传递给在此 pipeline中的下一个datanode，直到最后一个datanode，这种写数据的方式呈流水线的形式。
最后一个datanode成功存储之后会返回一个ack packet，在pipeline里传递至客户端，在客户端的开发库内部维护着"ack queue"，
成功收到datanode返回的ack packet后会从"ack queue"移除相应的packet。
如果传输过程中，有某个datanode出现了故障，那么当前的pipeline会被关闭，出现故障的datanode会从当前的pipeline中移除，
剩余的block会继续在剩下的datanode中继续以pipeline的形式传输，同时Namenode会分配一个新的datanode，保持 replicas设定的数量。
重复如上过程将所有package都上传完成 之后 向NameNode报告成功 关闭文件
**副本存放策略(机架感知策略)：
一个Block有3个副本，这3个副本应该如何保存？
客户端将第一个副本写入离自己最近的节点 如果客户端所在的节点就是个DataNode 则直接上传本地 如果不是 则找到最近的DataNode节点上传
要通过管道流来复制Block
此时第二个副本选择 和第一个副本不同机架的另一个DataNode节点
第三个副本选择和第二个副本相同机架的DataNode节点
删流程
客户端发起请求连接NameNode表示要删除文件
NameNode执行元数据的删除。
当NameNode执行delete方法时，它只标记操作涉及的需要被删除的数据块，而不会主动联系这些数据块所在的DataNode节点。
当保存着这些数据块的DataNode节点向NameNode节点发送心跳时，在心跳响应中，NameNode节点会向DataNode发出指令，要求删除这些block。
DataNode收到指令后删除对应的Block
所以在执行完delete方法后的一段时间内，数据块才能被真正的删除掉。
启动流程
NameNode启动，进入安全模式，只能查看目录结构无法进行其他操作(读写操作)
namenode开始合并元数据，注意这次合并由NameNode自己来进行，合并完成后 生成新的fsimage和新的空的edits文件
再将fsimage中的数据恢复到内存中
接着等待 等待DataNode的心跳报告 DataNode在心跳报告中除了告知NameNode当前DataNode存活以外，还会在心跳中 带着其所持有的Block信息
NameNode根据DataNode心跳中的信息 在内存中构建出 Block对应的DataNode信息
当NameNode获取到足够数量的Block信息后 解除安全模式 开始对外提供服务
**安全模式----注意安全模式最后不要强制退出。