一个比较常见的原因是因为多次执行：hadoop namenode -format导致的
在这个上面本人也踩过坑，所以想整理一下，做个记录。
本人搭建的环境是在虚拟机上创建三个slave节点和一个master节点，正常情况下，在第一次搭建环境成功后，都需要执行一次：hadoop namenode -format来格式化HDFS，执行一次是没有什么问题的，但是执行多次就会出问题了，问题就出在namenode节点的VERSIOLN和datanode节点的VERSION不一致，导致namenode节点无法找到datanode节点，也就无法管理和启动它了。下面用实验结果来说话
先说一下VERSION所在的位置吧，在搭建hadoop环境的时候，肯定都配置过hdfs-site.xml这个文件，我们会在里面配置这两项：
<property>
<name>dfs.namenode.name.dir</name>
<value>file:/usr/local/hadoop/hadoop_data/hdfs/namenode</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>file:/usr/local/hadoop/hadoop_data/hdfs/datanode</value>
</property>也就是datanode和namenode节点的数据存放位置，打开你配置的这个路径，下面有一个current文件夹。
VERSION就是存放在这个路径下面。先来看一下namenode节点中VERSION文件里的内容
再来看看datanode节点中VERSION文件里的内容
可以注意到，两个VERSION文件中都有同一个属性：clusterID，集群ID
没错，就是这个，在正常情况下，namenode节点VERSION中的clusterID的值是和所有datanode节点VERSION中的clusterID的值是相同的。
只有这样，namenode节点才可以找到所有的datanode节点并进行管理（包括启动，停止等）
所以当你的datanode节点无法启动时，可以查一下，VERSION中的clusterID值，如果发现不一致，那就把namenode节点的clusterID替换datanode中的clusterID值即可。
接下来深入了解下执行：hadoop namenode -format和clusterID之间的关联？？
正常情况下，namenode节点和datanode节点的clusterID值是一致的
现在在namenode节点上执行：hadoop namenode -format，格式化namenode节点的内容，可以看到，执行该语句后，namenode节点的VERSION中的内容发生了改变。
clusterID=CID-b65439d2-4e32-4bd8-b8c0-03bc89022fd8
cTime=0
storageType=NAME_NODE
blockpoolID=BP-1181498708-192.168.56.100-1504924045753
layoutVersion=-60可以看到，有三个值发生了变化，分别是namespaceID，clusterID和blockpoolID
所以每次执行hadoop namenode -format时，会改变namenode节点的VERSION中的namespaceID，clusterID和blockpoolID的值，还会清空hdfs中的内容。
下面来理解一下这三个值代表的含义
–>namespaceID，标识了所格式化的最新namenode的版本。
–>clusterID，集群ID，每次格式化都会更新，所有datanode的clusterID必须和namenode保持一致才会被namenode管理（包括启动，停止等）
–>blockpoolID，块管理池ID
哦，还有一个需要注意的地方：当datanode和namenode的clusterID不一致时，不能用datanode的clusterID去替换namenode的clusterID值，我测试过了，这样是不行的，只能用namenode的clusterID去替换datanode的clusterID值
原因可能是namenode节点每次更新的namespaceID，clusterID之间存在一种关联，改了clusterID，就破坏了这种关联，导致namenode无法启动。
所以说，只能去修改datanode节点的clusterID，让它和namenode节点的保持一致
果然，修改datanode节点的clusterID，让它和namenode节点的保持一致，启动完全成功。
