1.分布式文件存储系统HDFS——Namenode、源码元数据管理以及checkpoint
2.NameNode HA实现原理
3.创帆云大数据教程2-搭建docker的源码hadoop:namenode及resourceManager
4.原创-namenode配置Federation
5.2. Hadoop中的NameNode的作用是什么?
6.hadoop入门之namenode工作特点介绍

分布式文件存储系统HDFS——Namenode、元数据管理以及checkpoint

       HDFS，源码即Hadoop Distributed File System，源码是源码一个为各种分布式计算框架如Spark、MapReduce提供海量数据存储服务的源码定时跳转源码分布式文件存储系统。HDFS提供了一个统一的源码抽象目录树，通过路径如hdfs://namenode:port/dir-a/a.data，源码客户端可以访问文件。源码

       HDFS集群主要由两大角色构成：Namenode和Datanode。源码Namenode是源码主节点，负责管理整个文件系统的源码元数据，处理所有的源码读写请求。

       Namenode对元数据的源码管理采用三种形式：内存元数据、fsimage文件和edits文件。源码内存元数据基于内存存储，信息完整。fsimage文件是磁盘元数据的镜像文件，不包含block所在的Datanode信息。edits文件记录数据操作日志，jspxcms 完整源码通过日志可计算出内存元数据。fsimage + edits = 内存元数据。当客户端对HDFS中的文件进行新增或修改时，操作记录首先记入edit日志文件，随后更新内存元数据。

       在非HA模式下，Secondary Namenode每隔一定时间检查Namenode上的fsimage和edits文件是否需要合并。触发条件主要由配置参数设定。Secondary Namenode下载最新的fsimage和所有edits文件到本地，加载到内存中进行合并，然后将合并后的fsimage上传到Namenode。

       Secondary Namenode的作用有两个：加快Namenode启动和数据恢复。启动时，Namenode合并磁盘上的fsimage文件和edits文件，获取完整元数据。fsimage和edits文件过大，合并过程慢，导致HDFS长时间处于安全模式。SecondaryNamenode的源码 剑侠 完整checkpoint机制可以缓解此问题。此外，当Namenode故障退出需要恢复时，可以从SecondaryNamenode的工作目录中复制fsimage恢复Namenode。但SecondaryNamenode合并后的更新操作的元数据会丢失，因此建议Namenode元数据文件夹放在多个磁盘进行冗余，降低数据丢失风险。

       注意SecondaryNamenode在首次合并时需要从Namenode下载fsimage到本地。合并完成后，所持有的fsimage是最新的，无需再从Namenode处获取，只需获取edits文件即可。SecondaryNamenode将要合并的edits和fsimage拷贝到本地，反序列化到内存中计算合并。因此，通常需要将Namenode和SecondaryNamenode部署在不同机器上，且SecondaryNamenode服务器配置要求不低于Namenode。SecondaryNamenode不是Namenode的备服务器，主要职责是进行元数据的checkpoint。

NameNode HA实现原理

        前言：在Hadoop 1.x版本，HDFS集群的NameNode一直存在单点故障问题：集群只存在一个NameNode节点，它维护了HDFS所有的元数据信息，当该节点所在服务器宕机或者服务不可用，整个HDFS集群都将处于不可用状态，极大限制了HDFS在生产环境的应用场景。直到Hadoop 2.0版本才提出了高可用 (High Availability,英雄战歌源码 HA) 解决方案，并且经过多个版本的迭代更新，已经广泛应用于生产环境。

