2.HDFS基础_工作原理

一.HDFS基础概念

1.NameNode和DataNodes

HDFS具有主/从架构。HDFS集群由单个NameNode，管理文件系统命名空间的主服务器和管理客户端对文件的访问组成。此外，还有许多DataNode，通常是群集中每个节点一个，用于管理连接到它们运行的​​节点的存储。HDFS公开文件系统命名空间，并允许用户数据存储在文件中。在内部，文件被分成一个或多个块，这些块存储在一组DataNode中。

• NameNode：执行文件系统命名空间操作，如打开，关闭和重命名文件和目录。它还确定了块到DataNode的映射。
• DataNode：负责提供来自文件系统客户端的读写请求。DataNodes还执行块创建，删除。

2.文件系统命名空间

HDFS支持传统的分层文件组织。用户可以在这些目录中创建目录并存储文件。文件系统命名空间层次结构与大多数其他现有文件系统类似; 可以创建和删除文件，将文件从一个目录移动到另一个目录，或重命名文件。HDFS尚未实现用户配额或访问权限。HDFS不支持硬链接或软链接。但是，HDFS架构并不排除实现这些功能。

NameNode维护文件系统名称空间。NameNode记录对文件系统命名空间或其属性的任何更改。我们可以指定HDFS维护的文件的副本数，文件的副本数称为该文件的复制因子，该信息由NameNode存储。

3.数据复制

HDFS旨在跨大型集群中的计算机可靠地存储非常大的文件。它将每个文件存储为一系列块， 除最后一个块之外的文件中的所有块都具有相同的大小。复制文件的块以实现容错，块大小和副本数可根据文件进行配置。副本数可以在文件创建时指定，并可以在以后更改。HDFS中的文件是一次写入的，并且在任何时候都只有一个写入器。

NameNode决定块复制的过程，它定期从群集中的每个DataNode接收Heartbeat和Blockreport。收到Heartbeat意味着DataNode正常运行。Blockreport包含DataNode上所有块的列表。

4.副本策略

• 副本放置：数据块副本的放置对HDFS的可靠性和性能至关重要。大型HDFS实例在通常分布在许多机架上的计算机集群上运行。不同机架中两个节点之间的通信必须通过交换机。在大多数情况下，同一机架中的计算机之间的网络带宽大于不同机架中的计算机之间的网络带宽。机架感知副本放置策略的目的是提高数据可靠性，可用性和网络带宽利用率。
• 副本策略：NameNode通过Hadoop Rack Awareness中概述的过程确定每个DataNode所属的机架ID 。对于常见情况，当复制因子为3时，HDFS的放置策略是将一个副本放在本地机架中的一个节点上，另一个放在本地机架中的另一个节点上，将最后一个放在另一个机架中的另一个节点上。此策略可以减少机架间写入流量，从而提高写入性能。机架故障的可能性远小于节点故障的可能性; 此策略不会影响数据可靠性和可用性保证。但是，它确实减少了读取数据时使用的聚合网络带宽，因为块只放在两个唯一的机架而不是三个。使用此策略时，文件的副本不会均匀分布在机架上。三分之一的副本位于一个节点上，三分之二的副本位于一个机架上，另外三个副本均匀分布在剩余的机架上。
• 副本选择：为了最小化全局带宽消耗和读取延迟，HDFS尝试满足最接近读取器的副本的读取请求。如果在与读取器节点相同的机架上存在副本，则该副本首选满足读取请求。如果HDFS集群跨越多个数据中心，则驻留在本地数据中心的副本优先于任何远程副本。

5.安全模式

• 启动时，NameNode进入名为Safemode的特殊状态。此时，不会发生数据块的复制。NameNode从DataNode接收Heartbeat和Blockreport消息，Blockreport包含DataNode的数据块列表。
• 每个块都有指定的最小副本数，当使用NameNode检测完成该数据块的最小副本数时，会认为该块是安全复制的。NameNode检测并确认数据块副本数(确认一定百分比的数据块安全，该百分比是可配置的)安全后，NameNode退出Safemode状态。如果确定仍然具有少于指定数量的副本的数据块列表，NameNode将这些块复制到其他DataNode。

