HDFS 有着高容错的特点，被设计用来部署在低廉的硬件上，它能够提供高吞吐量来访问应用程序·的数据，适合那些有着超大数据集的应用程序。为了做到可靠性，HDFS创建了多份数据块的副本，并将它们放置在服务器的群的计算节点中，Mapreduce 可以在它们所在的节点上处理这些数据。
HDFS 的缺点与不足：
运维成本：如果采用" 一个框架，一个集群” 的模式，则可以需要多个管理员管理这些集群，进而增加运维成本，而共享模式通常需要少数管理员完成多个框架的统一管理，比如毫秒级的访问要求不适合小文件存取。
数据共享：随着数据量的暴增，跨集群间的数据移动不仅需花费时间，且硬件成本也会大大增加，而共享集群
模式，可让多种框架共享数据和硬件资源，将大大减少数据移动带来的成本：
HDFS的基本概念
HDFS 特点
1.适合运行在通用硬件，错误监测以及快速自动的恢复能力较好；
2.支持大文件存储，能提供比较高的数据传输带宽与数据访问吞吐量；
3.计算环境量移动到数据存储的地方，而不是把数据传输到计算环境的地方，有效减少网络的拥塞，提供系统的吞吐量
HDFS 适用场景
1.存储并管理PB数据；
2.适合处理非结构结构化数据；
3.注重数据处理的吞吐量
4.应用模式：write-once-read-many 存储模式
HDFS不适用场景
1.低时间延迟数据访问的应用，例如几十秒范围
原因：HDFS 是为高数据吞吐量应用量优化的，这样是以高时间延迟为底价
2.大量小文件
原因：NameNode 将文件系统的元数据存储在内存中，因此文件系统所能存储的文件总数受限于NameNode 内存容量。如果每个文件目录和数据块的存储信息大约占150字节，那么对于一百万个文件，假如每个文件仅占用一个数据块，则就至少需要300MB的内存，假设需要存储几十亿文件，这时需要的内存量将是非常巨大的。
3.多用户写入，任意修改文件：现在hdfs 文件可能只有一个 writer ，而且写操作总是写在文件末尾
HDFS 数据块
在传统的块存储介质中，块是读写的最小数据单位（扇区),传统文件系统是基于存储块进行操作的，为了节省文件分配表空间，一般会对物理存储进行整合，大小设定为4096 字节
HDFS 也使用了块概念，但是默认大小设定为64 M字节。HDFS 可针对每个文件由客户端指定配置，每个块有一个自己的全局ID，HDFS将一个文件分为一个或者数个块来存储，每个块是一个独立的存储单位，以块为单位在集群服务器中分配存储。
HDFS 体系结构
之前细说过，这里就不在细说了
NameNode
Namenode 是HDFS的元数据节点，负责文件系统的名字空间(Namespace) 管理以及客户端对文件的访问。NameNode 负责文 件元数据操作，DataNode 负责处理文件内容的读写操作，跟文件内容相关得数据流不经过NameNode，数据块的副本存放在哪 些DataNode 上是由NameNode决定的，读取文件时NameNode 会尽量让用户先读取最近的副本，以降低带宽消耗和读取延时。
NameNode 全权管理数据块复制，它周期性从集群中的每个DataNode 接受心跳信号和块状态状态。接收到心跳信号意味着DataNode节点上工作正常。块状态报告包含一个该Datanode 上所有数据块信息的列表。
NameSpace 和EditsLog
HDFS 支持传统的层次型文件组织结构，用户可以在HDFS上创建目录，然后将文件保存在这些目录里。文件系统名字空间的 层次结构和大多数现有文件系统类似：用户可以创建，删除，移动或者重命名。NameNode 负责维护文件系统的名字空间，任 何对文件系统名称空间副本的数目称为文件系统的副本系数。这个信息是由Namenode 保存的。
Datanode
负责所在物理节点的 存储管理
一次写入，多次读取 （不修改）
文件由数据块组成， 典型的块大小是64MB
数据块尽量散布道各 个节点
Secondary NameNode
当NameNode 启动时，它从映像文件(fsimage）读取HDFS 的状态，然后将EditsLog 文件中的修改应用在内存中，接着将新的HDFS 状态写入fsimage，后续的正常操作开始于一个空的EditsLog日志文件。由于NameNode 仅仅在启动时候将fsimage 和EditsLog 合并，因此在一个大的集群上经过一定运行时间后，EditsLog将会非常大，由此带来的一个副作用就·是在下次NameNode 重新启动时将会话费很长时间。Secondary NameNode 通常在一个独立的机器上运行，它的内存要求和主NameNode 一样的。Secondry NameNode 在配置后通过start-dfs.sh 启动。
Checkpoint Node
配置Checkpoint Node 和Secondry NameNode 类似，前者是后者的替代方式，不同之处在于它周期性将NameNode 的FsImage 和EditsLog 下载本地合并，然后把合并的结果上传会NameNode，一个NameNode 可以同时配置多个Checkpoint Node
Backup Node
Backup Node 同样提供上述Checkpoint 的功能，其维持一份NameNode 同步的同步的内存映射。Back Node 接受NameNode 的EditsLog，同时还将其内容更新至自己呢内存，相当于做了一个Namespace 的备份。
Backup Node 因为是时刻与NameNode 同步的，所以他不需要从NameNode 下载FsImage 和EditLog ，只需要定期把本机上的FsImage 和EditsLog 保存即可。
对于每个NameNode ，目前只允许配置Backup Node，而且使用Backup Node 模式就不允许登陆Checkpoint Node。
HDFS High Availability
在Hadoop2.0 之前，每个集群只能有一个NameNode，如果它出现问题就会导致整个集群瘫痪掉。因此在NameNode 需要有一定的冗余，通常的做法是把NameNode 配置成Active/Standby, 在Active 失效的时候能立即切换Standby 机上。现阶段Active、Standby 直接的同步两种方式：
JournalNode(JNS)伺服方式：ActiveNode 持续的将EditsLog 写入JournalNode 伺服进程，而是StandbyNode 则能实时监测并从读取相关内容同步。
Share NFS Directory 方式：通过挂接一个主从NameNode 节点都拥有读写权限的共享文件夹方式进行同步。Active 一方面不断将EditsLog 写入该文件夹，而Standby 泽监视该文件的同时同步到自己Namespace 中
读取数据过程
HDFS的可靠性
.冗余副本策略
.机架策略
心跳机制
.安全模式
.校验和
.回收站
.元数据保护
.快照机制
冗余副本策略
可以在hdfs-site.xml中设置复制因子指定副本数量 所有数据块都有副本 Datanode启动时，遍历本地文件系统，产生一份hdfs数据块和本地文件的对应关系列 表（blockreport）汇报给namenode
机架策略
集群一般放在不同机架上，机架间带宽要比机架内带宽要小
HDFS的“机架感知”
一般在本机架存放一个副本，在其它机架再存放别的副本，这样可以防止机架失效时 丢失数据，也可以提高带宽利用率
心跳机制
Namenode周期性从datanode接收心跳信号和块报告 Namenode根据块报告验证元数据
没有按时发送心跳的datanode会被标记为宕机，不会再给它任何I/O请求
如果datanode失效造成副本数量下降，并且低于预先设置的阈值，namenode会检测 出这些数据块，并在合适的时机进行重新复制
引发重新复制的原因还包括数据副本本身损坏、磁盘错误，复制因子被增大等
安全模式
Namenode启动时会先经过一个“安全模式”阶段
安全模式阶段不会产生数据写
在此阶段Namenode收集各个datanode的报告，当数据块达到最小副本数以上时， 会被认为是“安全”的
在一定比例（可设置）的数据块被确定为“安全”后，再过若干时间，安全模式结束
当检测到副本数不足的数据块时，该块会被复制直到达到最小副本数
校验和
在文件创立时，每个数据块都产生校验和
校验和会作为单独一个隐藏文件保存在命名空间下
客户端获取数据时可以检查校验和是否相同，从而发现数据块是否损坏
如果正在读取的数据块损坏，则可以继续读取其它副本
回收站
删除文件时，其实是放入回收站/trash
回收站里的文件可以快速恢复
可以设置一个时间阈值，当回收站里文件的存放时间超过这个阈值，就被彻底删除， 并且释放占用的数据块
元数据保护
映像文件刚和事务日志是Namenode的核心数据。可以配置为拥有多个副本
副本会降低Namenode的处理速度，但增加安全性
Namenode依然是单点，如果发生故障要手工切换
快照
支持存储某个时间点的映像，需要时可以使数据重返这个时间点的状态
Hadoop目前还不支持快照，已经列入开发计划
HDFS文件操作
命令行方式 API方式
怎样添加节点？
在新节点安装好hadoop
把namenode的有关配置文件复制到该节点
修改masters和slaves文件，增加该节点
设置ssh免密码进出该节点
单独启动该节点上的datanode和tasktracker（hadoop-daemon.sh start datanode/tasktracker）
运行start-balancer.sh进行数据负载均衡