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文件记录数据操作日志，网页的源码文件通过日志可计算出内存元数据。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。