在理解分布式存储框架之前，我们不妨先考虑自己设计一款分布式存储系统，以此来尝试理解Hadoop官方分布式存储系统的设计理念。
首先，当我们想要对超过单个磁盘容量的文件进行存储的时候，我们唯二的办法不外乎是扩大单个磁盘容量和增加磁盘总数量。理论上来说，文件的大小是可以不断增加的，而单个磁盘的大小拥有上限，因此唯一的办法便成了增加磁盘总数量。具体来说，想要存储超过磁盘容量的大文件，我们可以将文件进行等大小的拆分，然后存储到不同的磁盘之上，在获取文件的时候，再将文件进行合并即可。
然而以此产生的问题也不可避免，磁盘的故障率是客观存在的，当大文件非常多时，也同样需要大量的磁盘进行存储，因此磁盘故障这样的小概率事件自然成为了必然事件，而一个磁盘的损坏意味着这个磁盘上所有的文件都产生了丢失，在大文件拆分存储的场景下，每一个小文件丢失的背后都代表着一个大文件的全部损毁，因此这样的设计有着致命的缺陷。
对于解决这样的缺陷，官方想到的办法是采用多副本的机制，即：每个拆分出的文件默认有着3份的副本，存储在不同的磁盘之上，因此任意一个磁盘的损坏都不会引起大文件的丢失，因为在所有磁盘组成的集群当中，还有着另外两份副本存在。
这样将大文件拆分成小文件，分布的存储在不同的磁盘只上，并且每个小文件保存着三份副本的形式，就是分布式文件存储系统HDFS的雏形。
HDFS源于Google在2003年10月份发表的DFS——Google File System论文。传统的文件系统对海量数据的处理方式是将数据文件直接存储在一台计算机，也就是一整个文件对应一台计算机。在早期的场景下，这样做并不会存在什么问题，但是随着数据量的不断攀升，这样单节点的存储方式无疑会带来一些问题，如：当保存的文件越来越多，计算机面临存储瓶颈时，就需要扩容；当面临大文件的上传下载，单节点的存储会变得非常耗时。
为了解决传统文件系统遇到的存储瓶颈问题，首先考虑的就是扩容,扩容有两种形式,一种是纵向扩容，即增加磁盘和内存；另一种是横向扩容,即通过增加服务器数量，通过扩大规模达到分布式存储的效果，这种存储形式就是分布式文件存储的雏形，也就是HDFS所采用的存储模式。
解决了分布式文件系统的存储瓶颈问题之后,还需要解决文件上传与下载的效率问题，常规的解决办法是将一个大的文件切分成多个数据块,将数据块存储在不同的计算机节点之上，使用并行上传下载的方式化整为零。具体来说，以300MB的文件为例，先将文件进行横向的切分，切分成3块，每块大小100MB，然后将每个块文件存储在不同计算机节点之上。
如此一来，原本一台服务器要存储300MB的文件,此时每台服务器只需要存储100MB的数据块就完成了工作﹐当上传下载时，3个几点并行工作，从而解决了上传下载的效率问题。但是文件通过数据块分别存储在服务器集群中,那么如何获取一个完整的文件呢?针对这个问题,就需要再考虑增加一台服务器,专门用来记录文件被切割后的数据块信息以及数据块的存储位置信息。
具体来说，可以在文件存储系统中增加一台服务器作为名称空间服务器，也称作为NameSpace服务器，用于管理其他服务器。NameSpace服务器记录着文件被切分成多少个数据块,这些数据块分别存储在哪台服务器中,当客户端访问NameSpace服务器请求下载数据文件时,就能够通过类似查找目录的方式查找数据了。而这个服务器官方命名它为NameNode。
通过前面的操作,看似解决了所有问题,但其实还有一个非常关键的问题需要处理,那就是当存储数据块的服务器中突然有一台机器宕机,就无法正常的获取文件了,这个问题被称为单点故障。针对这个问题,可以采用备份的机制解决。也就是说，每个数据块除了在自己的节点存在以外，还会在自己节点以外的另外两个节点各保存一个备份文件，以三副本的方式存在于整个集群之中。如此一来，任何一台保存数据的节点宕机，节点上的每一份数据块在集群中都还可以找到至少两份数据进行恢复。如上所述，这样保存实际每个块文件的节点，官方命名它为DataNode。
这样的分布式存储、分布式上传下载和多副本机制就共同组成了最简单的HDFS系统。
HDFS是一个易于扩展的分布式文件系统,运行在成百上千台低成本的机器上。它与现有的分布式文件系统有许多相似之处,都是用来存储数据的系统工具,而区别在于 HDFS具有高度容错能力,旨在部署在低成本机器上。HDFS提供对应用程序数据的高吞吐量访问,主要用于对海量文件信息进行存储和管理,也就是解决大数据文件如TB乃至PB级数据的存储问题。