（ hdfs的设计理念
硬件故障是常态而非例外。HDFS实例可能包含数百或数千台服务器计算机，
每台计算机都存储文件系统数据的一部分。事实上，存在大量组件并且每个
组件具有非平凡的故障概率意味着HDFS的某些组件始终不起作用。
因此，检测故障并从中快速自动恢复是HDFS的核心架构目标。
在HDFS上运行的应用程序需要对其数据集进行流式访问。
它们不是通常在通用文件系统上运行的通用应用程序。HDFS设计用于批处理而不是用户的交互式使用。
重点是数据访问的高吞吐量而不是数据访问的低延迟。
POSIX强加了许多针对HDFS的应用程序不需要的硬性要求。
交易几个关键领域的POSIX语义以提高数据吞吐率。
在HDFS上运行的应用程序具有大型数据集。HDFS中的典型文件大小为千兆字节到太字节。
因此，HDFS被调整为支持大文件。它应该提供高聚合数据带宽并扩展到单个集群中的数百个节点。
它应该在单个实例中支持数千万个文件。
HDFS应用程序需要一个一次写入多次读取的文件访问模型。
除了追加和截断之外，无需更改创建，写入和关闭的文件。支持将内容附加到文件末尾，
但无法在任意点更新。该假设简化了数据一致性问题并实现了高吞吐量数据访问。
MapReduce应用程序或Web爬虫应用程序完全适合此模型。
应用程序请求的计算如果在其操作的数据附近执行则更有效。
当数据集的大小很大时尤其如此。这可以最大限度地减少网络拥塞并提高系统的整体吞吐量。
假设通常更好的是将计算迁移到更靠近数据所在的位置，而不是将数据移动到运行应用程序的位置。
HDFS为应用程序提供了接口，使其自身更靠近数据所在的位置。）
数据块(block)：存储在hdfs中的最小单位。默认大小128M
这么大的原因：
为了最小化寻址开销，一般寻址时间为10ms，传输速率为100MB/s，为了寻址时间占传输时间的1%
namenode启动过程
加载fsimage
加载edites
进行检查点保存
等待datanode汇报块信息
datanode启动过程
扫描本地块的信息
汇报给namenode
心跳机制
datanode每隔三秒汇报给namenode
检查点（运行时主要由secondarynamenode完成）
它从磁盘读取FsImage和EditLog，将EditLog中的所有事务应用到FsImage的内存中表示，
并将此新版本刷新为磁盘上的新FsImage。然后它可以截断旧的EditLog，
因为它的事务已应用于持久性FsImage
配置运行检查点的阀值（时间间隔）
<property>
<name>dfs.namenode.checkpoint.period</name>
<value>3600</value>
<description>The number of seconds between two periodic checkpoints.
</description>
</property>
配置运行检查点的阀值（操作次数）
<property>
<name>dfs.namenode.checkpoint.txns</name>
<value>1000000</value>
<description>The Secondary NameNode or CheckpointNode will create a checkpoint
of the namespace every 'dfs.namenode.checkpoint.txns' transactions, regardless
of whether 'dfs.namenode.checkpoint.period' has expired.
</description>
</property>
检查是否达到阀值
<property>
<name>dfs.namenode.checkpoint.check.period</name>
<value>60</value>
<description>The SecondaryNameNode and CheckpointNode will poll the NameNode
every 'dfs.namenode.checkpoint.check.period' seconds to query the number
of uncheckpointed transactions.
</description>
</property>
安全模式
进入
hdfs dfsadmin -safemode enter
手动保存命名空间
hdfs dfsadmin -saveNamespace
离开
hdfs dfsadmin -safemode leave