HDFS集群在数据管理方面地位突出，不过其元数据管理、节点维护等环节，确实令人既依赖又头疼，接下来就详细谈谈这些内容。

元数据读取需求

在标准的HDFS系统中，数据的读写活动非常活跃，其中读操作更为常见。每次读取数据时，都需要向NameNode查询相关资料，例如索引数据这类信息，它们在运行中的集群里被频繁访问且要求快速响应。为了确保效率，这些资料必须存储在内存空间。试想一下，成千上万条数据请求接连不断地发送过来，如果没有迅速的资料检索能力，这个系统很可能会陷入停滞状态。

元数据的保存和运用维护也需及时跟进，否则会降低整个团队的资料处理能力。

hdfs oiv -p XML -i 查看fsimage文件的文件名 -o 输出到哪里
hdfs oiv -p XML -i fsimage_0000000000000001153 -o /opt/module/hadoop-3.1.3/fsimage.xml

编辑日志的作用

sz fsimage.xml 
sz edits.xml 

NN只负责保存数据，将记录元数据的信息保存到硬盘中，产生一个编辑记录文件。这个文件详细记录了每个使用者进行的所有改动，因此显著减轻了写入负担。这好比在交通繁忙的路段设置分流，让数据写入过程变得更为顺畅。

不过，随着使用次数增多，日志文件会变得异常庞大，达到几十TB的规模，但与之相比，元数据几乎没有增长，这就造成了新的问题。

2NN的诞生

TimeOut = 2 * dfs.namenode.heartbeat.recheck-interval + 10 * dfs.heartbeat.interval
                  默认5分钟                                        默认30s

NN的持续运行和启动要求存在差异，因此产生了2NN。2NN每隔一定时间，比如上一轮合并过去一个小时，或者edits记录数量累积到100万次——这个时间间隔可以自行设定——就会去合并edits.log文件。合并操作期间，NN不会中断服务，2NN在后台悄悄完成工作。

sudo hostnamectl --static set-hostname hadoop104

组合完毕后，2NN会将整合好的文档借助TCP协议传送给NN。它仿佛一个不知疲倦的帮手，总是在无声中支持着整个团队的稳定运作。

sudo rsync -av /opt/module/ hadoop104:/opt/ 

2NN不能做热备的原因

rm -rf data logs edits.xml fsimage.xml

NN在把edits.log传给2NN的同时，自身并未停止操作，还会不断生成新的edits.log文件。因此，2NN收到的文件版本总是滞后的，无法提供最新的数据。这样一来，2NN就不能充当NN的即时备份角色。尽管存在一套配置相似的服务器，但无法实现热备功能，确实显得有些资源闲置了。

这也表明，在群体构建和维护方面，热备份等操作的实施仍需更周密的计划。

sudo rsync -av /etc/profile.d hadoop104:/etc

块位置信息的处理

HDFS仅记录文件分布的块信息，却未标明这些块存储在哪些数据节点上。集群启动后，会加载相关数据，但加载完毕仍无法确定块数据的具体位置。为此，数据节点需要主动向名称节点汇报自己存储的块信息，名称节点再将这些块信息进行汇总，从而保障文件系统的高效运作。

hadoop version
java -version

这个操作是在安全状态下执行的，必须所有数据都完全正确，系统集群才能正常运作。

hdfs --daemon start datanode

节点退役管理

淘汰的单元需要采用排除法，这样才能防止信息遗失。单元在停止运行期间，会将保留的内容复制到其他单元里面去，这个操作叫做资料转移。一旦资料复制结束，单元的处境就转变为退出服务。

yarn --daemon start nodemanager

如果从允许列表里移除某个点，很有可能会让资料不见，因此还是得依照正规方法来。

各位在运用HDFS集群的过程中，还有哪些难题让大家感到困扰？欢迎在下方留言讨论，同时别忘了给这篇文章点赞和转发。

cd /opt/module/hadoop-3.1.3/etc/hadoop/
vim workers