或者通过hdfs命令也可以查看当前的状态
[root@bigdata01 hadoop-3.2.0]# hdfs dfsadmin -safemode get Safe mode is ON 如果想快速离开安全模式，可以通过命令强制离开，正常情况下建议等 HDFS 自检完毕，自动退出 [root@bigdata01 hadoop-3.2.0]# hdfs dfsadmin -safemode leave Safe mode is OFF 此时，再操作 HDFS 中的文件就可以了。 实战：定时上传数据至 HDFS 需求分析： 在实际工作中会有定时上传数据到 HDFS 的需求，我们有一个 web 项目每天都会产生日志文件，日 志文件的格式为 access_2020_01_01.log 这种格式的，每天产生一个，我们需要每天凌晨将昨天生 成的日志文件上传至 HDFS 上，按天分目录存储， HDFS 上的目录格式为 20200101 针对这个需求，我们需要开发一个 shell 脚本，方便定时调度执行 第一步：我们需要获取到昨天日志文件的名称 第二步：在 HDFS 上面使用昨天的日期创建目录 第三步：将昨天的日志文件上传到刚创建的 HDFS 目录中 第四步：要考虑到脚本重跑，补数据的情况 第五步：配置 crontab 任务 开始开发 shell 脚本，脚本内容如下： [root@bigdata01 ~]# mkdir -p /data/shell [root@bigdata01 ~]# cd /data/shell [root@bigdata01 shell]# vi uploadLogData.sh #!/bin/bash # 获取昨天日期字符串 yesterday=$1 if [ "$yesterday" = "" ] then yesterday=`date +%Y_%m_%d --date="1 days ago"` fi # 拼接日志文件路径信息 logPath=/data/log/access_${yesterday}.log # 将日期字符串中的 _ 去掉 hdfsPath=/log/${yesterday//_/} # 在 hdfs 上创建目录 hdfs dfs -mkdir -p ${hdfsPath} # 将数据上传到 hdfs 的指定目录中 hdfs dfs -put ${logPath} ${hdfsPath} 生成测试数据，注意，文件名称中的日期根据昨天的日期命名 [root@bigdata01 shell]# mkdir -p /data/log [root@bigdata01 shell]# cd /data/log [root@bigdata01 log]# vi access_2020_04_08.log log1 执行脚本 [root@bigdata01 log]# cd /data/shell/ [root@bigdata01 shell]# sh -x uploadLogData.sh + yesterday= + '[' '' = '' ']' ++ date +%Y_%m_%d '--date=1 days ago' + yesterday=2020_04_08 + logPath=/data/log/access_2020_04_08.log + hdfsPath=/log/20200408 + hdfs dfs -mkdir -p /log/20200408 + hdfs dfs -put /data/log/access_2020_04_08.log /log/20200408 [root@bigdata01 shell]# hdfs dfs -ls /log/20200408 Found 1 items -rw-r--r-- 2 root supergroup 15 2020-04-09 16:05 /log/20200408/acce 注意：如果想要指定日期上传数据，可以通过在脚本后面传递参数实现 先创建一个日期的测试数据 [root@bigdata01 shell]# cd /data/log/ [root@bigdata01 log]# cp access_2020_04_08.log access_2020_01_01.log 执行脚本 [root@bigdata01 log]# cd /data/shell/ [root@bigdata01 shell]# sh -x uploadLogData.sh 2020_01_01 + yesterday=2020_01_01 + '[' 2020_01_01 = '' ']' + logPath=/data/log/access_2020_01_01.log + hdfsPath=/log/20200101 + hdfs dfs -mkdir -p /log/20200101 + hdfs dfs -put /data/log/access_2020_01_01.log /log/20200101 [root@bigdata01 shell]# hdfs dfs -ls /log/20200101 Found 1 items -rw-r--r-- 2 root supergroup 15 2020-04-09 16:17 /log/20200101/acce 这样后期如果遇到某天的数据漏传了，或者需要重新上传，就可以通过手工指定日期实现上传操作，在实 际工作中这种操作是不可避免的，所以我们在开发脚本的时候就直接考虑好补数据的情况，别等需要用的 时候了再去增加这个功能。 最后配置 crontab 定时任务，每天凌晨 1 点执行 [root@bigdata01 shell]# vi /etc/crontab 0 1 * * * root sh /data/shell/uploadLogData.sh >> /data/shell/uploadLogData.l HDFS 的高可用和高扩展 我们前面分析了 NameNode 负责接收用户的操作请求，所有的读写请求都会经过它，如果它挂了怎么 办？ 这个时候集群是不是就无法正常提供服务了？是的，那现在我们这个集群就太不稳定了，因为 NameNode 只有一个，是存在单点故障的，咱们在现实生活中，例如，县长，是有正的和副的，这样就 是为了解决当正县长遇到出差的时候，副县长可以顶上去。 所以在 HDFS 的设计中， NameNode 也是可以支持多个的，一个主的 多个备用的，，当主的挂掉了，备 用的可以顶上去，这样就可以解决NameNode 节点宕机导致的单点故障问题了，也就实现了 HDFS 的高可 用还有一个问题是，前面我们说了NameNode 节点的内存是有限的，只能存储有限的文件个数，那使用一 个主NameNode ，多个备用的 NameNode 能解决这个问题吗？ 不能！ 一个主NameNode ，多个备用的 NameNode 的方案只能解决 NameNode 的单点故障问题，无法解决单个 NameNode内存不够用的问题，那怎么办呢？不用担心，官方提供了 Federation 机制，可以翻译为联 邦，它可以解决单节点内存不够用的情况，具体实现思路我们稍后分析，这个就是HDFS 的高扩展 （联邦机制主要解决内存不足问题，主备主要管防止节点挂掉，主备之间进行选举，得到Active状态的主节点，备用节点进行备份，防止主节点挂掉自己顶上来） HDFS 的高可用 (HA) 下面我们首先来看一下 HDFS 的高可用，也可以称之为 HA(High Available) HDFS的HA ，指的是在一个集群中存在多个 NameNode ，分别运行在独立的物理节点上。在任何时间 点，只有一个NameNode 是处于 Active 状态，其它的是处于 Standby 状态。 Active NameNode （简写为 Active NN）负责所有的客户端的操作，而 Standby NameNode （简写为 Standby NN ）用来同步 Active NameNode的状态信息，以提供快速的故障恢复能力。 为了保证 Active NN 与 Standby NN 节点状态同步，即元数据保持一致。除了 DataNode 需要向这些 NameNode 发送 block 位置信息外，还构建了一组独立的守护进程 ”JournalNodes” （简写为 JN ） , 用来同 步Edits 信息。当 Active NN 执行任何有关命名空间的修改，它需要持久化到一半以上的 JNs 上。而 Standby NN负责观察 JNs 的变化，读取从 Active NN 发送过来的 Edits 信息，并更新自己内部的命名空间。 一旦Active NN 遇到错误， Standby NN 需要保证从 JNs 中读出了全部的 Edits ，然后切换成 Active 状态，如 果有多个Standby NN ，还会涉及到选主的操作，选择一个切换为 Active 状态。 需要注意一点，为了保证 Active NN 与 Standby NN 节点状态同步，即元数据保持一致 这里的元数据包含两块，一个是静态的，一个是动态的 静态的是 fsimage 和 edits ，其实 fsimage 是由 edits 文件合并生成的，所以只需要保证 edits 文件内容的一 致性。这个就是需要保证多个 NameNode 中 edits 文件内容的事务性同步。这块的工作是由 JournalNodes 集群进行同步的 动态数据是指 block 和 DataNode 节点的信息，这个如何保证呢？ 当 DataNode 启动的时候，上报数据信息的时候需要向每个 NameNode 都上报一份。 这样就可以保证多个 NameNode 的元数据信息都一样了，当一个 NameNode down 掉以后，立刻从 Standby NN 中选择一个进行接管，没有影响，因为每个 NameNode 的元数据时刻都是同步的。 注意 : 使用 HA 的时候，不能启动 SecondaryNameNode ，会出错。 之前是 SecondaryNameNode 负责合并 edits 到 fsimage 文件 那么现在这个工作被 standby NN 负 责了。 NameNode 切换可以自动切换，也可以手工切换，如果想要实现自动切换，需要使用到 zookeeper 集 群。 使用 zookeeper 集群自动切换的原理是这样的 当多个 NameNode 启动的时候会向 zookeeper 中注册一个临时节点，当 NameNode 挂掉的时候，这个临 时节点也就消失了，这属于zookeeper 的特性，这个时候， zookeeper 就会有一个 watcher 监视器监视 到，就知道这个节点down 掉了，然后会选择一个节点转为 Active ，把 down 掉的节点转为 Standby 。 注意：下面的配置步骤建议大家有空闲时间了再来操作就行，作为一个课外扩展，因为在工作中这个配置 是不需要我们做的，我们只需要知道这种特性即可。 下面开始配置 HDFS 的 HA HA 集群规划 解释：针对 HDFS 的 HA 集群，在这里我们只需要启动 HDFS 相关的进程即可， YARN 相关的进程可以不启 动，它们两个的进程本来就是相互独立的。 在 HDFS 的 HA 集群中，就不需要启动 SecondaryNameNode 进程了 namenode ： hdfs 的主节点 datanode ： hdfs 的从节点 journalnode ： JournalNode 进程，用来同步 Edits 信息的 zkfc(DFSZKFailoverController) ：监视 namenode 的状态，负责切换 namenode 节点的状态 zookeeper(QuorumPeerMain) ：保存 ha 集群的节点状态信息 环境准备：三个节点 bigdata01 192.168.182.100 bigdata02 192.168.182.101 bigdata03 192.168.182.102 每个节点的基础环境都要先配置好，先把 ip 、 hostname 、 fifirewalld 、 ssh 免密码登录、 host 、免密码登 录，JDK 这些基础环境配置好 我们目前使用的这几台机器之前已经搭建过分布式集群，所以这些基础环境都是没有问题的 但是注意：有一点还需要完善一下，由于 namenode 在进行故障切换的时候，需要在两个 namenode 节点之间互相使用 ssh 进行连接，所以需要实现这两个 namenode 之间的互相免密码登 录，目前我们只实现了 bigdata01 免密码登录到 bigdata02 ，所以还需要实现 bigdata02 免密码登 录到 bigdata01 ，这一步如果不做，后期无法实现 namenode 故障自动转移。 [root@bigdata02 hadoop]# scp ~/.ssh/authorized_keys bigdata01:~/ root@bigdata01's password: 输入密码 authorized_keys 100% 792 456.2KB/s 00:00 [root@bigdata01 hadoop]# cat ~/authorized_keys >> ~/.ssh/authorized_keys 然后验证一下 bigdata02 是否可以免密码登录 bigdata01 ，只要可以不输入密码就能连接进去就说明免密 码登录搞定了。 [root@bigdata02 hadoop]# ssh bigdata01 Last login: Fri Feb 6 23:54:41 2026 from 192.168.182.1 接着把 bigdata01 、 bigdata02 、 bigdata03 中之前安装的 hadoop 删掉，删除解压的目录，以及 hadoop_repo 目录。 注意：我们需要把 bigdata01 、 bigdata02 、 bigdata03 节点中 /data 目录下的 hadoop_repo 目录 和 /data/soft 下的 hadoop-3.2.0 目录删掉，恢复这些节点的环境，这里面记录的有之前集群的一些 信息。 [root@bigdata01 ~]# rm -rf /data/soft/hadoop-3.2.0 [root@bigdata01 ~]# rm -rf /data/hadoop_repo [root@bigdata02~]# rm -rf /data/soft/hadoop-3.2.0 [root@bigdata02 ~]# rm -rf /data/hadoop_repo [root@bigdata03 ~]# rm -rf /data/soft/hadoop-3.2.0 [root@bigdata04 ~]# rm -rf /data/hadoop_repo 我们在这里需要使用到 zookeeper 这个组件，所以先把它安装起来。 bigdata01 bigdata02 bigdata03 2. 首先在 bigdata01 节点上配置 zookeeper 解压 [root@bigdata01 soft]# tar -zxvf apache-zookeeper-3.5.8-bin.tar.gz 修改配置 dataDir=/data/soft/apache-zookeeper-3.5.8-bin/data server.0=bigdata01:2888:3888 server.1=bigdata02:2888:3888 server.2=bigdata03:2888:3888 创建目录保存 myid 文件，并且向 myid 文件中写入内容 myid 中的值其实是和 zoo.cfg 中 server 后面指定的编号是一一对应的 编号 0 对应的是 bigdata01 这台机器，所以在这里指定 0 在这里使用 echo 和 重定向 实现数据写入 [root@bigdata01 conf]#cd /data/soft/apache-zookeeper-3.5.8-bin [root@bigdata01 apache-zookeeper-3.5.8-bin]# mkdir data [root@bigdata01 apache-zookeeper-3.5.8-bin]# cd data [root@bigdata01 data]# echo 0 > myid 3. 把修改好配置的 zookeeper 拷贝到其它两个节点 [root@bigdata01 soft]# scp -rq apache-zookeeper-3.5.8-bin bigdata02:/data/soft [root@bigdata01 soft]# scp -rq apache-zookeeper-3.5.8-bin bigdata03:/data/sof 4. 修改 bigdata02 和 bigdata03 上 zookeeper 中 myid 文件的内容 首先修改 bigdata02 节点上的 myid 文件 [root@bigdata02 ~]# cd /data/soft/apache-zookeeper-3.5.8-bin/data/ [root@bigdata02 data]# echo 1 > myid 然后修改 bigdata03 节点上的 myid 文件 [root@bigdata03 data]# cd /data/soft/apache-zookeeper-3.5.8-bin/data/ [root@bigdata03 data]# echo 2 > myid 启动 zookeeper 集群 分别在 bigdata01 、 bigdata02 、 bigdata03 上启动 zookeeper 进程 在 bigdata01 上启动 [root@bigdata01 apache-zookeeper-3.5.8-bin]# bin/zkServer.sh start ZooKeeper JMX enabled by default Using config: /data/soft/apache-zookeeper-3.5.8-bin/bin/../conf/zoo.cfg Starting zookeeper ... STARTED 。。。。（2,3机器照做） 6. 验证 分别在 bigdata01 、 bigdata02 、 bigdata03 上执行 jps 命令验证是否有 QuorumPeerMain 进程 如果都有就说明 zookeeper 集群启动正常了 如果没有就到对应的节点的 logs 目录下查看 zookeeper*-*.out 日志文件 执行 bin/zkServer.sh status 命令会发现有一个节点显示为 leader ，其他两个节点为 follower [root@bigdata01 apache-zookeeper-3.5.8-bin]# bin/zkServer.sh status ZooKeeper JMX enabled by default Using config: /data/soft/apache-zookeeper-3.5.8-bin/bin/../conf/zoo.cfg Client port found: 2181. Client address: localhost. Mode: follower [root@bigdata02 apache-zookeeper-3.5.8-bin]# bin/zkServer.sh status ZooKeeper JMX enabled by default Using config: /data/soft/apache-zookeeper-3.5.8-bin/bin/../conf/zoo.cfg Client port found: 2181. Client address: localhost. Mode: leader [root@bigdata03 apache-zookeeper-3.5.8-bin]# bin/zkServer.sh status ZooKeeper JMX enabled by default Using config: /data/soft/apache-zookeeper-3.5.8-bin/bin/../conf/zoo.cfg Client port found: 2181. Client address: localhost. Mode: follower 7.停止zookeeper集群 最后想要停止 zookeeper 集群的时候可以在 bigdata01 、 bigdata02 、 bigdata03 三台机器上分别执行 bin/zkServer.sh stop 命令即可。 接下来我们来配置 Hadoop 集群 先在 bigdata01 节点上进行配置 1. 解压 hadoop 安装包 [root@bigdata01 soft]# tar -zxvf hadoop-3.2.0.tar.gz 2. 修改 hadoop 相关配置文件 进入配置文件所在目录 [root@bigdata01 soft]# cd hadoop-3.2.0/etc/hadoop/ [root@bigdata01 hadoop]# [root@bigdata01 hadoop]# vi hadoop-env.sh export JAVA_HOME=/data/soft/jdk1.8 export HADOOP_LOG_DIR=/data/hadoop_repo/logs/hadoop 修改 core-site.xml 文件 [root@bigdata01 hadoop]# vi core-site.xml此时我们来手工停掉 active 状态的 namenode ，模拟 namenode 宕机的情况，验证一下另一个 standby 的 namenode 是否可以自动切换为 active [root@bigdata01 hadoop-3.2.0]# jps 8758 DFSZKFailoverController 8267 NameNode 1581 QuorumPeerMain 8541 JournalNode 8814 Jps [root@bigdata01 hadoop-3.2.0]# kill 8267 [root@bigdata01 hadoop-3.2.0]# jps 8758 DFSZKFailoverController 1581 QuorumPeerMain 8541 JournalNode 8845 Jps 工停掉 active 状态的 namenode ，模拟 namenode 宕机的情况，验证一下另一个 standby 的 namenode 是否可以自动切换为 active 此时再刷新查看 bigdata02 的信息，会发现它的状态变为了 active
接着我们再把bigdata01中的namenode启动起来，会发现它的状态变为了standby
[root@bigdata01 hadoop-3.2.0]# bin/hdfs --daemon start namenode [root@bigdata01 hadoop-3.2.0]# jps 8898 NameNode 8758 DFSZKFailoverController 8967 Jps 1581 QuorumPeerMain 8541 JournalNode 通过前面的操作可以发现，现在的 namenode 其实就解决了单点故障的问题，实现了高可用。 现在我们再操作 HDFS 的时候就应该这样操作了。 这里面的 mycluster 就是在 hdfs-site.xml 中配置的 dfs.nameservices 属性的值。 [root@bigdata02 hadoop-3.2.0]# bin/hdfs dfs -ls hdfs://mycluster/ [root@bigdata02 hadoop-3.2.0]# bin/hdfs dfs -put README.txt hdfs://mycluster/ [root@bigdata02 hadoop-3.2.0]# bin/hdfs dfs -ls hdfs://mycluster/ Found 1 -rw-r--r-- 2 root supergroup 1361 2026-02-07 00:58 hdfs://mycluster/R 停止 HDFS 的 HA 集群 [gdata01 hadoop-3.2.0]# sbin/stop-dfs.sh Stopping namenodes on [bigdata01 bigdata02] Last login: Sat Feb 7 00:52:01 CST 2026 on pts/0 Stopping datanodes Last login: Sat Feb 7 01:03:23 CST 2026 on pts/0 Stopping journal nodes [bigdata01 bigdata03 bigdata02] Last login: Sat Feb 7 01:03:25 CST 2026 on pts/0 Stopping ZK Failover Controllers on NN hosts [bigdata01 bigdata02] Last login: Sat Feb 7 01:03:29 CST 2026 on pts/0 HDFS 的高扩展 (Federation) HDFS Federation 可以解决单一命名空间存在的问题，使用多个 NameNode ，每个 NameNode负责一个 这种设计可提供以下特性： 1 ： HDFS 集群扩展性。多个 NameNode 分管一部分目录，使得一个集群可以扩展到更多节点，不再因内 存的限制制约文件存储数目。 2 ：性能更高效。多个 NameNode 管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐 率。 3 ：良好的隔离性。用户可根据需要将不同业务数据交由不同 NameNode 管理，这样不同业务之间影响很 小。 如果真用到了 Federation ，一般也会和前面我们讲的 HA 结合起来使用，来看这个图这里面用到了 4 个 NameNode 和 6 个 DataNode NN-1 、 NN-2 、 NN-3 、 NN-4 DN-1 、 DN-2 、 DN-3 、 DN-4 、 DN-5 、 DN-6 、 其中 NN-1 、和 NN-3 配置了 HA ，提供了一个命令空间， /share ，其实可理解为一个顶级目录 NN-2 和 NN-4 配置了 HA ，提供了一个命名空间， /user 这样后期我们存储数据的时候，就可以根据数据的业务类型来区分是存储到 share 目录下还是 user 目录 下，此时 HDFS 的存储能力就是 /share 和 /user 两个命名空间的总和了。
