2024年10月namenode（理解NameNode）

　　⑴namenode（理解NameNode

　　⑵理解NameNode

　　⑶NameNode主要是用来保存HDFS的元数据信息，比如命名空间信息，块信息等。当它运行的时候，这些信息是存在内存中的。但是这些信息也可以持久化到磁盘上。

　　⑷上面的这张图片展示了NameNode怎么把元数据保存到磁盘上的。这里有两个不同的文件：

　　⑸fsimage-它是在NameNode启动时对整个文件系统的快照

　　⑹editlogs-它是在NameNode启动后，对文件系统的改动序列

　　⑺只有在NameNode重启时，editlogs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在产品集群中NameNode是很少重启的，这也意味着当NameNode运行了很长时间后，editlogs文件会变得很大。在这种情况下就会出现下面一些问题：

　　⑻editlogs文件会变的很大，怎么去管理这个文件是一个挑战。

　　⑼NameNode的重启会花费很长时间，因为有很多改动要合并到fsimage文件上。

　　⑽如果NameNode挂掉了，那我们就丢失了很多改动因为此时的fsimage文件非常旧。

　　⑾因此为了克服这个问题，我们需要一个易于管理的机制来帮助我们减小editlogs文件的大小和得到一个最新的fsimage文件，这样也会减小在NameNode上的压力。这跟Windows的恢复点是非常像的，Windows的恢复点机制允许我们对OS进行快照，这样当系统发生问题时，我们能够回滚到最新的一次恢复点上。

　　⑿现在我们明白了NameNode的功能和所面临的挑战-保持文件系统最新的元数据。那么，这些跟SecondaryNameNode又有什么关系呢？

　　⒀SecondaryNameNode

　　⒁SecondaryNameNode就是来帮助解决上述问题的，它的职责是合并NameNode的editlogs到fsimage文件中。

　　⒂上面的图片展示了SecondaryNameNode是怎么工作的。

　　⒃首先，它定时到NameNode去获取editlogs，并更新到fsimage上。

　　⒄一旦它有了新的fsimage文件，它将其拷贝回NameNode中。

　　⒅NameNode在下次重启时会使用这个新的fsimage文件，从而减少重启的时间。

　　⒆SecondaryNameNode的整个目的是在HDFS中提供一个检查点。它只是NameNode的一个助手节点。这也是它在社区内被认为是检查点节点的原因。

　　⒇现在，我们明白了SecondaryNameNode所做的不过是在文件系统中设置一个检查点来帮助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的备份。所以从现在起，让我们养成一个习惯，称呼它为检查点节点吧。

　　⒈【Hadoop生产调优】之NameNode内存配置

　　⒉Hadoop中的Namenode所在的服务器，根据配置不同，内存一般为G，Namenode记录一个文件块大致需要B，通过下面的计算可知，Namenode为G内存的Hadoop集群最多可以保存.亿个文件。刨除Linux系统、应用、任务等，实际上namenode不可能独占所有的内存资源，所以我们在生产环境，需要设置namenode的内存值。在hadoop-env.sh文件中，通过HADOOP_NAMENODE_OTPS=-Xmxm，我们可以配置namenode所占的内存资源。经上面配置后，我们来验证一下配置是否生效，执行jps命令，查看当前java进程。在执行jmap-heap命令，分别查看datanode和namenode的内存值。

　　⒊NameNodeHA实现原理

　　⒋前言：在Hadoop.x版本，HDFS集群的NameNode一直存在单点故障问题：集群只存在一个NameNode节点，它维护了HDFS所有的元数据信息，当该节点所在服务器宕机或者服务不可用，整个HDFS集群都将处于不可用状态，极大限制了HDFS在生产环境的应用场景。直到Hadoop.版本才提出了高可用(HighAvailability,HA)解决方案，并且经过多个版本的迭代更新，已经广泛应用于生产环境。解决方案：在同一个HDFS集群，运行两个互为主备的NameNode节点。一台为主Namenode节点，处于Active状态，一台为备NameNode节点，处于Standby状态。其中只有ActiveNameNode对外提供读写服务，StandbyNameNode会根据ActiveNameNode的状态变化，在必要时切换成Active状态。

　　⒌【NameNodeHA架构图】

　　⒍HealthMonitor定时调用NameNode的HAServiceProtocolRPC接口(monitorHealth和getServiceStatus)，监控NameNode的健康状态并向ZKFC反馈；

