什么是HDFS？

HDFS的全称是hadoop distributed file system，即hadoop的分布式文件系统。

见名知意，它就是用来进行文件存储的。毕竟它是大数据的一个组件，用来存储这种海量的数据。

它是基于03年10月份，谷歌发表的GFS这篇论文做的开源实现。目前是hadoop的一个核心子项目，用来解决海量数据存储的问题。

hadoop的三个子项目，一个是HDFS，一个是YARN，一个是MapReduce。

目前在开源大数据技术体系中，它的地位是无可替代的。

第一它诞生年限比较早，这么长时间的发展，它是非常成熟非常可靠的。再一个它的生态圈也非常广泛，社区这一块也非常活跃。在分布式文件系统选型的时候一般还是首选。

HDFS有什么优势

1、海量数据存储（典型文件大小GB~TB，百万以上文件数量， PB以上数据规模）

HDFS能够存储海量数据，这是它作为文件系统的必要的功能；它存储的数据典型文件大小是GB到TB，单个文件比较大，整体的一个规模也比较高。

海量的数据可以存得下，单个文件比较大也可以存得下。

它的一个存储方式就是多节点存储，至少使用3个节点来进行数据存储，如果存不下则可以进行节点的扩充来提升存储容量。

如果是某一个文件比较大，比如说一个文件是10个tb。10个tb的话直接存在某1个节点肯定是有压力的，所以它的方法在于先切分。不管你这个文件多大，先切成默认128M的这些小的数据块（称为Block块）。

为什么是128M？其实在1.x版本里面它是64M，因为那会儿硬件性能还不是特别好，硬盘的读取效率大概就是五六十兆每秒。目前的硬盘的读取效率大概是100M每秒，所以它的切分的力度就稍微扩大了一些。

切分成这些小数据块以后，把这些小数据块打散存储到各个节点。这样也就意味着不管单个文件多大，都可以完成存储。

2、高容错（多副本策略）、高可用（HA，安全模式）、高扩展（10K节点规模）

再一个存起来它是高容错的，集群的任意一个节点挂掉，它其实数据是不丢失的，数据是可靠的。或者任意一个盘挂掉，盘的损坏是不影响数据的。这个是怎么办到的？它采用多副本，就是多备份几份。

拆出来的这些数据块存储在某一节点后，还要在其他节点进行备份。这样的话任意一个节点挂掉没关系，另外的两个副本还在，数据是不丢的。

而且整个平台它是高可用的，高可用主要是针对管理节点。包括高扩展，性能不够或者存储容量不够，可以通过增加节点来扩容。

所以前两个是它作为一个文件系统基本的职责。

3、构建成本低、安全可靠（构建在廉价商用机器上，提供容错机制）

相对于其他系统，它的一个好处或者优势还在于构建成本低，而且安全可靠。它可以构建在廉价的商用机器上，而且提供这种容错机制，容错机制是通过多副本形式提供的。

这样的话能够极大的降低硬件的成本。

因为之前大家用的服务器，都是一些大型机或者中型机，就是非常昂贵的商用的服务器。那种的话硬件会比较可靠一些。

但HDFS它的软件机制，因为提供了容错，可以部署在廉价商用机器上。这个是企业非常希望看到的，节约了成本。

4、适合大规模离线批处理（流式数据访问，数据位置暴露给计算框架）

而且它存起来的数据适合大规模的底线批处理，为后面的mapreduce或者spark计算框架服务。它们在计算的时候要用到一种方式叫移动计算而非移动数据，就是数据不要动，把计算任务移动到数据节点。

而hdfs天然支持这种模式，原因在于HDFS把数据保存起来之后，HDFS的管理节点会记录这些数据的位置，这个时候计算任务想要分发到数据节点，那HDFS可以提供数据的具体位置，让计算任务来完成一个分发操作。

所以这是它的整个优点。总结起来其实也很简单，能存储海量的数据，而且存起来高容错；如果存储不下可以扩展，构建成本又比较低，存起来的数据能满足后续的大规模的离线批处理。

HDFS不适合哪些场景

当然对于一个组件来说，它既有优点就会有缺点。缺点其实并不是说这个软件有问题，而是这个软件它不适合的场景。

我们要有一个这样的概念，就是说软件它一定有适合的场景，也有它不适合的场景。软件没有好坏，技术没有好坏，它在适合的场景里可以发挥它的优势，在不适合的场景里面就会导致生产上的一些问题。

对于hdfs它不适合哪些场景？

1、不适合低延迟数据访问

HDFS不适合低延迟的数据访问，它完成数据读写的时间是比较长的。大家可以想象一下，1个文件比如说1GB，它首先要拆分出128M的数据块，拆分需要一段时间；拆分完以后，这些拆分出来数据块，要往集群里面进行存储，而且在存储的时候还要进行多副本的备份。

存储完成后，这些数据的位置都要记录在管理节点；即这个文件它拆分成多少块，每一块在哪些节点上存着，而且默认会存储三个副本，这些位置都要记录在管理节点。整个调度流程就很长，所以它的写的延迟会比较高一些。

