我们可以利用hadoop来存储大规模的数据，并且能够在很多时候保证数据的可靠性，而对于map/reduce运算，这些数据也能很好的被利用，这里说的就是HDFS(Hadoop Distibuted Filesystem)——hadoop自己的分布式文件系统。
先来看看什么叫做文件系统：
a file system (or filesystem) is a type of data store which can be used to store, retrieve and update a set of files.
以上的定义很清楚：可以被存储、获取、更新文件的数据存储类型就是一个文件系统，当然我翻译的可能不是很准确。。
HDFS正是一个这样的东西，它提供了一系列的接口来操作存储在其自身上的数据，或者说叫做文件，它自身可以管理这些文件，可以定义文件的副本数量（实际上是block副本的数量），并且，最给力的是它是分布式的，基于这个分布式的文件系统，我们就能把在本地文件系统（磁盘）上由于文件太大而不能存储的数据来存储到这个分布式文件系统上，而不需要关心它到底是如何存储的。
我把这个系列的文章作为入门文章，所以在这里我们只需要知道hadoop实现了这样一个文件系统，并且它是分布式的就可以了，而在后续的文章中，在进行HDFS的具体实现原理和代码级的剖析。
HDFS只是Hadoop文件系统体系中的一个实现，hadoop支持的文件系统远不止HDFS自己
hadoop提供了一些实现（java实现），以支持访问或存储不同的文件系统，比如说Amazon的s3文件系统、Kosmos文件系统，甚至是由FTP服务器支持的文件系统（可以这样理解，ftp服务器把本地的文件系统抽象成支持ftp协议的文件系统以供外界通过FTP协议来访问），理论上你可以使用上述中任意一种文件系统来作为Map/Reduce任务的输入，但是在处理大数据集时，HDFS应该是最好的选择了。
如果用单一的文件系统，而不是分布式的文件系统中的数据来作为Map/Reduce任务的输入的话，有两方面的问题：1、输入的文件超过了文件系统所能承载的上限（还有磁盘IO，网络瓶颈等问题）。2、文件系统能够支持大规模数据但集群上的Map任务将不能享受到数据本地化的优势，所有的Map任务的输入都要经过网络传输。(没错，说的就是Amazon的S3)。