HDFS是Hadoop抽象的文件系统概念的一个实现。
适用场景适用于大型商用机集群，流式数据访问模式来存储超大文件。
特征1、超大文件。
2、流式数据访问。HDFS的构建思路是，一次写入，多次读取是最高效的访问模式。数据集通常由数据源生成或从数据源复制而来，接着长时间在此数据集上各种分析，每次分析涉及该数据集的大部分数据甚至全部，因此读取整个数据集的时间延迟比读取第一条记录的时间延迟更重要。
3、商用硬件（各种零售店都能买到的普通硬件）。Hadoop不需要运行在昂贵且高可靠的硬件上。
4、不适用低延迟的数据访问。HDFS是为高数据吞吐量应用优化的，这可能会以提高时间延迟为代价。对于低延迟的访问需求，Hbase是更好的选择。
5、不适用大量的小文件。由于namenode将文件系统的元数据存储在内存中，该文件系统所能存储的文件总数受限于namenode的内存容量。
6、不适用多用户写入，任意修改文件，HDFS的文件可能只有一个writer，而且写操作总是将数据添加在文件的末尾，不支持在文件的任意位置进行修改。
每个磁盘都有默认的数据块大小，是磁盘进行读/写的最小单位。
构建于单个磁盘之上的文件系统是通过磁盘块来管理该文件系统中的块，该文件系统块的大小可以是磁盘块的整数倍。
与单一磁盘上的文件系统相似，HDFS上的文件也被划分为块大小的多个分块，作为独立的存储单元(从2.7.3版本开始block size的默认大小为128M，之前版本的默认值是64M。)但与其他文件系统不同的是，HDFS中小于块大小的文件不会占据整个块的空间。
①HDFS的块比磁盘的块大，其目的是为了最小化寻址开销。如果块设置得足够大，从磁盘传输的数据会明显大于定位这个块开始位置所需的时间。因此传输一个由多个块组成的文件的时间取决于磁盘传输速率。
②但是不能设置过大，MapReduce任务通常一次只处理一个块中的数据，因此如果任务数太少（少于集群中的节点的数量），作业的运行速度就会比较慢。
①一个文件的大小可以大于网络中任意一个磁盘的容量
②大大简化了存储子系统的设计，简化是所有系统的目标，这对于故障种类繁多的分布式系统来说尤为重要。将存储子系统控制单元设置为块(由于块的大小是固定的，因此计算单个磁盘上能存储多少个块就相对容易)。
③块适合用于数据备份(默认是3个)进而提高数据容错能力和提高可用性，HDFS中fsck指令可以显示块信息，即文件系统中各个文件由哪些块构成。
HDFS集群由两类节点以管理者-工作者模式运行。即一个namenode(管理者)多个datanode(工作者)。
①namenode管理文件系统的命名空间。它维护着文件系统树及整棵树内的所有文件和目录。这些信息以两个文件形式永久保存在本地磁盘上：命名空间镜像文件和编辑日志文件。namenode也记录着每个文件中各个块所在的数据节点信息，但它并不永久保存块的位置信息，因为这些信息会在系统启动时由数据节点重建。
②客户端(client)代表用户通过namenode与datanode交互来访问整个文件系统。
③datanode是文件系统的工作节点。它们根据需要存储并检索数据块（受客户端或namenode调度），并定期向namenode发送它们所存储的块的列表。
①第一种机制是备份那些组成文件系统元数据持久状态的文件。Hadoop通过配置，即将持久状态写入本地磁盘的同时，写入一个远程挂载的网络文件系统（NFS）
②第二种机制是运行一个辅助namenode，作用是定期通过编辑日志合并命名空间镜像，以防止编辑日志过大。这个辅助namenode一般在另一台单独的物理计算机上，因为它需要占用大量CPU时间与namenode相同容量的内存来执行合并操作，并保存合并后的命名空间镜像的副本，并在namenode发生故障时启用。但是，辅助namenode总是滞后于主节点，所以主节点全部失效时，难免会丢失部分数据。在这种情况下，一般把存储在NFS的namenode元数据复制到辅助namenode并作为新的namenode运行。
namenode在内存中保存文件系统中每个文件和每个数据块的引用关系。这意味着对于一个拥有大量文件的超大集群而言，内存将成为限制系统横向扩展的瓶颈。在2.x发行版本系列中引入的联邦HDFS运行系统通过添加namenode实现扩展，其中每个namenode管理文件系统命名空间中的一部分。例如一个namenode可能管理/user目录下的所有文件，而另一个namenode可能管理/share目录下的所有文件。每个namenode维护一个命名空间卷(namespace volume)，包括命名空间的元数据和在该命名空间下的文件的所有数据块的数据块池。命名空间卷之间是相互独立的，两两之间并不相互通信。数据块池不再进行切分，因此集群中的datanode需要注册到每个namenode，并且存储来自多个数据块池的数据块。
HDFS的高可用性。活动-备用(active-standby)①namenode之间需要通过高可用的共享存储实现编辑日志的共享。当备用namenode接管工作之后，它将通读共享编辑日志直至末尾，以实现与活动namenode的状态同步。
②datanode需要同时向两个namenode发送数据块处理报告，因为数据块的映射信息存储在namenode的内存中，而非磁盘。
③客户端需要使用特定的机制来处理namenode的失效问题，这一机制对用户是透明的。
这样一来，当活动namenode失效之后，备用namenode能够快速实现任务接管。如果在活动namenode失效且备用namenode也失效的情况下，管理员依旧可以申请一个备用namenode并实现冷启动。
一个称为故障转移控制器(failover_controller)的系统中有一个新实体管理着将活动namenode转移为备用namenode的转换过程。故障转移控制器是可插拨的，但其最初的实现是基于Zookeeper的并由此确保有且仅有一个活动namenode。每一个namenode运行着一个轻量级的故障转移控制器，其工作就是监视宿主namenode是否失效(通过一个简单的心跳机制实现)并在namenode失效时进行故障切换。
①管理员手动发起故障转移，称为“平稳的故障转移”，因为故障转移控制器可以组织两个namenode有序切换。
②在非故障转移的情况下，无法确定失效的namenode是否已经停止运行。但是在网速非常慢等情况下，也可能激发故障转移。为防止危害系统导致系统崩溃、脑裂等情况，进行“规避”，规避机制包括杀死namenode进程，收回访问共享存储目录的权限，通过远程管理命令屏蔽相应网络端口。诉诸的最后手段是，先前活动节点STonITH(shoot the other node in the head)的技术进行规避，该方法主要通过一个特定的供电单元对相应主机进行断电操作。
③客户端的故障切换通过客户端类库实现透明处理。最简单的实现是通过客户端的配置文件实现故障切换的控制。HDFS URI使用一个逻辑主机名，该主机名映射到一对namenode地址(在配置文件中设置)，客户端类库会访问每一个namenode地址直至处理完成。
①fs.default.name(core-sit.xml中)：设置为hdfs://localhost/，用于设置Hadoop的默认文件系统。文件系统由URI指定的，这里使用hdfs URI来配置HDFS为Hadoop的默认文件系统。HDFS的守护程序通过该属性项来确定HDFS namenode的主机及端口。我们将在localhost默认端口8020上运行namenode。HDFS客户端也可以通过该属性得知namenode在哪里运行进而连接到它。
②dfs.replication：如果设置为1，则HDFS就不会按默认设置将文件系统块复本设为3。在单独一个datanode上运行时，HDFS无法将块复制到3个datanode上，所以会持续给出块复本不足的警告，设置该属性之后，就不会再有问题了。
针对文件和目录，HDFS的权限模式与POSIX非常相似，分为三类权限模式。
只读权限®：读取文件、列出目录
写入权限(w)：写入文件或是在一个目录上新建及删除文件或目录
执行权限(x)：访问一个目录的子项，对于文件，该权限可以忽略
