在阅读Hadoop:The Definitive Guide一书时,我遇到了这个page,其中包含以下内容:
namenode还知道给定文件的所有块所在的datanode,但是,它不会持久存储块位置,因为此信息是在系统启动时从数据节点重建的。
我很难理解这是如何运作的。假设我在复制因子为3的8节点集群上复制1 GB文件。因此每个数据节点将有1个块,这些块将在其他节点上复制,使每个节点上的块总数有效地达到3现在,namenode应该保留一个包含每个块位置的索引。但根据文本,如果namenode不存储块位置持久,那么在关闭并重新启动集群后它们是如何重建的。将无法分辨哪个块属于哪个文件。有人可以向我解释一下吗?
答案 0 :(得分:2)
namenode确实保留了一些关于文件的状态(名称,路径,大小,块大小,块ID等),而不是块的位置的物理位置。
当数据节点启动时,它们实际上树遍历dfs数据目录,发现它们拥有的所有文件块,一旦完成,就向名称节点报告它所承载的块。
namenode构建一个文件映射,以阻止来自每个数据节点的报告中的位置。
这是群集首次启动时有时需要几分钟才能退出安全模式的原因之一 - 如果您有大量文件,则每个数据节点可能需要一些时间才能进行树步行和发现它所拥有的街区。
答案 1 :(得分:-1)
每个fsimage文件都包含文件系统中所有目录和文件inode的序列化形式。每个inode都是文件或目录元数据的内部表示,包含文件的复制级别,修改和访问时间,访问权限,块大小以及文件组成块等信息。对于目录,存储修改时间,权限和配额元数据.fsimage文件不记录存储块的数据节点。相反,namenode将这个映射保留在内存中,它通过在数据节点加入集群时询问它们的块列表来构造,然后定期地确定namenode的块映射是最新的。