一. hdfs设计的动机
为大规模分布式计算准备的分布式文件系统，并非实时性要求很高的文件系统。
二. 设计的取舍
1. 因为要求有高吞吐量，所以牺牲读取文件的实时性，实时性要求高的分布式文件系统可以选择hbase
2. 使用廉价的机器，所以任意一个存储节点可能会挂掉，将之视为hadoop的常态
3. 流式存储，一次写入，多次读取进行数据迭代，写入也尽量采取在文件的末尾进行追加的方式，在任意一处写入数据的操作代价很高，尽量不要做
4. 不鼓励使用大量的小文件处理，每个小文件都需要都有一个元数据来存储这些小文件的信息，并且这些信息都存储在namenode上，一条元数据大概是150K左右的大小，而namenode的容量是有限的
三. hdfs中的块
hdfs中的块与普通文件系统中的块（这里是逻辑块，不同于磁盘中的块）的概念类似，都是文件系统可操作的最小单位，但是大小差别很大，常见的文件系统的块通常为磁盘块大小（512字节）的整数倍，而hdfs中的块默认大小为64M
hdfs的块之所以那么大，是为了尽快寻址，并且hadoop中的不鼓励处理小文件，而大小小于64M的文件会被单独占一个块，只是这个块的大小等于文件的大小，并不是64M
hdfs中的块很适合做备份，通常每个块都会有三个备份，然后存储在不同的节点上，即使其中一个节点挂掉，仍然可以找到备份的数据块（如何将块尽量的比较均匀分布在不同的节点上？）
四.namenode和datanode
namenode是管理者，datanode是执行者
namenode存储着文件块的位置、索引信息、namespace，这些信息在系统重启时重建，还存储操作日志
datanode上存储着具体的文件块，并且在一个固定的时间段内（心跳），会向namenode报告自己的状态和块列表信息
如果namenode上的信息丢失，将是整个文件系统的灾难，所以要有一定的机制来保证文件存储的可靠性
hdfs一般通过两个机制来保证可靠性：
a. 写时copy:在namenode进行写操作（原子操作）的同时，在向本地磁盘写的同时，也会向网络上的某个机器上写同样的内容，通常通过NFS完成
b. 镜像备份：定期将namenode上的数据在另一个机器上创建镜像，进行备份，如果namenode出现问题，则通过镜像进行恢复，缺点是仍然会损失一些数据
从上述这张图中，可以看出，用户写文件并不是经过namenode进行转发，而是直接往datanode上写,然后由datanode将自己节点上块信息传给namenode，这样就避免了namenode成为系统IO的瓶颈。
五. 常见hdfs命令
1. 见$hadoop fs -help http://hadoop.apache.org/docs/r1.2.1/file_system_shell.html 阅读帮助和文档是最好的学习命令的方式
2. 修改~/.bashrc 映射常用命令