hadoop的存储模型整个思想就是：化整为零、并行计算。
第一步：如果一个文件非常非常大，单台服务器的内存无法处理这样一个大文件，无法一次性加载到内存中，可以对文件切割成若干个小文件。第二步：为了达到提升计算效果的目的，可以把切割的小文件分散发送到多台服务器之上，让服务器并行计算小文件，由于每台服务器它所计算得数据量比较小同时他们又是并行的，就可以达到分而治之的目的。以上即分布式存储和分布式计算。
下面就谈及到了第一个问题，文件的切割。文件线性切割成块block，切割的单位叫做块；块分散存储在集群节点中。文件切割是按照字节来切割，对于计算机来说无论什么数据最终都会转换成01的模式来存储，所以底层的单位为字节。hdfs以字节数组的方式切割。假设一整个文件大小为100byte，按照每个块存储大小为10个字节，此时可以切割10个块。（一个汉字对于utf-8编码来说中占三个字节，对GBK编码来说占两个字节，假定切割的块正好跨了字节就是某个字的第一个字节在第一块的末尾中，后两个字节在第二块的起始，此时分别读取的结果肯定会乱码，hdfs对这种情况做了纠正。）
第二个问题就是偏移量的概念：每一个切割后的块都有一个偏移量，块会分散散列在集群的节点之中。可能是第一台服务器处理第一个块，第二台服务器处理第二个块等等。假定有50台服务器，该文件切割成10块，只会把这10个块分散到10个服务器之上，一个节点一个。假定只有5个节点（即五台服务器）那么就是一个节点放置两个块，而且这种放置是无序的，并不是第一块第二块对应第一个节点，三四块对应第二个节点，而是任意放置的，只确保每个节点放置两块，达到负载均衡的效果。第一块的偏移量是0，第二块的偏移量取决于块的大小，假定每个块大小为10byte，那么第二个块的偏移量为10，第三个即20.。。。。。由于每个块散列在不同的节点上，根据每个块的偏移量设置就可以完成查询和归并的工作。单一文件Block大小一致，文件与文件可以不一致。在切割时每一个块的大小一致，最后一个块不确定（在不是整除的情况下有可能会比前几个块小一点）。但是如果是不同的文件，块的大小可以不一致，如果第一个文件按10个字节切割，第二个文件可能按50个字节切割。
第三个问题是副本问题。文件线性切割成块，块分散存储在集群节点中，Block可以设置副本数，副本无序分散在不同节点中。假定一个文件切成两块，为了避免某一节点挂掉（该节点的块也丢失），所以要对块做副本即备份。某一节点挂掉还可以从另一节点读取该块。hdfs默认副本数为3。副本数不要超过节点数量，假定节点个数为3，副本数为4，则至少有一个节点的副本数量要为2，这种情况 是没有意义的，因为副本之间完全相同，一个节点挂掉，该节点的副本也跟着消失。副本的目的是为了数据可靠，数据越大，完整性保障越小；副本数越多，对于计算性数据移动的成功率越大。比如三个副本散列在三台服务器之上，如果你同时跑三个计算程序，这三个计算程序都成功移动到数据旁边，数据副本就在每台服务器之上，然后你每台服务器都跑一个程序，这三个程序肯定会开辟进程，占用本台服务器机器的资源，这时又要跑其他服务器的程序，如果这个块只有三个分身，那么程序肯定会向三个分身所在的节点疯狂的移动，程序过来计算肯定会开辟进程，结果资源占满了不够用了，那么程序就需要分布到其他节点，但其他节点没有该数据副本，所以需要移动数据块即数据性计算移动。所以如果节点当中有一笔作业，每天都有很多程序要用它，即这个块被很多程序所用，那么最好将该块的副本数量调高，散落在更多的节点之上，避免计算时只集中在某几个节点，造成资源的拥堵。
文件上传可以设置Block大小和副本数，hdfs默认块大小是128mb，副本数为3。如果设置的话范围需在1mb~128mb，已上传的文件block副本数可以调整（因为有可能有多个程序要计算这些副本数据，为了提高效率，可以通过提升副本数量，让他散落在更多的节点之上。副本数量越多并行计算的可能性越大），但是文件的大小不能改变。
只支持一次写入多次读取，同一时刻只有一个写入者。不允许修改文件块数据的内容。但是可以追加数据。因为追加不会影响到其他块的迁移问题。设想：每个节点散列着不同的块，假定其中一个块改变了，那么其他的块也会受到影响，偏移量也会跟着改变，所有块都要移动，那么整个集群就会被牵扯进来。如果很多人都并发修改这个文件，此时集群的所有的能力只能全部用来保证文件的一致性，维持文件的完整性，其他的计算无法进行。