Hadoop分布式文件系统即Hadoop Distributed FileSystem。
当数据集的大小超过一台独立的物理计算机的存储能力时，就有必要对它进行分区（Partition）并存储到若干台单独的计算机上，管理网络中跨越多台计算机存储的文件系统成为分布式文件系统（Distributed FileSystem）。
该系统架构与网络之上，势必引入网络编程的复杂性，因此分布式文件系统比普通磁盘文件系统更为复杂。例如：使文件系统能够容忍节点故障且不丢数据便是一个极大的挑战。
Hadoop有一个成为HDFS的分布式文件系统，即Hadoop Distributed FileSystem。在非正式的文档或旧的文档中也叫着做DFS。HDFS是Hadoop的旗舰级文件系统，它实际上是一个综合性的文件系统的抽象。例如还可以集成其他文
件系统如Amazon S3或本地文件系统。
HDFS以流式数据访问模式来存储超大文件，运行在商用硬件集群上，特点如下：
1、超大文件存储
“超大文件”在这里指具有即便MB、几百GB、几百TB大小的文件，目前已经有了存储PB级别数据的Hadoop集群。（全球最大的Hadoop集群在雅虎，有大约25，000个节点，主要用于支持广告系统与网页搜索。）
2、流式数据访问
HDFS的构建思路是一次写入，多次读取是最高效的访问模式。数据集通常由数据源生成或从数据源复制而来，接着长时间在此数据集上进行各种分析。每次分析都将涉及该数据集的大部分或全部，因此读取整个数据集
的时间延迟比读取第一条记录的时间延迟更重要。
3、商用硬件
Hadoop并不需要运行在昂贵且高可靠的硬件上。它是设计在普通硬件的集群上的，因此至少对于庞大的集群来说，节点故障的几率还是非常高的。HDFS在遇到上述故障时，被设计成能够继续运行且不让用户察觉到明显
的中断。同样那些不适合在HDFS上运行的应用也值得研究。目前对实时性要求较高的应用不适合在HDFS上运行。
4、低时间延迟的数据访问
要求低时间延迟数据访问的应用，例如及时毫秒范围不适合在HDFS上运行。因为HDFS是为高吞吐量应用优化的，这可能会以提高时间延迟为代价。目前对于低延迟时间的访问需求，HBase是更好的选择。
5、大量的小文件
由于NameNode将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总数受限于NameNode的内存容量。根据经验，每个文件、目录和数据块的存储信息大约占150字节，因此举例如果有一百万个文件，且每
个文件占一个数据块，那至少需要300MB内存。尽管存储上百万个文件是可行的的，但是存储数十亿个文件就超出了当前硬件的能力。
6、多用户写入、任意修改文件
HDFS中的文件只能有一个写入，且目前（Hadoop-0.x~Hadoop-2.6.0）只能追加到文件的末尾。不支持多个写入操作，也不支持在文件的任意位置修改操作。
HDFS数据块
每个磁盘都有默认的数据块大小，这是磁盘进行数据读/写的最小单位。构建于单个磁盘之上的文件系统通过磁盘块来管理该文件系统中的块，该文件系统块的大小可以是磁盘块的整倍数。文件系统文件系统块一般为几千字
节，而磁盘块一般为521字节。例如Windos上文件系统的磁盘单位为簇，Linux上文件系统的磁盘单位为block。
HDFS同样有块的概念，但是比较大。在Hadoop-0.x和Hadoop-1.x中默认的块大小为64MB，在Hadoop-2.0及以后的版本中默认的块大小是128MB。与单一磁盘上的文件系统相似，HDFS上的文件也被划分为块大小的多个分块
（chunk），作为独立的存储单元。其他文件系统不同的是，HDFS中小于一个块大小的文件不会占据整个块的空间。HDFS的分块我的理解是逻辑分块，而并非是物理切块。HDFS的块之所以大是为了最小化寻址开销。如果块设
置的足够大，从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。如果使用更多的时间来传输数据显然比寻址更高效。但是块也不会太大，MapReduce中的map任务通常一次只处理一个块中的数据，如果任务
数太少（少于集群中的节点数量），作业的运行速度就会比较慢。分块非常适合用于数据备份进而提供数据容错的能力和提高可用性。在分布式集群的默认情况下HDFS的块副本数为3个，且每个块分布在不同的节点上。这样
的好处是在磁盘或机器发生故障后数据不会丢失，如果一个块不可用时则去其他节点上读取另一个副本，而这个过程对用户是透明的。一个因为损坏或机器故障而丢失的块可以从其他节点上复制到另一台正常运行的机器上，
以保障副本的数量回到正常水平。同样有些应用程序可能选择为一些常用的文件块设置更高的副本数进而分散集群中的读取负载。