hadoop之hdfs基本概念

首先说明一点就是我们这里凡是关键字都用英文原文表示，以表示其准确性

NameNode和DataNodes

 

1. NameNode是一个中心服务器，单一节点（简化系统的设计和实现），负责管理文件系统的名字空间（namespace）以及客户端对文件元数据的相关操作
2. datanode负责我们块数据的读取和写入操作

数据块

HDFS旨在支持非常大的文件。与HDFS兼容的应用程序是处理大型数据集的应用程序。这些应用程序只编写一次数据，但是它们读取一次或多次，并要求在流速下满足这些读取。HDFS支持文件上的一次写入多次读取。HDFS使用的典型块大小为128MB。因此，HDFS文件被切割成128MB块，如果可能，每个块将驻留在不同的DataNode上。

 

 

数据的备份

HDFS旨在跨大型集群中的计算机可靠地存储非常大的文件。它将每个文件存储为一系列的块;除最后一个块之外的文件中的所有块都具有相同的大小。复制文件的块以实现容错。

Namenode管理所有的块数据，Namenode通过定期接受datanode发送过来的两种机制一种是心跳检测机制一种是块报告(Blockreport)来操作datanode，收到Heartbeat意味着DataNode正常运行，Blockreport包含DataNode上所有块的列表。用于构建datanode与块id的映射关系。见下表：

文件系统元数据的持久化（standalone）

 

HDFS名称空间由NameNode存储。NameNode使用名为EditLog的事务日志来持久记录文件系统元数据发生的每个更改。例如，在HDFS中创建新文件会导致NameNode将记录插入EditLog，以指示此情况。同样，更改文件的元数据也还会导致将新记录插入EditLog。NameNode使用其本地主机操作系统的文件系统中的文件来存储EditLog。整个文件系统命名空间（包括块到文件和文件系统属性的映射）都存储在名为FsImage的文件中。FsImage也作为文件存储在NameNode的本地文件系统中。

 

NameNode在内存中保存整个文件系统命名空间和file Blockmap的映像。此关键元数据项设计非常紧凑，因此具有4 GB RAM的NameNode足以支持大量文件和目录。当NameNode启动时，它从磁盘读取FsImage和EditLog，以FsImage中的数据构建元数据，将EditLog中的所有事务应用到FsImage的内存中刷新文件结构，并将此新版本的文件系统刷新到磁盘上的新FsImage中。然后它可以截断旧的EditLog，因为它的事务已应用于持久性FsImage。此过程称为checkpoint（检查点）。在当前实现中，仅在NameNode启动时才会发生检查点。

 

DataNode将HDFS数据存储在其本地文件系统中的文件中。DataNode不了解HDFS文件。它将每个HDFS数据块存储在其本地文件系统中的单独文件中。DataNode不会在同一目录中创建所有文件。相反，它使用heuristic(启发式)方法来确定每个目录的最佳文件数，并适当地创建子目录。在同一目录中创建所有本地文件并不是最佳选择，因为本地文件系统可能无法有效地支持单个目录中的大量文件。当DataNode启动时，它会扫描其本地文件系统，生成与每个本地文件对应的所有HDFS数据块的列表，并将此报告发送到NameNode,这个操作就是上面提到的Blockreport。这样，namenode就可以构建block与datanode的映射关系了。

Secondary NameNode

那么secondary namenode的出现又是为了解决什么为题呢？通过上一节我们知道NameNode将对文件系统的修改存储本机文件系统文件的EditLog中。当NameNode启动时，它从本地文件系统中的fsimage读取HDFS，然后从EditLog文件中合并更新文件系统。然后它将新的HDFS状态写入fsimage并使用空的EditLog文件开始正常工作。由于NameNode仅在启动期间合并fsimage和EditLog文件，我们可以想象EditLog文件在繁忙的群集上可能会随着时间的推移而变得非常大。较大的EditLog文件的另一个副作用是下次重新启动NameNode需要更长的时间（合并大的EditLog和fsimage的工程非常漫长）。