　　⒎ActiveStandbyElector接收ZKFC的选举请求，通过Zookeeper自动完成主备选举，选举完成后回调ZKFC的主备切换方法对NameNode进行Active和Standby状态的切换；

　　⒏JouranlNode集群共享存储系统，负责存储HDFS的元数据，ActiveNameNode(写入)和StandbyNameNode(读取)通过共享存储系统实现元数据同步，在主备切换过程中，新的ActiveNameNode必须确保元数据同步完成才能对外提供服务;

　　⒐ZKFailoverController在启动时同时会初始化HealthMonitor和ActiveStandbyElector服务，同时也会向HealthMonitor和ActiveStandbyElector注册相应的回调方法：

　　⒑HealthMonitor检测NameNode的两类状态，HealthMonitor.State和HealthMonitor.HAServiceStatus。在程序上启动一个线程循环调用NameNode的HAServiceProtocolRPC接口的方法来检测NameNode的状态，并将状态的变化通过回调的方式来通知ZKFailoverController。

　　⒒当HealthMonitor检测到NameNode的健康状态或角色状态发生变化时，ZKFC会根据状态的变化决定是否需要进行主备选举。

　　⒓HealthMonitor.State状态变化导致的不同后续措施：

　　⒔HAServiceStatus在状态检测之中仅起辅助的作用，当HAServiceStatus发生变化时，ZKFC会判断NameNode返回的HAServiceStatus与ZKFC所期望的是否相同，如果不相同，ZKFC会调用ActiveStandbyElector的quitElection方法删除当前已经在ZK上建立的临时节点退出主备选举。

　　⒕ZKFC通过ActiveStandbyElector的joinElection方法发起NameNode的主备选举，这个过程通过Zookeeper的写一致性和临时节点机制实现:a.当发起一次主备选举时，Zookeeper会尝试创建临时节点/hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock，Zookeeper的写一致性保证最终只会有一个ActiveStandbyElector创建成功，创建成功的ActiveStandbyElector对应的NameNode就会成为主NameNode，ActiveStandbyElector回调ZKFC的方法将对应的NameNode切换为Active状态。而创建失败的ActiveStandbyElector对应的NameNode成为备NameNode，ActiveStandbyElector回调ZKFC的方法将对应的NameNode切换为Standby状态;

　　⒖b.不管是否选举成功，所有ActiveStandbyElector都会向Zookeeper注册一个Watcher来监听这个节点的状态变化事件;

　　⒗c.如果ActiveNameNode对应的HealthMonitor检测到NameNode状态异常时，ZKFC会删除在Zookeeper上创建的临时节点ActiveStandbyElectorLock，这样处于StandbyNameNode的ActiveStandbyElector注册的Watcher就会收到这个节点的NodeDeleted事件。收到这个事件后，会马上再次创建ActiveStandbyElectorLock，如果创建成功，则StandbyNameNode被选举为ActiveNameNode。

　　⒘【防止脑裂】在分布式系统中脑裂又称为双主现象，由于Zookeeper的“假死”，长时间的垃圾回收或其它原因都可能导致双ActiveNameNode现象，此时两个NameNode都可以对外提供服务，无法保证数据一致性。对于生产环境，这种情况的出现是毁灭性的，必须通过自带的隔离（Fencing机制预防这种现象的出现。ActiveStandbyElector为了实现fencing隔离机制，在成功创建hadoop-ha/dfs.nameservices/ActiveStandbyElectorLock临时节点后，会创建另外一个/hadoop?ha/{dfs.nameservices}/ActiveBreadCrumb持久节点，这个持久节点保存了ActiveNameNode的地址信息。当ActiveNameNode在正常的状态下断开ZookeeperSession(注意由于/hadoop-ha/dfs.nameservices/ActiveStandbyElectorLock是临时节点，也会随之删除)，会一起删除持久节点/hadoop?ha/{dfs.nameservices}/ActiveBreadCrumb。但是如果ActiveStandbyElector在异常的状态下关闭ZookeeperSession，那么由于/hadoop-ha/${dfs.nameservices}/ActiveBreadCrumb是持久节点，会一直保留下来。当另一个NameNode（standy=》active选主成功之后，会注意到上一个ActiveNameNode遗留下来的ActiveBreadCrumb节点，从而会回调ZKFailoverController的方法对旧的ActiveNameNode进行fencing。①首先ZKFC会尝试调用旧ActiveNameNode的HAServiceProtocolRPC接口的transitionToStandby方法，看能否将状态切换为Standby；②如果调用transitionToStandby方法切换状态失败，那么就需要执行Hadoop自带的隔离措施，Hadoop目前主要提供两种隔离措施：sshfence：SSHtotheActiveNameNodeandkilltheprocess；shellfence：runanarbitraryshellmandtofencetheActiveNameNode；只有在成功地执行完成fencing之后，选主成功的ActiveStandbyElector才会回调ZKFC的beeActive方法将对应的NameNode切换为Active，开始对外提供服务。