6.机架意识

许多Hadoop组件都具有机架感知功能，并利用网络拓扑结构提高性能和安全性。Hadoop守护程序通过调用管理员配置的模块来获取集群中从站的机架信息。强烈建议在启动HDFS之前配置机架感知。

7.文件系统元数据的持久性

• NameNode存储HDFS的名称空间。NameNode使用EditLog(事务日志)来持久记录文件系统元数据发生的每个更改。例如，在HDFS中创建新文件会导致NameNode将记录插入EditLog。整个文件系统命名空间（包括块到文件和文件系统属性的映射）存储在名为FsImage的文件中。FsImage和EditLog作为文件存储在NameNode的本地文件系统中。
• NameNode在整个内存中保存整个文件系统命名空间和文件Blockmap的映像。此关键元数据项设计为紧凑，因此具有4GB RAM的NameNode足以支持大量文件和目录。当NameNode启动时，它从磁盘读取FsImage和EditLog，将EditLog中的所有事务应用到FsImage的内存中表示，并将此新版本刷新到磁盘上的新FsImage中。然后它可以截断旧的EditLog，因为它的事务已应用于持久性FsImage。此过程称为检查点。在当前实现中，仅在NameNode启动时才会发生检查点。正在开展工作以支持在不久的将来定期检查点。
• DataNode将HDFS数据存储在其本地文件系统中的文件中。DataNode不了解HDFS文件，它将每个HDFS数据块存储在其本地文件系统中的单独文件中。DataNode不会在同一目录中创建所有文件，它使用启发式方法来确定每个目录的最佳文件数，并适当地创建子目录。在同一目录中创建所有本地文件并不是最佳选择，因为本地文件系统可能无法有效地支持单个目录中的大量文件。当DataNode启动时，它会扫描其本地文件系统，生成与每个本地文件对应的所有HDFS数据块的列表，并将此报告发送到NameNode：这是Blockreport。

8.HDFS HA

(1) 背景

在Hadoop 2.0.0之前，NameNode是HDFS集群中的单点故障(SPOF)。每个集群都有一个NameNode，如果该机器或进程变得不可用，整个集群将无法使用，直到NameNode重新启动或在单独的计算机上启动。这在两个主要方面影响了HDFS集群的总体可用性：

• 计划外事件(例如计算机崩溃)，重新启动NameNode之前，集群将不可用。

• 计划维护事件(如NameNode计算机上的软件或硬件升级)将导致群集停机时间窗口。

HDFS高可用功能通过在同一集群中运行两个冗余NameNode来解决问题。这样，在机器崩溃的情况下，可以快速故障转移到新的NameNode，或者为了计划维护，可以进行正常的管理员启动的故障转移。

(2) HA 体系结构

在典型的HA集群中，两台独立的计算机配置为NameNode。在任何时间点，其中一个NameNode处于活动状态，另一个处于待机状态。Active NameNode负责集群中的所有客户端操作，而Standby只是充当从属服务器，维持足够的状态以在必要时提供快速故障转移。

为了使备用节点保持其状态与活动节点同步，当前实现要求两个节点都可以访问共享存储设备上的目录。

当Active节点执行任何名称空间修改时，它会将修改记录持久地记录到存储在共享目录中的编辑日志文件中。Standby节点不断观察此目录以进行编辑，并在查看编辑时将其应用于自己的命名空间。如果发生故障转移，备用数据库将确保在将自身升级为活动状态之前已从共享存储中读取所有编辑内容。这可确保在发生故障转移之前完全同步命名空间状态。

为了提供快速故障转移，备用节点还必须具有关于集群中块的位置的最新信息。为了实现这一点，DataNode配置了两个NameNode的位置，并向两者发送块位置信息和心跳。