secondary namenode的作用就是定期合并fsimage和EditLog文件，并使EditLog文件大小保持在限制范围内。它通常在与主NameNode不同的机器上运行，因为它的内存要求与主NameNode的相同。

我们可以在core-site.xml中设置多长时间进行一次以及文件多大后进行合并。

dfs.namenode.checkpoint.period  默认1小时执行一次

dfs.namenode.checkpoint.txns

secondarynameNode如何辅助管理FSImage与Edits文件

①：secnonaryNN通知NameNode切换editlog
②：secondaryNN从NameNode中获得FSImage和editlog(通过http方式)
③：secondaryNN将FSImage载入内存，然后开始合并editlog，合并之后成为新的fsimage
④：secondaryNN将新的fsimage发回给NameNode
⑤：NameNode用新的fsimage替换旧的fsimage

安全模式

启动时，NameNode进入一个名为Safemode的特殊状态。当NameNode处于Safemode状态时，不会发生数据块的复制。NameNode从DataNode接收Heartbeat和Blockreport消息。Blockreport包含DataNode托管的数据块列表。每个块都有指定的最小副本数。当使用NameNode检查入datanode中的副本数等于该数据块的最小副本数时，会认为该块是安全的。当到达可配置百分比的安全数据块再加上30秒后，NameNode退出Safemode状态。然后，他进行损坏数据块的重新备份工作。

 

数据的写入

创建文件的客户端请求不会立即到达NameNode。实际上，最初HDFS客户端将文件数据缓存到临时本地文件中。应用程序写入被透明地重定向到此临时本地文件。当本地文件累积超过一个HDFS块大小的数据时，客户端将联系NameNode。NameNode将文件名插入文件系统层次结构并为其分配数据块。NameNode使用DataNode和目标数据块的标识响应客户端请求。然后，客户端将数据块从本地临时文件刷新到指定的DataNode。关闭文件时，临时本地文件中剩余的未刷新数据将传输到DataNode。然后客户端告诉NameNode文件已关闭。在此刻，NameNode将文件创建操作提交到持久性存储中。如果NameNode在文件关闭之前死亡，则文件将丢失。

 

在仔细考虑了在HDFS上运行的目标应用程序之后，采用了上述方法。这些应用程序需要流式写入文件。如果客户端直接写入远程文件而没有任何客户端缓冲，则网络速度和网络拥塞会大大影响吞吐量。这种方法并非没有先例。早期的分布式文件系统（例如AFS）使用客户端缓存来提高性能。POSIX要求已经放宽，以实现更高的数据上传性能。

 

备份时的复制流水线

当客户端将数据写入HDFS文件时，其数据首先写入本地文件，如上所述。假设HDFS文件的复制因子为3。当本地文件累积完整的用户数据块时，客户端从NameNode检索DataNode列表。此列表包含将承载该块副本的DataNode。然后，客户端将数据块刷新到第一个DataNode。第一个DataNode开始以小部分接收数据，将每个部分写入其本地存储库并将该部分传输到列表中的第二个DataNode。第二个DataNode又开始接收数据块的每个部分，将该部分写入其存储库，然后将该部分刷新到第三个DataNode。最后，第三个DataNode将数据写入其本地存储库。从而，DataNode可以从管道中的前一个数据接收数据，同时将数据转发到管道中的下一个数据。因此，数据从一个DataNode流水线到下一个DataNode。如下图：

 

数据的读取依然

 

关于垃圾回收站

当用户或应用程序删除文件时，不会立即从HDFS中删除该文件。而是将其移动到/ trash目录中。只要文件保留在/ trash中，文件就可以快速恢复。文件保留在/ trash中的时间是可以配置的。我们可以在

core-site.xml的fs.trash.interval属性中配置有效时间，0代表立即删除。

总结：

好了，有了这个些概念我们就可以讲解High Availability和Federation的相关概念了。