解决方案：在同一个HDFS集群，运行两个互为主备的NameNode节点。一台为主Namenode节点，处于Active状态，一台为备NameNode节点，处于Standby状态。其中只有Active NameNode对外提供读写服务，Standby NameNode会根据Active NameNode的状态变化，在必要时切换成Active状态。

        【NameNode HA架构图】

        HealthMonitor

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

        ActiveStandbyElector

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

        JouranlNode集群

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

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

        HealthMonitor检测NameNode的两类状态，HealthMonitor.State和HealthMonitor.HAServiceStatus。在程序上启动一个线程循环调用NameNode的HAServiceProtocol RPC接口的方法来检测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.如果Active NameNode对应的HealthMonitor检测到NameNode状态异常时，ZKFC会删除在Zookeeper上创建的临时节点ActiveStandbyElectorLock，这样处于Standby NameNode的ActiveStandbyElector注册的Watcher就会收到这个节点的 NodeDeleted事件。收到这个事件后，会马上再次创建ActiveStandbyElectorLock，如果创建成功，则Standby NameNode被选举为Active NameNode。

        【防止脑裂】

        在分布式系统中脑裂又称为双主现象，由于Zookeeper的“假死”，长时间的垃圾回收或其它原因都可能导致双Active NameNode现象，此时两个NameNode都可以对外提供服务，无法保证数据一致性。对于生产环境，这种情况的出现是毁灭性的，必须通过自带的隔离（Fencing）机制预防这种现象的出现。

        ActiveStandbyElector为了实现fencing隔离机制，在成功创建 hadoop-ha/dfs.nameservices/ActiveStandbyElectorLock 临时节点后，会创建另外一个 /hadoop−ha/{ dfs.nameservices}/ActiveBreadCrumb 持久节点，这个持久节点保存了Active NameNode的地址信息。当Active NameNode在正常的状态下断开Zookeeper Session (注意由于 /hadoop-ha/dfs.nameservices/ActiveStandbyElectorLock 是临时节点，也会随之删除)，会一起删除持久节点 /hadoop−ha/{ dfs.nameservices}/ActiveBreadCrumb 。但是如果ActiveStandbyElector在异常的状态下关闭Zookeeper Session，那么由于 /hadoop-ha/${ dfs.nameservices}/ActiveBreadCrumb 是持久节点，会一直保留下来。当另一个NameNode（standy => active）选主成功之后，会注意到上一个Active NameNode遗留下来的ActiveBreadCrumb节点，从而会回调ZKFailoverController的方法对旧的Active NameNode进行fencing。

        ① 首先ZKFC会尝试调用旧Active NameNode的HAServiceProtocol RPC接口的transitionToStandby方法，看能否将状态切换为Standby；

        ② 如果调用transitionToStandby方法切换状态失败，那么就需要执行Hadoop自带的隔离措施，Hadoop目前主要提供两种隔离措施：

sshfence：SSH to the Active NameNode and kill the process；

        shellfence：run an arbitrary shell command to fence the Active NameNode；

        只有在成功地执行完成fencing之后，选主成功的ActiveStandbyElector才会回调ZKFC的becomeActive方法将对应的NameNode切换为Active，开始对外提供服务。

        博客主页： /u/ebbf

创帆云大数据教程2-搭建docker的hadoop:namenode及resourceManager

       基于docker搭建namenode与resourceManger的教程

       搭建步骤如下：

       首先规划容器，Zookeeper已搭建完毕。

       建立一个基础容器，使用已制作的镜像，包含SSH、hadoop3.0文件和JDK。镜像环境变量需提前配置。

       配置核心文件：修改core-site.xml、hdfs-site.xml和mapred-site.xml，确保使用YARN框架执行MapReduce处理程序。注意，配置mapreduce.application.classpath参数避免运行时错误。

       编辑yarn-site.xml并更新worker列表。

       将配置好的基础容器提交为镜像，命名为hadoop:base。

       使用hadoop:base镜像创建多个容器：nn1、nn2为namenode节点；jn1、jn2、jn3为journalnode节点；rm1、rm2为yarn节点；dd1、快速充值源码dd2、dd3为datanode节点。

       启动容器，以journalnode1为例，其他类似，调整共享目录和容器名称。

       登录namenode主节点容器，格式化HDFS和ZKFC，启动HDFS。

       在yarn节点上启动yarn服务。

       验证HDFS和YARN，运行相应命令检查状态。

       至此，namenode与resourceManger搭建完成，下节将讲解HBase部署。