对于HA集群的正确操作而言，一次只有一个NameNode处于活动状态至关重要。否则，命名空间状态将在两者之间快速分歧，冒着数据丢失或其他不正确结果的风险。为了确保此属性并防止所谓的“脑裂情景”，管理员必须为共享存储配置至少一种防护方法。在故障转移期间，如果无法验证先前的活动节点是否已放弃其活动状态，则防护进程负责切断先前Active对共享编辑存储的访问。这可以防止它对命名空间进行任何进一步的编辑，从而允许新的Active安全地进行故障转移。

二.HDFS读写流程

1.基本架构

HDFS是一个主从式结构，HDFS集群中有一个NameNode和一些DataNodes。NameNode管理文件的元数据，DataNode存储实际的数据。从用户的角度看，就像操作传统的文件系统一样，可以通过目录路径对文件执行创建、读取、删除操作。客户端联系NameNode来获取元数据信息，而真正的文件I/O是直接和DataNode进行交互的。

2.HDFS读流程

• 第一步：Client向NameNode发送数据请求后，寻找数据对应的数据块的位置信息。
• 第二步：NameNode返回文件对应的数据块元数据信息，如所属机器、数据块的block_id、数据块的先后顺序等。
• 第三步：由Client与DataNode直接通信，读取各个block数据块的信息。过程为并行读取，由客户端合并数据。

3.HDFS写流程

• 第一步：客户端向数据写入HDFS文件时，其数据首先写入本地文件。当本地文件累积完整的用户数据块时，客户端从NameNode检索DataNode列表(此列表包含即将存储该块副本的DataNode，即：该副本应该存放在的机器节点)。NameNode返回给客户端该Block及其副本存放的DataNode。
• 第二步：客户端将数据块刷新到第一个DataNode。第一个DataNode开始以Package(数据包)的形式接收数据，写入其本地存储库并将该部分传输到列表中的第二个DataNode。第二个DataNode又开始接收数据块的每个部分，将该部分写入其存储库，然后将该部分刷新到第三个DataNode。最后，第三个DataNode将数据写入其本地存储库。从而，DataNode可以从管道中的前一个数据接收数据，同时将数据转发到管道中的下一个数据。
• 第三步：等所有的Block数据块都写完后，客户端收到DataNode所有写入完成的ack应答。客户端告诉NameNode，写入完成，关闭socket流。

4.Check Point过程

Secondary NameNode不是NameNode的备份。它的作用是：定期合并fsimage与edits文件，并推送给NameNode，以及辅助恢复NameNode。

• secondary namenode请求主Namenode停止使用edits文件，暂时将新的写操作记录到一个新文件中，如edits.new。 
• secondary namenode节点从主Namenode节点获取fsimage和edits文件（采用HTTP GET） 
• secondary namenode将fsimage文件载入到内存，逐一执行edits文件中的操作，创建新的fsimage文件 
• secondary namenode将新的fsimage文件发送回主Namenode（使用HTTP POST） 
• Namenode节点将secondary namenode节点接收的fsimage文件替换旧的fsimage文件，用步骤1产生的edits.new文件替换旧的edits文件，同时更新fstime文件来记录检查点执行的时间。

随着Hadoop版本升级，Secondary NameNode逐渐被CheckpointNode和BackupNode替代。 

• CheckpointNode：与Secondary NameNode的作用一致。 
• BackupNode：NameNode的完全备份。 

三.HDFS文件目录

1.NameNode

NameNode文件结构包含edits、fsimage、seen_txid、VERSION。

(1) edits

• 编辑日志(edit log)：当客户端执行写操作时，首先NameNode会在编辑日志中写下记录，并在内存中保存一个文件系统元数据，这个描述符会在编辑日志改动之后更新。
• edits_start_transaction_id-end_transaction_id(最终编辑日志)：HA环境中，Standby Namenode只能读取这些日志文件。
• edits_inprogress_start_transaction_id：当前正在被追加的edit log，HDFS默认会为该文件提前申请1MB空间以提升性能。

(2) fsimage