　　⒙NameNode和SecondaryNameNode工作机制

　　⒚??首先，我们做个假设，如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。??这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新FsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦NameNode节点断电，就会产生数据丢失。因此，引入Edits文件(只进行追加操作，效率很高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到Edits中。这样，一旦NameNode节点断电，可以通过FsImage和Edits的合并，合成元数据。??但是，如果长时间添加数据到Edits中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行FsImage和Edits的合并，如果这个操作由NameNode节点完成，又会效率过低。因此，引入一个新的节点SecondaryNamenode，专门用于FsImage和Edits的合并。??NameNode启动时，先滚动Edits并生成一个空的edits.inprogress，然后加载Edits和Fsimage到内存中，此时NameNode内存就持有最新的元数据信息。Client开始对NameNode发送元数据的增删改的请求，这些请求的操作首先会被记录到edits.inprogress中（查询元数据的操作不会被记录在Edits中，因为查询操作不会更改元数据信息，如果此时NameNode挂掉，重启后会从Edits中读取元数据的信息。然后，NameNode会在内存中执行元数据的增删改的操作。??由于Edits中记录的操作会越来越多，Edits文件会越来越大，导致NameNode在启动加载Edits时会很慢，所以需要对Edits和Fsimage进行合并（所谓合并，就是将Edits和Fsimage加载到内存中，照着Edits中的操作一步步执行，最终形成新的Fsimage。SecondaryNameNode的作用就是帮助NameNode进行Edits和Fsimage的合并工作。??NN首先会询问NN是否需要CheckPoint（触发CheckPoint需要满足两个条件中的任意一个，定时时间到和Edits中数据写满了。直接带回NN是否检查结果。NN执行CheckPoint操作，首先会让NameNode滚动Edits并生成一个空的edits.inprogress，滚动Edits的目的是给Edits打个标记，以后所有新的操作都写入edits.inprogress，其他未合并的Edits和Fsimage会拷贝到NN的本地，然后将拷贝的Edits和Fsimage加载到内存中进行合并，生成fsimage.chkpoint，然后将fsimage.chkpoint拷贝给NameNode，重命名为Fsimage后替换掉原来的Fsimage。NameNode在启动时就只需要加载之前未合并的Edits和Fsimage即可，因为合并过的Edits中的元数据信息已经被记录在Fsimage中。（通常情况下，SecondaryNameNode每隔一小时执行一次。（一分钟检查一次操作次数，当操作次数达到百万时，SecondaryNameNode执行一次。

　　⒛在现代的企业环境中，单机容量往往无法存储大量数据，需要跨机器存储。统一管理分布在集群上的文件系统称为分布式文件系统。

　　HDFS（HadoopDistributedFileSystem是Hadoop的核心组件之一，非常适于存储大型数据(比如TB和PB)，HDFS使用多台计算机存储文件，并且提供统一的访问接口，像是访问一个普通文件系统一样使用分布式文件系统。

　　HDFS是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储，为超大数据集的应用处理带来了很多便利。

　　HDFS具有以下优点：

　　当然HDFS也有它的劣势，并不适合以下场合：

　　HDFS采用Master/Slave的架构来存储数据，这种架构主要由四个部分组成，分别为HDFSClient、NameNode、DataNode和SecondaryNameNode。

　　Namenode是整个文件系统的管理节点，负责接收用户的操作请求。它维护着整个文件系统的目录树，文件的元数据信息以及文件到块的对应关系和块到节点的对应关系。

　　Namenode保存了两个核心的数据结构：

　　在NameNode启动的时候，先将fsimage中的文件系统元数据信息加载到内存，然后根据edits中的记录将内存中的元数据同步到最新状态；所以，这两个文件一旦损坏或丢失，将导致整个HDFS文件系统不可用。

　　为了避免edits文件过大，SecondaryNameNode会按照时间阈值或者大小阈值，周期性的将fsimage和edits合并，然后将最新的fsimage推送给NameNode。

　　并非NameNode的热备。当NameNode挂掉的时候，它并不能马上替换NameNode并提供服务。其主要任务是辅助NameNode，定期合并fsimage和fsedits。

　　Datanode是实际存储数据块的地方，负责执行数据块的读/写操作。

　　一个数据块在DataNode以文件存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据，包括数据块的长度，块数据的校验和，以及时间戳。

　　文件划分成块，默认大小M，以快为单位，每个块有多个副本（默认个存储不同的机器上。

　　Hadoop.X默认M，小于一个块的文件，并不会占据整个块的空间。Block数据块大小设置较大的原因：

　　文件上传HDFS的时候，Client将文件切分成一个一个的Block，然后进行存储。

　　Client还提供一些命令来管理HDFS，比如启动或者关闭HDFS。

　　Namenode始终在内存中保存metedata，用于处理“读请求”，到有“写请求”到来时，namenode会首先写editlog到磁盘，即向edits文件中写日志，成功返回后，才会修改内存，并且向客户端返回，Hadoop会维护一个fsimage文件，也就是namenode中metedata的镜像，但是fsimage不会随时与namenode内存中的metedata保持一致，而是每隔一段时间通过合并edits文件来更新内容。

　　HDFSHA（HighAvailability是为了解决单点故障问题。

　　HA集群设置两个名称节点，“活跃（Active”和“待命（Standby”，两种名称节点的状态同步，可以借助于一个共享存储系统来实现，一旦活跃名称节点出现故障，就可以立即切换到待命名称节点。

　　为了保证读写数据一致性，HDFS集群设计为只能有一个状态为Active的NameNode，但这种设计存在单点故障问题，官方提供了两种解决方案：

　　通过增加一个SecondaryNameNode节点，处于Standby的状态，与Active的NameNode同时运行。当Active的节点出现故障时，切换到Secondary节点。

　　为了保证Secondary节点能够随时顶替上去，Standby节点需要定时同步Active节点的事务日志来更新本地的文件系统目录树信息，同时DataNode需要配置所有NameNode的位置，并向所有状态的NameNode发送块列表信息和心跳。

　　同步事务日志来更新目录树由JournalNode的守护进程来完成，简称为QJM，一个NameNode对应一个QJM进程，当Active节点执行任何命名空间文件目录树修改时，它会将修改记录持久化到大多数QJM中，Standby节点从QJM中监听并读取事务日志内容，并将日志应用到自己的命名空间。发生故障转移时，Standby节点将确保在将自身提升为Active状态之前，从QJM读取所有内容。

　　注意，QJM只是实现了数据的备份，当Active节点发送故障时，需要手工提升Standby节点为Active节点。如果要实现NameNode故障自动转移，则需要配套ZKFC组件来实现，ZKFC也是独立运行的一个守护进程，基于zookeeper来实现选举和自动故障转移。

　　虽然HDFSHA解决了“单点故障”问题，但是在系统扩展性、整体性能和隔离性方面仍然存在问题：

　　HDFSHA本质上还是单名称节点。HDFS联邦可以解决以上三个方面问题。

　　在HDFS联邦中，设计了多个相互独立的NN，使得HDFS的命名服务能够水平扩展，这些NN分别进行各自命名空间和块的管理，不需要彼此协调。每个DN要向集群中所有的NN注册，并周期性的发送心跳信息和块信息，报告自己的状态。

　　HDFS联邦拥有多个独立的命名空间，其中，每一个命名空间管理属于自己的一组块，这些属于同一个命名空间的块组成一个“块池”。每个DN会为多个块池提供块的存储，块池中的各个块实际上是存储在不同DN中的。

　　namenode节点无法启动的解决方案：

　　首先要检查core-site.xml和hdfs-site.xml文件是否配置好我是这么配置的：配置core-site.xml（核心组件????.进入core-site.xml文件:???.增加以下内容：配置hdfs-site.xml（文件系统???.进入hdfs.site.xml文件:???.增加以下内容：再进行以下操作：如果还没有出现namenode......那就请看下下面以下是我的解决方法：将data目录下面的文件都删除，再对namenode初始化（不要害怕初始化，我就是应为害怕，所以进程十分的缓慢，最后重启hadoop就成功啦然后就OK啦！！！悄咪咪：重启真是个好东西，如果有时候改命令还没有好，就重启一下，然后就莫名其妙的好了

　　单独启动namenode进程命令

　　单独启动namenode进程命令为Hadoop。该进程命令是通过运行start-all.sh脚本来调用sbin/start-dfs.sh脚本和sbin/start-yarn.sh脚本，然后再启动namenode。

　　Hadoop中的NameNode的作用是什么

　　NameNode为一个通常在HDFS实例中的单独机器上运行的软件。它负责管理文件系统名称空间和控制外部客户机的访问。NameNode决定是否将文件映射到DataNode上的复制块上。

　　对于最常见的个复制块，第一个复制块存储在同一机架的不同节点上，最后一个复制块存储在不同机架的某个节点上。

　　实际的I/O事务并没有经过NameNode，只有表示DataNode和块的文件映射的元数据经过NameNode。

　　当外部客户机发送请求要求创建文件时，NameNode会以块标识和该块的第一个副本的DataNodeIP地址作为响应。这个NameNode还会通知其他将要接收该块的副本的DataNode。

　　NameNode在一个称为FsImage的文件中存储所有关于文件系统名称空间的信息。这个文件和一个包含所有事务的记录文件（这里是EditLog将存储在NameNode的本地文件系统上。FsImage和EditLog文件也需要复制副本，以防文件损坏或NameNode系统丢失。

　　NameNode本身不可避免地具有SPOF（SinglePointOfFailure单点失效的风险，主备模式并不能解决这个问题，通过HadoopNon-stopnamenode才能实现%uptime可用时间。

　　NameNode管理文件系统的命名空间。它维护着文件系统树及整棵树内所有的文件和目录。这些信息以两个文件形式永久保存在本地磁盘上：命名空间镜像文件和日志文件。

　　NameNode也记录着每个文件中各个块所在的数据节点信息，但它并不永久保存块的位置信息，因为这些信息在系统启动时由数据节点重建。

　　参考资料来源：百度百科-Hadoop

　　Hadoop之NameNode目录结构

　　为了后面能够更加熟悉的保障Hadoop集群的平稳运行，我们需要深入的了解NameNode、SecondaryNameNode（也称辅助NameNode以及datanode等HDFS组件在磁盘上的目录结构以及运行的原理。这篇文章我们就一起来看一下NameNode的目录结构。NameNode的工作目录就是我门指定的hadoop工作目录（由hadoop.tmp.dir配置项指定，配置在core-site.xml文件内下的dfs/name目录。VERSION文件中包含正在运行的HDFS的版本信息，一般情况下应该包含下面的内容：当我们操作HDFS中的文件时，这些操作首先会被写入到日志中，然后相关的文件数据也会被更新。日志文件在概念上是单个实体，但是它其实是存储在磁盘上的多个文件上的，我们看到了很多的edits_xxx就是日志。但是任何一个时刻都只有一个日志文件处于打开可写的状态（edits_inprogress_xxx。其实这个有点类似日志滚动的概念。日志不会是无限的增长的，集群中的SecondaryNameNode会定期为namenode内存中的文件系统元数据创建系统镜像，具体的创建过程参照下图。edits日志文件合并的触发条件受两个配置项的控制，dfs.namenode.checkpoint.period（单位为秒，这个配置项是从时间维度上的控制，默认情况下是每隔个小时触发一次合并。第二个配置项是dfs.namenode.checkpoint.txns，这个配置是从日志大大小维度上进行控制的，默认是如果从上一个检查点开始日志已经达到了万个事务就合并。检查日志大小的频率默认是分钟检查一次，可由dfs.namenode.checkpoint.check.period（单位为秒配置项来改变。

　　namenode的主要功能

　　NameNode主要功能是接受客户端的读写服务。

　　NameNode维护着文件系统树及整棵树内所有的文件和目录。这些信息以两个文件形式永久保存在本地磁盘上：命名空间镜像文件和日志文件。NameNode也记录着每个文件中各个块所在的数据节点信息，但它并不永久保存块的位置信息，因为这些信息在系统启动时由数据节点重建。

　　Namenode的重要性

　　namenonde的作用在Hadoop中非常重要。它是Hadoop的大脑，主要负责管理系统上的分配块，还为客户提出请求时的数据提供特定地址。当有节点要访问某个文件的时候，它会先访问namenode，获取文件的位置信息，然后和dataNode直接通讯获取数据块，（类似目录的作用。