原创-namenode配置Federation

       1. 随着集群规模的扩大，达到上千节点，数据存储规模达到P左右，单namespace的性能瓶颈日益凸显。为解决这一问题，集群需配置多个namespace，即实施联邦（Federation）策略。

       2. 目前共配置了三个namespace，以确保集群的高效运行。

       3. 在配置dfs.namenode.shared.edits.dir属性时，需注意各value值的正确设置。对于其他两个namespace所在的namenode节点，分别应配置为testCluster和testCluster。

       4. 在core-site.xml文件中，fs.defaultFS属性应配置为hdfs://testCluster，以指定默认访问的namespace。

       5. 在规划的router节点上，通过执行命令hdfs --daemon start dfsrouter来启动联邦服务。服务默认端口为。启动后，可访问如下界面：

        - hdfs dfsrouteradmin -add /testClusterRoot testCluster /

        - hdfs dfsrouteradmin -add /testClusterRoot testCluster /

        - hdfs dfsrouteradmin -add /testClusterRoot testCluster /

       6. 具体操作语法命令可参考apache官网。

       7. 客户端若希望通过router访问联邦集群，需在hdfs-site.xml文件中进行如下调整：添加新的namespace（testClusterFed），并配置高可用模式。注意，dfs.namenode.rpc-address.testClusterFed.r1属性应配置为router对应的服务，端口为。

       8. 调整后，客户端即可通过命令hadoop fs -ls hdfs://testClusterFed/testClusterRoot来访问联邦集群。

2. Hadoop中的NameNode的作用是什么?

       NameNode在Hadoop分布式文件系统（HDFS）中扮演着核心角色，它作为一个独立的服务器软件，负责整个系统的名称空间管理和客户端访问控制。它的主要职责是决定文件如何被分割成数据块，并决定这些块应存储在哪个DataNode上，以实现数据的冗余和容错性。通常，一个文件的三个复制块中，第一个在本地机架的不同节点，最后一个在不同机架的节点上存储，以确保数据的安全性。

       NameNode在数据操作中并不直接参与实际的I/O，而是管理文件的元数据，如文件映射到DataNode的位置。当用户创建文件时，NameNode会响应提供文件块标识和第一个副本的DataNode IP地址，并通知其他副本的DataNode。为了保障数据的持久性和可靠性，FsImage文件存储着整个名称空间的信息，而EditLog记录所有事务，两份副本都存储在NameNode上，以防数据丢失。

       然而，NameNode的单点故障问题是一个挑战，因为它是一个关键服务的集中点。传统的主备模式并不能解决这一问题。为了实现更高的可用性，Hadoop引入了Non-stop NameNode，以确保%的运行时间。NameNode的主要任务还包括维护文件系统的目录结构，以及记录每个文件块在DataNode的临时存储信息，这些信息在系统启动时由DataNode自行重建。

       总的来说，NameNode在Hadoop中是至关重要的，它负责管理文件系统的核心逻辑，保证数据的安全、冗余和系统的稳定性。

hadoop入门之namenode工作特点介绍

       namenode始终在内存中保存metedata（整个文件系统的目录结构，每个目录有哪些文件，每个文件有哪些分块及每个分块保存在哪个DataNode上），用于处理“读请求”（不需要修改内容）

       到有“写请求”到来时，namenode会首先对metedata修改的内容写editlog到磁盘（每一次改变都会同步到磁盘。），成功返回后，才会修改内存，并且向客户端返回。客户端在写数据到每个datanode中。namenode在将metadata写到editlog的时候会同步到磁盘。

       Hadoop会维护一个fsimage文件，也就是namenode中metedata的镜像，但是fsimage不会随时与namenode内存中的metedata保持一致（因为非常大），而是每隔一段时间通过合并editlog来更新内容。Secondary namenode就是用来更新fsimage的

       secondary namenode的工作流程

       1.Secondary通知primary切换editlog（目的合并editlog）

       2.Secondary从primary获得fsimage和editlog（通过http）

       3.Secondary将fsimage载入内存，然后开始合并editlog

       4.Secondary将新的fsimage发回给primary

       5.Primary用新的fsimage替换旧的fsimage

       什么时候checkpiont?

       fs.checkpoint.period 指定两次checkpoint的最大时间间隔，默认秒。

       fs.checkpoint.size 规定edits文件的最大值，一旦超过这个值则强制checkpoint，不管是否到达最大时间间隔。默认大小是M。