• 文件系统镜像(fsimage)：文件系统元数据的持久检查点，包含以序列化格式存储的文件系统目录和文件inodes，每个inodes表示一个文件或目录的元数据信息以及文件的副本数、修改和访问时间等信息。
• fsimage_end_transaction_id：每次checkpointing(合并所有edits到一个fsimage的过程)产生最终的fsimage同时，会生成一个.md5的文件用来对文件做完整性校验。

(3) seen_txid

• seen_txid是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾数，namenode重启的时候，会按照seen_txid的数字，循序从头跑edits_0000001~到seen_txid的数字。
• 当hdfs发生异常重启的时候，一定要比对seen_txid内的数字是不是你edits最后的尾数。不然会发生创建namenode的metaData时，元数据有缺少，导致误删Datanode上多余Block。

(4) VERSION

VERSION文件是java属性文件，保存了HDFS的版本号。

• namespaceID是文件系统的唯一标识符，是在文件系统初次格式化时生成的
• clusterID是系统生成或手动指定的集群ID 
• cTime表示NameNode存储时间的创建时间，升级后会更新该值
• storageType表示此文件夹中保存的是元数据节点的数据结构
• blockpoolID：针对每一个Namespace所对应blockpool的ID,该ID包括了其对应的NameNode节点的ip地址
• layoutVersion是一个负整数，保存了HDFS的持续化在硬盘上的数据结构的格式版本号

(5) in_use.lock

防止一台机器同时启动多个Namenode进程导致目录数据不一致。

2.DataNode

DataNode文件结构主要由blk_前缀文件、BP-random_integer-namenode_ip-address_creation_time和VERSION构成。

(1) BP-random integer-NameNode-IP address-creation time

BP代表BlockPool，即：Namenode VERSION中集群唯一blockpoolID。

(2) finalized/rbw

• 这两个目录都是用于实际存储HDFS BLOCK的数据，里面包含许多block_xx文件以及相应的.meta文件，.meta文件包含了checksum信息。
• rbw是“replica being written”的意思，该目录用于存储用户当前正在写入的数据。

(3) blk_前缀文件

• HDFS中的文件块本身，存储的是文件内容。

• 块的元数据信息(使用.meta后缀标识)。一个文件块由存储的原始文件字节组成，元数据文件由一个包含版本和类型信息的头文件和一系列块的区域校验和组成。

• 注：当目录中存储的块数据量增加到一定规模时，DataNode会创建一个新的目录，用于保存新的块及元数据。当目录中的块数据量达到64（可由dfs.DataNode.numblocks属性确定）时，便会新建一个子目录，这样就会形成一个更宽的文件树结构，避免了由于存储大量数据块而导致目录很深，使检索性能免受影响。通过这样的措施，数据节点可以确保每个目录中的文件块都可控的，也避免了一个目录中存在过多文件。

(4) VERSION

• storageID相对于DataNode来说是唯一的，用于在NameNode处标识DataNode 
• clusterID是系统生成或手动指定的集群ID 
• cTime表示NameNode存储时间的创建时间 
• datanodeUuid表示DataNode的ID号 
• storageType将这个目录标志位DataNode数据存储目录
• layoutVersion是一个负整数，保存了HDFS的持续化在硬盘上的数据结构的格式版本号

(5) in_use.lock

防止一台机器同时启动多个Datanode进程导致目录数据不一致。

3.SecondaryNameNode

SecondaryNameNode主要包括edits、fsimage、VERSION。

(1) edits

从NameNode复制的日志文件。

(2) fsimage

从NameNode复制的镜像文件。

(3) VERSION

SecondaryNameNode和NameNode的VERSION相同。

(4) in_use.lock

防止一台机器同时启动多个SecondaryNameNode进程导致目录数据不一致。

四.HDFS配置项

官网核心配置项说明：http://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-common/core-default.xml

官网HDFS配置项说明：http://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/hdfs-default.xml

官网HDFS HA手动故障转移配置：http://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html#Deployment

官网HDFS HA自动故障转移配置：http://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html#Automatic_Failover