第三章 HADOOP分布式文件系统 第一节 HDFS设计
当数据过大而不适用于单独一台机器的存储容量时，把它分到许多独立的机器上就很
必要了。管理网络计算机存储的文件系统叫分布式文件系统。由于它是基于网络的，所有
复杂的网络程序问题接踵而至，使分布式文件系统比普通的硬盘文件系统更复杂。例如，
最大的挑战是使文件系统可以处理节点失败而不至于数据丢失。
HADOOP自带了一个分布式文件系统叫HDFS，即HADOOP Distributed Filesystem。
（你也许会看到“DFS"----在非正式的场合或老的文档或配置----与HDFS是同一个东西）。
HDFS是HADOOP的代表文件系统，是本章的重点，但是HADOOP有一个通用的文件系
统抽象，所以我们也会看到HADOOP如何与其它的存储系统集成（如本地文件系统和Amazon S3）。
HDFS设计
HDFS是一个文件系统，设计用来存储大学大的文件，并使用流媒体数据访问模式，运行在标准
硬件组成的集群上。让我们看下这条语句的细节
大文件
“非常大”在这个语境里的意思是文件大小有几百M，或G，或T。有HADOOP集群存储了PB级
的数据。
流式数据访问
HDFS是基于这样的思想----数据访问最有效的模式是“写一次，读多次”模式----创建的。一个数据
集从源产生或拷贝，然后基于这个数据集开始各种分析。每一个分析会使用数据集的全部或大部分数据，
所以读取所有数据集合的时间远比读取一条记录的延时重要。
标准硬件
HADOOP不需要昂贵的、高可靠的硬件。它被设计运行在标准硬件组成的集群的（普通的硬件，可以
从各个供货商那买到），做为集群中的节点，出错的机会是很高的，尤其是大的集群。HDFS设计可以进行
工作而不需要用户面对这个失败导致明显的中断。
也需要知道哪些项目不适用于HDFS。也许将来会改变，至少现在这些领域不适合HDFS:
低延迟数据访问
要求数据访问低延迟的项目，要在10几毫秒的范围内，不适合HDFS。记住，HDFS优化是针对大
吞吐量的数据，并以延迟的代价。HBase（见20章）是目前针对低延迟访问的较好选择。
大量小文件
因为namenode在内存中保存文件系统元数据，文件系统的文件数据限制是由namenode的内存总量
决定的。根据经验，每一个文件、目录以及块占用大约150字节。所以，如果你有100万文件，每个文件占
用一个块，你至少需要300M内存。尽管存储几百万文件是可以承受的，几十亿的会超过目前硬件的容量。
多次写，任意位置修改文件
HDFS的文件写许是由一个程序写的。写操作一般只在文件末尾，并且只能增加。它不支持多个程序
写或在文件任意位置修改（也许将来会支持，不会那样会相对低效）。