当然这个也可以理解，因为hdfs它的本质目的是为了满足海量数据的一个存储。它先要保证你这个海量数据能够存得下，然后再来保证其它的特性，所以延迟这一块并不是它主要关注的一个内容。

而且在数据读取的时候，因为数据块是存储到在集群各个节点里面，于是需要从hdfs管理节点先找到到这个文件的位置信息，然后在各个节点里面进行数据块的找回；数据块先读回到客户端，并在客户端合并成最终的原始文件。可想而知读的延迟也是会比较高的。

所以你可以把hdfs当成一个海量数据，或者大文件存储的一个软件，但是你不能要求它是低延迟的，因为它设计的重点不在这里。

2、不适合大量小文件存储（元数据占用NameNode大量空间，移动计算时任务数量增加）

HDFS不适合小文件存储，这个是非常重要的，小文件存储会带来很多的问题。第一是存储上的问题，第二是计算上的问题。

当一个文件存储完成之后，在hdfs的管理节点要对数据的位置信息进行记录。记录这个文件，它被拆分成了多少Block块（数据块），这些数据块它在哪些节点存着，这个信息我们叫元数据。

元数据会记录在管理节点内存当中。

一个1GB的文件如果被拆分成5个Block块，在hdfs的管理节点内存当中，只需要记录5份元数据信息。同样的1GB的文件，它被拆分成1024份，每一个Block块其实是1M，这个时候管理节点内存当中肯定会占1024份的空间。

大量的小文件都存上来之后，有可能会把管理节点的内存占满。这个时候集群中的所有的文件，就都没办法进行操作了，因为管理节点这块内存已经溢出。

所以小文件存的越多，对管理节点带来的内存压力越大。

第二，小文件对计算会产生压力。1GB的文件如果被拆分成三份进行存储，在运行计算任务的时候，只需要分发三个计算任务上去就可以了（移动计算而非移动数据），即需要3个Task。

同样的1GB文件，如果被拆分成了1024份，在做相同的计算任务时，要分发1024个task上去，大家想一下哪个计算效率更高？肯定是相对大的这种文件，计算效率更高，因为只需要分发3个task。

同样的1024个task它要生成，然后再要调度再要分发，这个过程中花费了大量的时间；虽然每个task运算效率其实很高，因为每个task只需要处理1MB的数据，但是在前期的调度过程中花费了大量的时间。

所以不只是hdfs，像所有的大数据的框架，它对小文件这一块都是比较头疼的。

那什么叫小文件？小文件其实是远远小于128M（一个标准Block大小）的这些文件。

3、不支持并发写入

HDFS它不支持并发写入，其实是它为了保证数据的可靠性导致的。

它不支持把文件拆分成多份之后，使用并发任务将数据块写入到各个节点。因为在并发过程中，万一说某几个数据块没有写入成功，它带来的维护成本其实是非常高的。

假设一个文件大小为1tb，它可能拆分成几千份或者几万份，这个时候如果你走并发，带来的维护成本是可想而知的。

所以它在数据进行写入的时候是先拆分，拆分后单线程顺序写入，这样的话首先能保证数据可靠，再一个维护成本也会大大的降低。

所以它不支持这种并发写；当然我们也可以理解，它首要任务是保证海量数据的一个存储，完成了基本功能后，再去考虑其他的功能。

它的延迟包括并发这一块其实要差一点。

4、不支持文件随机修改（仅支持追加写入）

HDFS不支持文件的随机修改，仅支持文件的追加写入。也是出于hdfs基本功能的一个考虑，因为文件存储在HDFS里，并且会存储三个副本，三个副本均在不同的节点。

假设整个集群有50Pb的数据，有这么多数据的情况下，如果开放了随机修改的功能，势必在同一时间会有大量的更改操作。而且更改任务一定是三个节点同时进行的。即使只有1pb的数据触发了随机修改任务，整个集群也是承受不住的。

集群的压力一旦飙升上来之后，它连最基础的这种数据读写功能都完成不了。所以hdfs是不支持文件随机就改。

如果说硬要去做文件修改，可以把之前的文件删掉，然后把新文件给它追加进去，这样是可以的。

如果这个时候有的同学说不理解了，在生产环境中把文件写进去以后，它明明会有很多的这种更改操作，hdfs不支持更改那怎么办呢？

那就不要用hdfs，hdfs它只是一个文件系统，如果想对文件系统里面的数据进行更改，可以用基于HDFS文件系统的一些软件，比如说数据库，在大数据这一块的话有hbase、hive。

它们这些上层软件，是支持对数据进行修改的。虽然说它们的文件最终也是存在hdfs里，但是它们上层实现了随机修改的功能。

OK，HDFS的基本概念就分享到这里，配套视频讲解，可以在B站【数舟】中观看，B站传送门：https://www.bilibili.com/video/BV1bs4y1v7eq/