• 存储大文件。上G、T甚至P。
• 一次写入，多次读取。并且每次作业都要读取大部分的数据。
• 搭建在普通商业机群上就可以了。虽然会经常宕机，但HDFS有良好的容错机制。

• 实时数据获取。如果有这个需求可以用HBase（hbase有主键索引，还会充分利用内存缓存数据块）。
• 很多小文件。因为namenode要存储HDFS的metadata（比如目录的树状结构，每个文件的文件名、ACL、长度、owner、文件内容存放的位置等等信息），所以HDFS上文件的数目受到namenode内存的限制。
• 并发环境下的写入和修改。

hadoop中存储文件以HDFS形式存储,HDFS拥有自己的设计原则：

• 文件大小以block块的形式存储
• 每个块至少分配到三台DataNode（看集群情况而定）
• 通过副本机制提高可靠度和吞吐量
• hadoop1.0使用单一的master（NameNode）来协调存储元数据（metadata）
• 最有意思的是hadoop设计者没有设置客户端缓存机制，因为我们对处理数据有足够的信心。

主要存储元数据：例如：文件名，拷贝几份，分别备份到哪里；

过程大概如下： client要向集群中写入数据，首先询问Master（NameNode）,Master告知客户端向哪些DataNode 写入数据，在往DataNode写入数据的同时，DataNode与NameNode保持心跳，如果DataNode在执行 任务失败，NameNode会通过心跳机制得知DataNode死掉，将重新分配新的任务到其他的DataNode。

为了让Standby Node与Active Node保持同步，这两个Node都与一组称为JNS的互相独立的进程保持通信(Journal Nodes)。当Active Node上更新了namespace，它将记录修改日志发送给JNS的多数派。Standby noes将会从JNS中读取这些edits，并持续关注它们对日志的变更。Standby Node将日志变更应用在自己的namespace中，当failover发生时，Standby将会在提升自己为Active之前，确保能够从JNS中读取所有的edits；即在failover发生之前，Standy持有的namespace应该与Active保持完全同步。

为了支持快速failover，Standby node持有集群中blocks的最新位置是非常必要的。为了达到这一目的，Datanodes上需要同时配置这两个Namenode的地址，同时和它们都建立心跳链接，并把block位置发送给它们。

任何时刻，只有一个Active Namenode是非常重要的，否则将会导致集群操作的混乱，那么两个Namenode将会分别有两种不同的数据状态，可能会导致数据丢失，或者状态异常，这种情况通常称为“split-brain”(脑裂，三节点通讯阻断，即集群中不同的Datanodes却看到了两个Active Namenodes)。对于JNS(Journal Nodes)而言，任何时候只允许一个Namenode作为writer；在failover期间，原来的Standby Node将会接管Active的所有职能，并负责向JNS写入日志记录，这就阻止了其他Namenode基于处于Active状态的问题。

ZKFC是Hadoop中通过ZK实现FC功能的一个实用工具,FC是要和NN一一对应的，两个NN就要部署两个FC。它负责监控NN的状态，并及时的把状态信息写入ZK。它通过一个独立线程周期性的调用NN上的一个特定接口来获取NN的健康状态。FC也有选择谁作为Active NN的权利，因为最多只有两个节点，目前选择策略还比较简单（先到先得，轮换）。如果namenode状态异常，ZKFC会作出判断，先通过Fenceing功能关闭namonode（，然后在ZK上删除它对应ZNode。发送上述事件后，在另外一台机器上的ZKFC中的ActiveStandbyElector 会收到事件，并重新进行选举（尝试创建特定ZNode），它将获得成功并更改NN中状态，从而实现Active节点的变更。

• 第一副本：如果是本地上传，放置在上传文件DataNode。如果是集群外提交，由NameNode选择一台磁盘不太满，CPU不太忙的节点。
• 第二副本：放置在于第一副本不同的机架的节点上
• 第三副本：与第二个副本相同集群的节点

也许根据业务的需要我们需要更多地副本，其他副本随机分配

客户端在与数据节点通信出现错误，客户端会向NameNode报告错误，并尝试连接包含此数据块的下一个数据节点，直到读取成功或所有datanode失败。失败的数据节点将被记录，以后不再连接。namenode收到客户端的通知后会自动恢复错误数据块。

• Block默认大小64M，如果上传文件小于64M，那么仍然占用一个命名空间（NameNode metadata），但是物理存储不会占用64M空间；（这也是hadoop为什么不太适合处理小数据的原因之一）
• Block大小和副本数由Client端上传文件到HDFS时设置，其中副本数可以变更，Block是不可以再上传后变更的

hdfs为了性能牺牲了一部分一致性要求

• 创建一个文件后能立即可见
• 但是写入文件的内容并不保证立即可见，即使数据流已经刷新并存储，当写入的数据超过一个块后，新的reader才能看见这个块。

当且仅当该目录是snapshottable。快照只读，不可写

hdfs dfsadmin -allowSnapshot