尧图网页设计 
1. 从零开始搭建 Hadoop 集群前必须先想清楚这几件事先聊点实在的。很多人一上来就搜“Hadoop 集群搭建”照着网上教程复制粘贴结果不是这里报错就是那里起不来折腾一两天最后把系统重装了。我当年也干过这种事后来带过几个实习生看他们踩的坑基本一模一样。所以这篇东西我不打算只给你一份“照着敲就行”的命令清单而是想把背后的逻辑、容易翻车的点、以及我实际生产环境中用到的经验一起讲清楚。先说结论Hadoop 集群搭建本身不难难的是你对它有没有一个全局认知。你得清楚自己在搭什么、为什么要这么搭、每个配置文件动了哪根神经。从应用场景来看Hadoop 集群搭建是几乎所有大数据项目的底座。不管你是要做网约车订单数据的清洗分析、校园大数据可视化、交通信息分析系统还是 Spark 离线计算、Hive 数仓建设第一步永远是先把 HDFS 和 YARN 跑起来。我见过不少毕业设计选“基于 Hadoop 的某某分析系统”的同学上来就想写代码结果连 HDFS 的存储机制都没搞明白最后数据往里一丢就 OOM内存溢出。这个思路必须纠正。所以这篇博文适合谁想系统学大数据的学生、要搭环境做毕设或比赛的开发者、准备跳槽大数据开发岗需要面试干货的工程师。如果你是完全没接触过 Linux 的新手建议先补一下基本命令再来看否则有些操作你会觉得像在看天书。2. 环境准备与版本选型这一步偷懒后面全是坑2.1 硬件与操作系统千万别用 Windows 当主战场先说最容易被忽视的问题操作系统。Hadoop 从设计上就跑在 Linux 上虽然 Windows 上用 IDEA 也能开发调试但你要是想在 Windows 上搭真正的多节点集群那就是给自己上刑。我的建议很直接学习/测试环境本地装 VMware 或 VirtualBox建三台 CentOS 7.9 虚拟机内存至少 2GB/台4GB 更舒服用 NAT 或桥接模式都行。生产/准生产环境建议物理机或云主机规格至少 8 核 16G 起步磁盘最好是多块让数据盘和系统盘分开。操作系统版本上CentOS 7.x 是绝大多数教程的选择也是企业用得最多的。它够稳、软件源全、踩坑资料最多。虽然 CentOS 8 已经停止维护但大数据生态对它的依赖不会因为你换了新版就瞬间适配所以 CentOS 7 依然是当前阶段最稳的底座。如果你愿意折腾Ubuntu 20.04 也可以只是很多调优参数和文件路径会和 CentOS 有差异新手容易混乱。注意一定要统一所有节点的时间和时区。Hadoop 内部对时间非常敏感时钟漂移会导致认证失败、心跳异常等一堆莫名其妙的问题。我吃过这个亏集群三个节点时间差了 30 秒DataNode 反复掉线排查了大半天最后发现是虚拟机挂起恢复后时钟没同步。同步方式很简单装个 ntpdate 然后写个定时任务就行# 所有节点执行 yum install -y ntpdate ntpdate -u ntp.aliyun.com # 写定时任务每 10 分钟同步一次 echo */10 * * * * /usr/sbin/ntpdate -u ntp.aliyun.com /dev/null 21 /var/spool/cron/root2.2 软件版本搭配JDK、Hadoop、Zookeeper 的兼容性盘点版本选型是大数据入门的第一道坎也是面试爱问的点。我直接给出经过验证的组合照抄即可组件版本备注CentOS7.9最小化安装即可JDK8u202 或 1.8.0_301Hadoop 3.x 要求 JDK 8JDK 11 也能跑但生态里很多工具对 8 的兼容性最好Hadoop3.3.4 或 3.2.43.x 系列较稳3.3.x 对新手更友好Zookeeper3.6.3做 HA 高可用用单节点测试可不装JDK 这里多说一句千万别用默认的 OpenJDK 图省事从 Oracle JDK 官网下载 .tar.gz 版本自己解压配置 JAVA_HOME 最干净。OpenJDK 在个别场景下会出现一些诡异问题比如 SSL 握手异常、加密算法不支持等。反正都是免费的何苦给自己埋雷。Hadoop 版本上3.1.x 和 3.3.x 我都深度用过当前推荐 3.3.4。它默认支持 NameNode 联邦的改进、YARN 的 Capacity Scheduler 多队列能力也更完善而且对 S3 等云存储的适配更好。如果是学生做毕设3.3.4 完全够用。2.3 网络规划与主机名设置提前规划节点角色不然后患无穷节点规划是整个搭建过程最关键的一步没有之一。我建议三台机器一主两从的经典架构主机名IP 示例角色分配hadoop01192.168.100.101NameNode、ResourceManager、SecondaryNameNodehadoop02192.168.100.102DataNode、NodeManagerhadoop03192.168.100.103DataNode、NodeManager为什么是三台而不是两台因为 HDFS 默认副本数是 3两份就达不到备份效果四份以上又浪费存储。学习阶段三台能让你完整体验副本机制和机架感知面试被问到“为什么副本数是 3”的时候你也能结合实际说两句。设置主机名和 hosts 映射# 三台机器分别执行 hostnamectl set-hostname hadoop01 # 然后编辑 /etc/hosts三台机器内容一致 cat /etc/hosts EOF 192.168.100.101 hadoop01.hadoop.com hadoop01 192.168.100.102 hadoop02.hadoop.com hadoop02 192.168.100.103 hadoop03.hadoop.com hadoop03 EOF这里必须强调hosts 文件的顺序和内容一定不要乱。集群内所有节点的一致性至关重要特别是 hosts、JAVA_HOME 路径、Hadoop 解压路径这些必须统一。我遇到过只改了主节点的 /etc/hosts从节点还是旧 IP 映射结果从节点起 DataNode 时一直连不上 NameNode报错信息看了半天才反应过来。最后配置三台机器之间的 SSH 免密登录。这一步是为了后续脚本化管理集群做准备也是 Hadoop 启动脚本自身依赖的基础start-dfs.sh 会通过 SSH 远程启动各节点的进程# 每个节点生成密钥 ssh-keygen -t rsa -P -f ~/.ssh/id_rsa # 把公钥分发到三台机器的 authorized_keys 中 ssh-copy-id hadoop01 ssh-copy-id hadoop02 ssh-copy-id hadoop03 # 验证免密 ssh hadoop02 date实操心得免密一定要双向配好别只在主节点配到从节点。你后面用 xsync 脚本分发配置文件的时候从节点如果还要输入密码整个流程的自动化就断了。3. 核心配置文件逐项拆解每个参数背后的原理说明3.1 为什么 Hadoop 的配置在 XML 里而不是命令行很多人第一次打开 core-site.xml 会困惑这么重要的系统配置为啥不写在 yml 或者 properties 里要用 XML我理解这件事的核心逻辑是这样的Hadoop 的定位是分布式框架底层用 Java 写Java 生态里 XML 的 DOM/SAX 解析非常成熟复杂的层级结构表达能力强而且 Hadoop 设计了“默认配置 用户覆盖”的机制——所有参数在 jar 包里有默认值你写的 core-site.xml 只是覆盖你关心的那部分改坏了也容易恢复。这种设计最大的好处是你不需要理解每个参数的含义才能跑起来系统给你的默认值在绝大多数场景是能工作的。你只需要关注几个核心参数把它们调对就够了。配置文件总共就那么几个分布在 $HADOOP_HOME/etc/hadoop/ 目录下按功能可以归成三类全局通用配置core-site.xml决定文件系统访问方式、I/O 调优等HDFS 配置hdfs-site.xml这是重头戏负责管理各个守护进程的职责和存储行为计算调度配置yarn-site.xml 和 mapred-site.xml决定谁来做分布式计算和调度3.2 core-site.xml 详解默认文件系统到底意味着什么core-site.xml 是其他所有配置的基础。我先给你看我实际生产里用的精简版configuration property namefs.defaultFS/name valuehdfs://hadoop01:9820/value /property property namehadoop.tmp.dir/name value/opt/hadoop/tmp/value /property property namehadoop.http.staticuser.user/name valueroot/value /property /configuration第一个参数 fs.defaultFS 是灵魂所在。它决定了 HDFS 的入口地址也就是客户端去哪里找 NameNode。学习阶段你可以写成 file:/// 用本地文件系统但想体验真正的分布式存储必须改成 hdfs:// 协议。后面的端口号 9820旧版本是 90003.x 改成了 9820是 NameNode 的 RPC 通信端口DataNode 和客户端全靠这个端口和 NameNode 保持心跳、读写元数据。第二个参数 hadoop.tmp.dir 是大多数新手翻车的重灾区。它默认为 /tmp/hadoop-${user.name}而 /tmp 目录在 Linux 启动后会被清理。如果你没有改这个路径重启机器后 NameNode 的元数据目录就没了格式化又不知道格式化哪份集群直接哑火。所以我建议把它指定到一个独立的数据盘比如 /opt/hadoop/tmp既安全又方便备份。注意hadoop.tmp.dir 一旦确定并格式化后就不要再改路径。改了就等于告诉 NameNode 换了个新的元数据存储位置它会认为集群是初始化状态需要重新格式化而格式化会清空所有元数据相当于数据丢了。这个坑无数人踩过我亲眼见过同事因为想给 tmp 目录换大磁盘直接把整个集群数据弄丢。3.3 hdfs-site.xml 详解副本数、NameNode 和 DataNode 的存储目录hdfs-site.xml 是 Hadoop 集群的“宪法”里面定义的每一个属性都直接影响数据的安全性和集群性能。我这里给一份我平时用得最多的配置configuration !-- 副本数默认就是3也可以不写 -- property namedfs.replication/name value3/value /property !-- NameNode 元数据存储目录 -- property namedfs.namenode.name.dir/name valuefile:///opt/hadoop/data/namenode/value /property !-- DataNode 数据存储目录逗号分隔多磁盘可以写多个 -- property namedfs.datanode.data.dir/name valuefile:///opt/hadoop/data/datanode/value /property !-- 关闭集群时的安全模式自动进入测试环境可以关掉 -- property namedfs.namenode.safemode.threshold-pct/name value1.0f/value /property !-- 设置SecondaryNameNode的地址 -- property namedfs.namenode.secondary.http-address/name valuehadoop01:9868/value /property /configurationdfs.replication 是面试里的高频题为什么默认是 3原因很简单——它兼顾了数据可靠性和存储成本。一份原始数据一份放在同一个机架的另一个节点防止单机器故障第三份放到不同机架防止整个机架断电或交换机故障这样任何一个节点或机架出问题数据都能恢复。dfs.namenode.name.dir 和 dfs.datanode.data.dir 这两个参数要重点解释。它们决定数据到底落在哪块磁盘上。生产环境我强烈建议你把这两项配置成多个目录用逗号分隔file:///data1/hadoop/namenode,file:///data2/hadoop/namenode这样做的原理是 Hadoop 会对这些目录做镜像写入——同一份元数据同时写到两块物理磁盘上单块磁盘坏了不至于全丢。DataNode 则是轮询写入策略数据文件打到不同磁盘上既充分利用磁盘 IO 和空间又降低了单盘故障的损失。还有一点大家容易忽略SecondaryNameNode 不是 NameNode 的备用节点。它的作用是定期合并 NameNode 的编辑日志edits和镜像文件fsimage减轻 NameNode 重启时的恢复压力。如果主 NameNode 挂了SecondaryNameNode 不能立刻顶上但它有最近一次的合并结果可以配合日志尽量恢复。这个知识点很多教程说不清楚面试也爱挖坑你搞明白了会很有优势。3.4 yarn-site.xml 详解ResourceManager 和 NodeManager 的协作机制YARN 是 Hadoop 的资源调度平台。我在给别人讲 YARN 的时候喜欢打一个比方YARN 就像一个酒店的管理系统ResourceManager 是前台大堂经理NodeManager 是各楼层的服务员你的 MapReduce 任务就是住店的客人。客人来了先找大堂经理要房间申请资源经理查一下哪个楼层有空房通过心跳信息掌握各节点资源情况然后安排服务员带客人入住分配容器。看配置configuration !-- 启用 YARN 的 ResourceManager -- property nameyarn.resourcemanager.hostname/name valuehadoop01/value /property !-- NodeManager 附属服务 -- property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property !-- 为辅助服务设置对应的类 -- property nameyarn.nodemanager.aux-services.mapreduce_shuffle.class/name valueorg.apache.hadoop.mapred.ShuffleHandler/value /property !-- 每个 NodeManager 的内存上限单位 MB -- property nameyarn.nodemanager.resource.memory-mb/name value4096/value /property !-- 每个容器默认内存大小单位 MB -- property nameyarn.scheduler.minimum-allocation-mb/name value512/value nameyarn.scheduler.maximum-allocation-mb/name value4096/value /property /configurationyarn.nodemanager.aux-services 这个参数一定要设置成 mapreduce_shuffle否则你提交 MapReduce 作业时会报错Shuffle 过程中无法建立连接。它的作用是为 Map 和 Reduce 阶段之间的“洗牌”Shuffle工作提供辅助通信服务没有它Map 的结果怎么传输给 Reduce 就没人管了。内存参数我单独提一下。yarn.nodemanager.resource.memory-mb 决定每台节点最多能分配多少内存给 YARN 管理的容器。很多人在虚拟机里搭 Hadoop总共就 2G 内存却给 YARN 配了 8G结果节点还没干活就 OOM。这个数值要根据实际机器内存来设我一般建议单节点 YARN 内存不超过物理内存的 70%给系统、HDFS 和其他进程留足空间。3.5 mapred-site.xml将计算引擎切换到 YARN默认情况下 Hadoop 3.x 的 MapReduce 计算框架还是使用“本地跑”的模式如果不在 mapred-site.xml 里指定用 YARN你提交作业时只能看到 LocalJobRunner 在单机执行根本不会分布式。configuration property namemapreduce.framework.name/name valueyarn/value /property !-- 历史服务器跑完作业可以查看运行日志和统计信息 -- property namemapreduce.jobhistory.address/name valuehadoop01:10020/value /property property namemapreduce.jobhistory.webapp.address/name valuehadoop01:19888/value /property /configuration这里最核心就一行mapreduce.framework.name 设为 yarn。至于 JobHistory很多新手不知道它有什么用等到想查看某个 Job 的详细指标Map 端耗时、Reduce 端耗时、Shuffle 字节数时才发现页面打不开。如果是在真正做项目阶段JobHistory 是调优的必备工具建议从一开始就配好。4. 集群启动与验证格式化、启停命令和 Web UI 检查4.1 首次启动必须做对的两件事SSH 免密和 HDFS 格式化在启动集群之前有一件事不做不行——格式化 NameNode。这步是 Hadoop 初始化元数据存储目录的唯一途径执行后会生成一个 current 目录里面包含 VERSION 文件和 fsimage 等初始文件。# 在主节点执行确保 hadoop 命令在 PATH 中 hdfs namenode -format格式化为什么要在所有配置文件修改完之后才做因为格式化时会读取 core-site.xml 里的 hadoop.tmp.dir 和 hdfs-site.xml 里的 dfs.namenode.name.dir把当前的配置固化到元数据里。你如果格式化之后再改目录路径NameNode 启动时按新路径去找元数据找不到就会自动进入安全模式并报错。这又是一处新手高频翻车点切记格式化优先级在配置之后。格式化过程中会有一次“重新格式化”的确认提示因为你的 name.dir 目录若非空它会警告你并让你输入 Y 确认。这一点也反向说明了一个事实格式化是破坏性操作执行前务必确认你的数据已经备份或本来就是一把干净的集群。准确地说执行格式化之前还有一个前置检查/opt/hadoop/tmp 目录里不能有残留数据。如果之前格式化过又没删干净格式化会失败报错信息会提示你 “Storage directory already exists”。这不是什么问题rm -rf 那个 tmp 目录重新来一遍就行。4.2 启停脚本的正确打开方式start-dfs.sh 与 start-yarn.sh在 Hadoop 3.x 版本里启动命令是分离的。HDFS 和 YARN 是两套独立的系统分别有自己的守护进程。我习惯先启动 HDFS再启动 YARN顺序不能反。反了会出现一种情况ResourceManager 起来了但 NameNode 还没就绪YARN 的节点检查会失败之后你提交的任务会卡在 ACCEPTED 状态出不来。# 主节点执行 start-dfs.sh start-yarn.sh # 顺便把历史服务器起起来跑完作业能看日志 mapred --daemon start historyserver执行 start-dfs.sh 后脚本会读取你配置的 slavesHadoop 3.3 里这个文件名改成了 workers文件通过 SSH 登录到每台机器启动对应的 DataNode。所以这个 workers 文件一定要写对# 在 $HADOOP_HOME/etc/hadoop/workers 中 hadoop02 hadoop03如果发现 start-dfs.sh 只在主节点启动了 NameNode从节点的 DataNode 没起来第一反应去检查 workers 文件第二反应看 SSH 免密通不通第三反应是看从节点机器的时间是否同步。大部分从节点起不来的问题这三点能覆盖九成原因。启动完成后的验证环节我建议做三件事按顺序来第一用 jps 命令检查进程是否齐全# 主节点应该有 NameNode、SecondaryNameNode、ResourceManager # 从节点应该有 DataNode、NodeManager jps第二访问 Web UI 检查集群状态。NameNode 的页面在hadoop01:9870注意 3.x 的端口从 50070 变成了 9870里面能看到 HDFS 容量、存活节点数、容器状态。ResourceManager 的页面在hadoop01:8088能看到当前运行的作业队列和资源使用情况。都打不开的话查一下防火墙systemctl stop firewalld systemctl disable firewalld这个操作在做实验和内部环境可以执行生产环境就不要关防火墙了改放行指定端口更安全。第三本地跑一个最基础的 MapReduce 示例验证整个计算链路是否通# 把本地文件传到 HDFS hdfs dfs -mkdir -p /test/input hdfs dfs -put /opt/hadoop/etc/hadoop/*.xml /test/input/ # 跑官方 wordcount 示例 hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.4.jar wordcount /test/input /test/output # 查看结果 hdfs dfs -cat /test/output/part-r-00000这个 wordcount 测的不只是能跑通还能测出你的 YARN 配置、Shuffle 服务、数据副本策略在当前集群里的整体表现。第一次跑可能比较慢因为要启动 JVM 跑多个 Map/Reduce 任务耗时一两分钟很正常不要以为卡死了。4.3 单点测试流程伪分布式模式其实更适合初学者先练手我在标题里的热词里看到不少人在搜“hadoop伪分布式搭建”提一嘴。伪分布式就是在一台机器上同时跑 NameNode、DataNode、ResourceManager、NodeManager它和真正的集群差别只在于节点数量配置逻辑完全一样。如果你是第一次接触 Hadoop对多节点不太自信建议先在一台机器上把伪分布式跑通理解每个进程是干什么的、日志里看什么再扩展成三节点集群会顺利得多。伪分布式最需要注意的就是 hdfs-site.xml 中的副本数在单节点上不需要 3改成 1 就够了。否则你会看到 DataNode 里一直有 BLOCK 复制任务在排队磁盘空间也被无谓占用。另外一个常见的操作是伪分布式环境经过一段时间的试验后要升级成正式集群这时候很多人的做法是在原有数据目录上重新格式化然后改配置。我的建议是直接删掉 hadoop.tmp.dir 下的所有内容也删掉 DataNode 的数据目录重新格式化。不要想着保留旧数据伪分布式阶段的数据本来就不该拿进生产环境。5. HA 高可用搭建与 Zookeeper 整合生产环境绕不开的主题5.1 为什么要做 NameNode HA单点故障是最致命的痛点前面的配置用的是单 NameNode 架构这在学习和开发阶段完全够用但生产环境必须解决一个问题NameNode 挂了怎么办HDFS 的所有元数据都存在 NameNode 的内存里一旦它宕机整个 HDFS 就不可用了。哪怕你配了 SecondaryNameNode 做定期合并恢复也需要时间而且中间产生的增量日志有丢失风险。解决思路是部署两个甚至更多的 NameNode——Active 和 Standby。Active 负责所有读写请求Standby 实时同步 Active 的元数据状态。Active 挂了Standby 立刻接管整个过程自动完成客户端基本无感知。这就是所谓的 Hadoop HA 高可用方案。要让 Standby 能实时跟上 Active 的元数据变化最常见的方式是引入 Zookeeper 和 JournalNode 集群。原理可以这样理解Active NameNode 把每一次元数据变更比如创建目录、写文件、修改副本状态写到 JournalNode 集群的一份共享日志里Standby NameNode 不停地去读这份日志把自己同步到最新状态。而 Zookeeper 负责的是故障自动切换——它维护一个锁Active NameNode 持有锁并定期发送心跳锁一旦超时未续Zookeeper 就认为 Active 挂了把锁交给 StandbyStandby 随即提升为 Active。5.2 Zookeeper 集群安装三个奇数节点选对端口和目录Zookeeper 的集群搭建比 Hadoop 本身还简单但有几个细节很容易被忽略。我给出最小可用的配置# 下载解压后进入 conf 目录 cp zoo_sample.cfg zoo.cfg编辑 zoo.cfgtickTime2000 initLimit10 syncLimit5 dataDir/opt/zookeeper/data clientPort2181 server.1hadoop01:2888:3888 server.2hadoop02:2888:3888 server.3hadoop03:2888:3888然后在每台机器的 dataDir 下创建 myid 文件内容分别写 1、2、3与上面的 server.编号对应# hadoop01 上执行 echo 1 /opt/zookeeper/data/myid # hadoop02 上执行 echo 2 /opt/zookeeper/data/myid # hadoop03 上执行 echo 3 /opt/zookeeper/data/myid说到端口这里有个容易混淆的知识点。zoo.cfg 里每个 server 后面跟着两个端口2888 是 Zookeeper 集群内部节点之间同步数据的端口3888 是选举 leader 用的端口。这两个端口必须和 Hadoop 的配置对应上否则 Zookeeper 集群起不来HA 也宣告失败。启动和验证# 三台节点都执行 zkServer.sh start # 查看状态应该能看到一台是 leader两台是 follower zkServer.sh status看到 Mode: leader / follower 就是正常的。如果全是 standalone说明配置没生效或者 myid 文件不对优先检查 dataDir 路径的权限和 zoo.cfg 的读取位置Zookeeper 默认只认 conf/zoo.cfg你还得把改好的文件放对位置。5.3 基于 ZKFC 自动故障切换的核心配置Hadoop HA 的配置量比单节点多一些但核心思路是在原有 hdfs-site.xml 和 core-site.xml 的基础上做增量修改。在 hdfs-site.xml 里增加这些property namedfs.nameservices/name valuemycluster/value /property property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /property property namedfs.namenode.rpc-address.mycluster.nn1/name valuehadoop01:9820/value /property property namedfs.namenode.rpc-address.mycluster.nn2/name valuehadoop02:9820/value /property property namedfs.namenode.http-address.mycluster.nn1/name valuehadoop01:9870/value /property property namedfs.namenode.http-address.mycluster.nn2/name valuehadoop02:9870/value /property property namedfs.namenode.shared.edits.dir/name valueqjournal://hadoop01:8485;hadoop02:8485;hadoop03:8485/mycluster/value /property property namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property property namedfs.ha.fencing.methods/name valuesshfence/value /property property namedfs.ha.fencing.ssh.private-key-files/name value/root/.ssh/id_rsa/value /property property namedfs.journalnode.edits.dir/name value/opt/hadoop/data/journalnode/value /property然后在 hdfs-site.xml 之外core-site.xml 里还要加一行指定 zookeeper 地址property nameha.zookeeper.quorum/name valuehadoop01:2181,hadoop02:2181,hadoop03:2181/value /property这些配置里的字段名看起来很长但理解后并不难记。我总结一个规律所有带 mycluster.nn1 的参数都是在为命名空间 mycluster 下的 nn1 这个 NameNode 指定地址。mycluster 这个名称可以自定义但三台机器上的配置必须一致不能一台写 mycluster 另一台写 myha那会直接无法通信。启动顺序也要注意多了一个 JournalNode先在每台节点启动 JournalNode 进程hdfs --daemon start journalnode在 nn1 上格式化hdfs namenode -format同步元数据到 nn2在 nn2 上执行hdfs namenode -bootstrapStandby格式化 ZKFC在 nn1 上执行hdfs zkfc -formatZK依次启动 dfs 和 yarn这个流程是不能乱的。先起 JournalNode 的目的是让两个 NameNode 有共享日志的落点bootstrapStandby 是为了让 Standby 能从 Active 那里完整拷贝一份元数据不是简单地从 JournalNode 读增量日志而 zkfc -formatZK 是初始化 Zookeeper 里关于 HA 状态的记录。实操心得HA 方案搭好之后强烈建议做一次故障演练——手动 kill 掉 Active NameNode 进程观察 Standby 是否在 30 秒内自动切换。这个演练操作本身很简单但能说明你的配置到底有没有生效。我见过有人把 HA 搭好之后放了一年真到出故障那天才发现 ZKFC 根本没注册上切换失败数据全在一个假 Active 上。6. 常见问题与排查技巧实录这些坑你迟早会遇上6.1 NameNode 无法启动或一直处于安全模式这个问题的出现频率仅次于 DataNode 掉线。先说安全模式NameNode 启动时会先进入安全模式在此模式下它只能提供元数据读取服务比如 list、get 操作不允许修改操作比如 put、mkdir、delete。它会通过 DataNode 的汇报数据来确认数据块副本是否达到安全阈值。默认阈值是 99.9%如果一直达不到它会无限停留在安全模式。常见原因有两个一是 DataNode 没有全部启动或者有两个 DataNode 的副本数小于配置阈值。此时执行hdfs dfsadmin -safemode leave可以强制退出但这只是治标真正的数据不完整问题还在。二是你改了副本数或者 HDFS 存储目录后没有重启所有节点导致 DataNode 上报的数据块情况和 NameNode 期望不一致。这时候最快的处理办法是重启整个集群让 DataNode 重新注册并汇报。想查看当前安全模式状态用这条hdfs dfsadmin -safemode get想确认所有 DataNode 是否在线hdfs dfsadmin -report6.2 DataNode 反复掉线报错 “java.io.IOException: Connection refused”我在前文提过时间同步问题这里再展开讲一个隐蔽的坑DataNode 连不上 NameNode 不一定是因为网络不通很可能是 DataNode 还在用旧集群的 clusterID。HDFS 集群有一个唯一的 clusterID当你格式化 NameNode 的时候会生成一个。DataNode 启动时会读取自己数据目录里保存的 clusterID如果和你 NameNode 当前集群的 clusterID 不一致它就会拒绝注册。最常见的场景是你格式化过两次 NameNode第二次的 clusterID 变了但 DataNode 的 current 目录还在坚持旧的。解决方法是把 DataNode 数据目录下的 current 目录删掉让 DataNode 重新初始化# 在每一台出问题的从节点上执行 rm -rf /opt/hadoop/data/datanode/current # 重启该从节点的 DataNode hdfs --daemon stop datanode hdfs --daemon start datanodeDataNode 重新注册时会向 NameNode 申请当前的 clusterID 和版本信息所以不用重新格式化 NameNode。这个操作在生产环境要十分谨慎毕竟它删的是本地数据块好在 Hadoop 的副本机制保证了只要其他节点有备份数据不会丢。6.3 YARN 提交作业卡在 ACCEPTED或者 Map 任务一直失败这个问题的根源大概率是内存配置不匹配。你可以在 ResourceManager 的 Web UI 里看到每个运行中 Job 的内存请求然后用free -h查看节点实际可用内存检查两者是否冲突。另一个隐藏较深的问题是 mapreduce.map.memory.mb 默认值 1024MB而 yarn.nodemanager.resource.memory-mb 设成了 2048MB。这种情况下一个节点上只能跑 2 个 Map 任务而你有 4 个 Map 任务的并发需求系统会把后 2 个排队。如果物理内存本身不够还会直接跑死节点。老手通常会把 mapreduce.map.memory.mb 和 reduce 版本调到 2048 或 3072并给 NodeManager 留更多内存但新手还是按默认来比较稳妥等熟悉了再调。如果遇到 Map 任务反复执行失败去日志里搜索 “Container killed on request”这是典型的物理内存超限被 NodeManager 杀掉的信号。这种场景下要调整 yarn.nodemanager.vmem-check-enabled 为 false或者直接增大内存配置。我一般倾向设置 vmem-check-enabled 为 false因为虚拟内存的计算在容器化环境里很容易误报。6.4 数据倾斜这个经典问题搭完集群后必会遇到虽然标题是集群搭建但搭完集群后第一个要遇到的开发问题就是数据倾斜。我在热词里看到“网约车大数据综合项目——数据清洗”“基于 Hadoop 的交通信息分析系统”这类实战场景这种数据处理任务几乎都会碰上 key 分布严重不均衡的情况。比如你按城市分区统计北京的数据量可能是二三线城市的几十倍那负责北京分区的 Reduce 任务就会成为整个作业的瓶颈。讲这类问题的排查方法时我一般分三步第一步看出没出问题。MR 任务的 Reduce 端完成度长期停在 33% 不动其他任务都跑完了只有一两个还在挣扎。第二步判断倾斜原因。是某个 key 特别多还是分区函数设计不合理或者是数据在 Shuffle 阶段没有做预处理聚合。用日志和 counter 来辅助判断关键是看每个 Reduce 拿到的数据量是否严重不均衡。第三步对症下药。常用手段是加盐salting——给热点 key 加随机前缀拆散到多个分区处理完再合并或者在 Map 端做 Combiner 预聚合减少 Shuffle 数据量。面试问数据倾斜怎么解决重点答这两招就够了。核心原理就是让每个分区的数据量相对均匀Reduce 就不会有人闲死有人忙死。6.5 常见问题速查表现象可能原因首选排查命令/操作NameNode 起不来tmp 目录被清、clusterID 不符tail -f $HADOOP_LOG_DIR/hadoop-root-namenode-hadoop01.logDataNode 一直掉线时间不同步、免密失效ntpdate 同步时间ssh hadoop02 date 验证作业卡在 ACCEPTEDResourceManager 内存不足查看 RM 页面容量检查每个 NodeManager 上报的资源Web UI 打不开防火墙未关、进程未启动systemctl stop firewalldjps 查进程磁盘空间飙升Block 副本冗余过多hdfs dfsadmin -report 查看空间和各节点使用率Shuffle 阶段报错未配置 aux-services检查 yarn-site.xml重启 NodeManager上传文件报 Quota 超限HDFS 目录配额满hdfs dfs -count -h /路径 查看配额挂载新磁盘后 DataNode 崩溃磁盘格式不对、目录不存在先创建目录并挂载再启动 DataNode7. 从集群到项目Hadoop 生态里下一步该怎么走集群搭好、WordCount 跑通很多人就以为“学完了”。这里必须泼一盆冷水Hadoop 本身只是一个分布式存储与计算底座它不能直接解决你的业务问题。你真正要写的是处理业务数据的计算逻辑而这套逻辑通常不是直接用 MapReduce 去写的。以我之前做过的一个“基于 Hadoop 的网约车订单数据分析系统”为例整体链路是这样的数据源是数千万条订单日志放在 HDFS 里按天分目录存储第一层清洗用 Hive 写 SQL做字段提取、格式转换、去重第二层按城市和时段聚合统计用 Spark SQL 跑比纯 MapReduce 快一个量级最后结果落地到 MySQL用 Flask ECharts 做可视化展示这个链路的核心思想是Hadoop 负责存储和底层的资源调度Hive 负责把 SQL 转成 MR 或 Spark 作业Spark 负责更复杂的计算MySQL 做结果的服务端前端负责呈现。你要想把这些串起来需要的不是一个“会启动集群”的人而是一个“懂数据全链路”的人。所以我的建议是集群搭建完成后不要满足于现状要立刻进入这三个方向一是学会用 Hive。这是数仓建模的基础面试必考。重点是掌握内外部表的区别、分区和分桶的原理、以及如何写出能走 MapReduce 的高效 SQL。二是学 Spark。Spark 现在已经是批处理的主流引擎它的 RDD、DataFrame 和 SQL 三层 API 要搞清楚尤其在 Spark on YARN 模式下怎么提交作业、怎么调内存和并行度都是实操中很常见的问题。三是学一个可视化框架。ECharts 本身轻量易上手配合 Flask 写接口能把 Hive 或者 Spark 算出的结果展示成图表。这类“大数据 可视化”的组合是很多毕业设计和综合项目的标配。另外一个值得尝试的方向是把自己搭的集群容器化。现在用 Docker 跑 Hadoop 镜像、K8s 调度 Hadoop 任务也越来越普遍你可以试着写个 Dockerfile 把 Hadoop 集群打进去再用 docker-compose 一键拉起三节点。这个过程会让你对端口、目录、环境变量这些细节的理解再上一个台阶。8. 版本升级和集群扩展的思路集群不是搭完一次就一劳永逸的。你在跑数据的过程中会遇到两类问题一是单台机器磁盘不够了二是算力不够了。第一种的解法是往 DataNode 上加磁盘改 dfs.datanode.data.dir 参数把新目录加进去然后滚动重启 DataNode。第二种的解法就是加节点。加 DataNode 节点的流程其实非常简单新机器按第 2 节的步骤设置 hosts、JDK、免密解压 Hadoop 安装包把主节点的 core-site.xml、hdfs-site.xml、yarn-site.xml 整个拷贝到新机器把新机器的主机名写进主节点的 workers 文件启动新节点上的 DataNode 和 NodeManagerhdfs --daemon start datanode yarn --daemon start nodemanager不需要重新格式化 NameNode新节点会自动向现有集群注册。如果没生效去 DataNode 日志里看是不是 clusterID 不匹配解决办法参照第 6.2 节删掉 current 目录重启。Hadoop 3.x 还引进了“NameNode 目录联邦”这样的新特性本质上允许你为不同的业务域创建多个独立的 NameNode 命名空间让 HDFS 的元数据压力分散。如果是做超大规模集群值得研究。但个人学习和中小项目把单 NameNode 调优到极致比盲目引入联邦更实际。关于版本升级我自己的体会是不要追新。Hadoop 社区出新版本的速度非常快但生态里的 Hive、Spark、HBase 等组件的兼容性往往滞后。生产环境用稳定版比用新版重要一万倍。你可以在测试集群上验证新版特性但生产环境尽量按“组件版本矩阵”来规划确认所有组件的版本都兼容后再动。最后再说几句我的体会写了这么多其实核心就一句话Hadoop 集群搭建是每个大数据人的基本功但真正拉开差距的是你对“为什么这么搭”的理解深度。你可能在面试中被问到的不是某某命令怎么写而是“HDFS 为什么不适合存小文件”“NameNode 元数据存内存会不会有瓶颈”“YARN 的内存模型如何规划”这些问题的答案其实都藏在你搭建集群时的每一个配置决策里。从我的经验看刚入门的人最值得花时间的地方有三块一是把 HDFS 的工作机制研究透包括块的读写流程、副本放置策略、安全模式机制二是把 YARN 的资源调度流程理清楚从提交作业到分配容器、执行任务的全过程三是亲手把集群拆了重建几遍这种“破坏性训练”比看十遍教程都有用。如果这篇文章能帮你把集群从 0 到 1 搭起来并且看懂每个参数背后的逻辑那就不白写。等你把 WordCount 跑通的那一刻恭喜你你已经是分布式计算世界里的人了。剩下的路就是不停地写作业、跑数据、看日志、调参数日复一日地在这套系统的边界上试探。也正是这个过程才会让你真正理解什么叫做“大数据”。 Hadoop集群搭建核心要点：从环境配置到HA高可用实战
1. 从零开始搭建 Hadoop 集群前必须先想清楚这几件事先聊点实在的。很多人一上来就搜“Hadoop 集群搭建”照着网上教程复制粘贴结果不是这里报错就是那里起不来折腾一两天最后把系统重装了。我当年也干过这种事后来带过几个实习生看他们踩的坑基本一模一样。所以这篇东西我不打算只给你一份“照着敲就行”的命令清单而是想把背后的逻辑、容易翻车的点、以及我实际生产环境中用到的经验一起讲清楚。先说结论Hadoop 集群搭建本身不难难的是你对它有没有一个全局认知。你得清楚自己在搭什么、为什么要这么搭、每个配置文件动了哪根神经。从应用场景来看Hadoop 集群搭建是几乎所有大数据项目的底座。不管你是要做网约车订单数据的清洗分析、校园大数据可视化、交通信息分析系统还是 Spark 离线计算、Hive 数仓建设第一步永远是先把 HDFS 和 YARN 跑起来。我见过不少毕业设计选“基于 Hadoop 的某某分析系统”的同学上来就想写代码结果连 HDFS 的存储机制都没搞明白最后数据往里一丢就 OOM内存溢出。这个思路必须纠正。所以这篇博文适合谁想系统学大数据的学生、要搭环境做毕设或比赛的开发者、准备跳槽大数据开发岗需要面试干货的工程师。如果你是完全没接触过 Linux 的新手建议先补一下基本命令再来看否则有些操作你会觉得像在看天书。2. 环境准备与版本选型这一步偷懒后面全是坑2.1 硬件与操作系统千万别用 Windows 当主战场先说最容易被忽视的问题操作系统。Hadoop 从设计上就跑在 Linux 上虽然 Windows 上用 IDEA 也能开发调试但你要是想在 Windows 上搭真正的多节点集群那就是给自己上刑。我的建议很直接学习/测试环境本地装 VMware 或 VirtualBox建三台 CentOS 7.9 虚拟机内存至少 2GB/台4GB 更舒服用 NAT 或桥接模式都行。生产/准生产环境建议物理机或云主机规格至少 8 核 16G 起步磁盘最好是多块让数据盘和系统盘分开。操作系统版本上CentOS 7.x 是绝大多数教程的选择也是企业用得最多的。它够稳、软件源全、踩坑资料最多。虽然 CentOS 8 已经停止维护但大数据生态对它的依赖不会因为你换了新版就瞬间适配所以 CentOS 7 依然是当前阶段最稳的底座。如果你愿意折腾Ubuntu 20.04 也可以只是很多调优参数和文件路径会和 CentOS 有差异新手容易混乱。注意一定要统一所有节点的时间和时区。Hadoop 内部对时间非常敏感时钟漂移会导致认证失败、心跳异常等一堆莫名其妙的问题。我吃过这个亏集群三个节点时间差了 30 秒DataNode 反复掉线排查了大半天最后发现是虚拟机挂起恢复后时钟没同步。同步方式很简单装个 ntpdate 然后写个定时任务就行# 所有节点执行 yum install -y ntpdate ntpdate -u ntp.aliyun.com # 写定时任务每 10 分钟同步一次 echo */10 * * * * /usr/sbin/ntpdate -u ntp.aliyun.com /dev/null 21 /var/spool/cron/root2.2 软件版本搭配JDK、Hadoop、Zookeeper 的兼容性盘点版本选型是大数据入门的第一道坎也是面试爱问的点。我直接给出经过验证的组合照抄即可组件版本备注CentOS7.9最小化安装即可JDK8u202 或 1.8.0_301Hadoop 3.x 要求 JDK 8JDK 11 也能跑但生态里很多工具对 8 的兼容性最好Hadoop3.3.4 或 3.2.43.x 系列较稳3.3.x 对新手更友好Zookeeper3.6.3做 HA 高可用用单节点测试可不装JDK 这里多说一句千万别用默认的 OpenJDK 图省事从 Oracle JDK 官网下载 .tar.gz 版本自己解压配置 JAVA_HOME 最干净。OpenJDK 在个别场景下会出现一些诡异问题比如 SSL 握手异常、加密算法不支持等。反正都是免费的何苦给自己埋雷。Hadoop 版本上3.1.x 和 3.3.x 我都深度用过当前推荐 3.3.4。它默认支持 NameNode 联邦的改进、YARN 的 Capacity Scheduler 多队列能力也更完善而且对 S3 等云存储的适配更好。如果是学生做毕设3.3.4 完全够用。2.3 网络规划与主机名设置提前规划节点角色不然后患无穷节点规划是整个搭建过程最关键的一步没有之一。我建议三台机器一主两从的经典架构主机名IP 示例角色分配hadoop01192.168.100.101NameNode、ResourceManager、SecondaryNameNodehadoop02192.168.100.102DataNode、NodeManagerhadoop03192.168.100.103DataNode、NodeManager为什么是三台而不是两台因为 HDFS 默认副本数是 3两份就达不到备份效果四份以上又浪费存储。学习阶段三台能让你完整体验副本机制和机架感知面试被问到“为什么副本数是 3”的时候你也能结合实际说两句。设置主机名和 hosts 映射# 三台机器分别执行 hostnamectl set-hostname hadoop01 # 然后编辑 /etc/hosts三台机器内容一致 cat /etc/hosts EOF 192.168.100.101 hadoop01.hadoop.com hadoop01 192.168.100.102 hadoop02.hadoop.com hadoop02 192.168.100.103 hadoop03.hadoop.com hadoop03 EOF这里必须强调hosts 文件的顺序和内容一定不要乱。集群内所有节点的一致性至关重要特别是 hosts、JAVA_HOME 路径、Hadoop 解压路径这些必须统一。我遇到过只改了主节点的 /etc/hosts从节点还是旧 IP 映射结果从节点起 DataNode 时一直连不上 NameNode报错信息看了半天才反应过来。最后配置三台机器之间的 SSH 免密登录。这一步是为了后续脚本化管理集群做准备也是 Hadoop 启动脚本自身依赖的基础start-dfs.sh 会通过 SSH 远程启动各节点的进程# 每个节点生成密钥 ssh-keygen -t rsa -P -f ~/.ssh/id_rsa # 把公钥分发到三台机器的 authorized_keys 中 ssh-copy-id hadoop01 ssh-copy-id hadoop02 ssh-copy-id hadoop03 # 验证免密 ssh hadoop02 date实操心得免密一定要双向配好别只在主节点配到从节点。你后面用 xsync 脚本分发配置文件的时候从节点如果还要输入密码整个流程的自动化就断了。3. 核心配置文件逐项拆解每个参数背后的原理说明3.1 为什么 Hadoop 的配置在 XML 里而不是命令行很多人第一次打开 core-site.xml 会困惑这么重要的系统配置为啥不写在 yml 或者 properties 里要用 XML我理解这件事的核心逻辑是这样的Hadoop 的定位是分布式框架底层用 Java 写Java 生态里 XML 的 DOM/SAX 解析非常成熟复杂的层级结构表达能力强而且 Hadoop 设计了“默认配置 用户覆盖”的机制——所有参数在 jar 包里有默认值你写的 core-site.xml 只是覆盖你关心的那部分改坏了也容易恢复。这种设计最大的好处是你不需要理解每个参数的含义才能跑起来系统给你的默认值在绝大多数场景是能工作的。你只需要关注几个核心参数把它们调对就够了。配置文件总共就那么几个分布在 $HADOOP_HOME/etc/hadoop/ 目录下按功能可以归成三类全局通用配置core-site.xml决定文件系统访问方式、I/O 调优等HDFS 配置hdfs-site.xml这是重头戏负责管理各个守护进程的职责和存储行为计算调度配置yarn-site.xml 和 mapred-site.xml决定谁来做分布式计算和调度3.2 core-site.xml 详解默认文件系统到底意味着什么core-site.xml 是其他所有配置的基础。我先给你看我实际生产里用的精简版configuration property namefs.defaultFS/name valuehdfs://hadoop01:9820/value /property property namehadoop.tmp.dir/name value/opt/hadoop/tmp/value /property property namehadoop.http.staticuser.user/name valueroot/value /property /configuration第一个参数 fs.defaultFS 是灵魂所在。它决定了 HDFS 的入口地址也就是客户端去哪里找 NameNode。学习阶段你可以写成 file:/// 用本地文件系统但想体验真正的分布式存储必须改成 hdfs:// 协议。后面的端口号 9820旧版本是 90003.x 改成了 9820是 NameNode 的 RPC 通信端口DataNode 和客户端全靠这个端口和 NameNode 保持心跳、读写元数据。第二个参数 hadoop.tmp.dir 是大多数新手翻车的重灾区。它默认为 /tmp/hadoop-${user.name}而 /tmp 目录在 Linux 启动后会被清理。如果你没有改这个路径重启机器后 NameNode 的元数据目录就没了格式化又不知道格式化哪份集群直接哑火。所以我建议把它指定到一个独立的数据盘比如 /opt/hadoop/tmp既安全又方便备份。注意hadoop.tmp.dir 一旦确定并格式化后就不要再改路径。改了就等于告诉 NameNode 换了个新的元数据存储位置它会认为集群是初始化状态需要重新格式化而格式化会清空所有元数据相当于数据丢了。这个坑无数人踩过我亲眼见过同事因为想给 tmp 目录换大磁盘直接把整个集群数据弄丢。3.3 hdfs-site.xml 详解副本数、NameNode 和 DataNode 的存储目录hdfs-site.xml 是 Hadoop 集群的“宪法”里面定义的每一个属性都直接影响数据的安全性和集群性能。我这里给一份我平时用得最多的配置configuration !-- 副本数默认就是3也可以不写 -- property namedfs.replication/name value3/value /property !-- NameNode 元数据存储目录 -- property namedfs.namenode.name.dir/name valuefile:///opt/hadoop/data/namenode/value /property !-- DataNode 数据存储目录逗号分隔多磁盘可以写多个 -- property namedfs.datanode.data.dir/name valuefile:///opt/hadoop/data/datanode/value /property !-- 关闭集群时的安全模式自动进入测试环境可以关掉 -- property namedfs.namenode.safemode.threshold-pct/name value1.0f/value /property !-- 设置SecondaryNameNode的地址 -- property namedfs.namenode.secondary.http-address/name valuehadoop01:9868/value /property /configurationdfs.replication 是面试里的高频题为什么默认是 3原因很简单——它兼顾了数据可靠性和存储成本。一份原始数据一份放在同一个机架的另一个节点防止单机器故障第三份放到不同机架防止整个机架断电或交换机故障这样任何一个节点或机架出问题数据都能恢复。dfs.namenode.name.dir 和 dfs.datanode.data.dir 这两个参数要重点解释。它们决定数据到底落在哪块磁盘上。生产环境我强烈建议你把这两项配置成多个目录用逗号分隔file:///data1/hadoop/namenode,file:///data2/hadoop/namenode这样做的原理是 Hadoop 会对这些目录做镜像写入——同一份元数据同时写到两块物理磁盘上单块磁盘坏了不至于全丢。DataNode 则是轮询写入策略数据文件打到不同磁盘上既充分利用磁盘 IO 和空间又降低了单盘故障的损失。还有一点大家容易忽略SecondaryNameNode 不是 NameNode 的备用节点。它的作用是定期合并 NameNode 的编辑日志edits和镜像文件fsimage减轻 NameNode 重启时的恢复压力。如果主 NameNode 挂了SecondaryNameNode 不能立刻顶上但它有最近一次的合并结果可以配合日志尽量恢复。这个知识点很多教程说不清楚面试也爱挖坑你搞明白了会很有优势。3.4 yarn-site.xml 详解ResourceManager 和 NodeManager 的协作机制YARN 是 Hadoop 的资源调度平台。我在给别人讲 YARN 的时候喜欢打一个比方YARN 就像一个酒店的管理系统ResourceManager 是前台大堂经理NodeManager 是各楼层的服务员你的 MapReduce 任务就是住店的客人。客人来了先找大堂经理要房间申请资源经理查一下哪个楼层有空房通过心跳信息掌握各节点资源情况然后安排服务员带客人入住分配容器。看配置configuration !-- 启用 YARN 的 ResourceManager -- property nameyarn.resourcemanager.hostname/name valuehadoop01/value /property !-- NodeManager 附属服务 -- property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property !-- 为辅助服务设置对应的类 -- property nameyarn.nodemanager.aux-services.mapreduce_shuffle.class/name valueorg.apache.hadoop.mapred.ShuffleHandler/value /property !-- 每个 NodeManager 的内存上限单位 MB -- property nameyarn.nodemanager.resource.memory-mb/name value4096/value /property !-- 每个容器默认内存大小单位 MB -- property nameyarn.scheduler.minimum-allocation-mb/name value512/value nameyarn.scheduler.maximum-allocation-mb/name value4096/value /property /configurationyarn.nodemanager.aux-services 这个参数一定要设置成 mapreduce_shuffle否则你提交 MapReduce 作业时会报错Shuffle 过程中无法建立连接。它的作用是为 Map 和 Reduce 阶段之间的“洗牌”Shuffle工作提供辅助通信服务没有它Map 的结果怎么传输给 Reduce 就没人管了。内存参数我单独提一下。yarn.nodemanager.resource.memory-mb 决定每台节点最多能分配多少内存给 YARN 管理的容器。很多人在虚拟机里搭 Hadoop总共就 2G 内存却给 YARN 配了 8G结果节点还没干活就 OOM。这个数值要根据实际机器内存来设我一般建议单节点 YARN 内存不超过物理内存的 70%给系统、HDFS 和其他进程留足空间。3.5 mapred-site.xml将计算引擎切换到 YARN默认情况下 Hadoop 3.x 的 MapReduce 计算框架还是使用“本地跑”的模式如果不在 mapred-site.xml 里指定用 YARN你提交作业时只能看到 LocalJobRunner 在单机执行根本不会分布式。configuration property namemapreduce.framework.name/name valueyarn/value /property !-- 历史服务器跑完作业可以查看运行日志和统计信息 -- property namemapreduce.jobhistory.address/name valuehadoop01:10020/value /property property namemapreduce.jobhistory.webapp.address/name valuehadoop01:19888/value /property /configuration这里最核心就一行mapreduce.framework.name 设为 yarn。至于 JobHistory很多新手不知道它有什么用等到想查看某个 Job 的详细指标Map 端耗时、Reduce 端耗时、Shuffle 字节数时才发现页面打不开。如果是在真正做项目阶段JobHistory 是调优的必备工具建议从一开始就配好。4. 集群启动与验证格式化、启停命令和 Web UI 检查4.1 首次启动必须做对的两件事SSH 免密和 HDFS 格式化在启动集群之前有一件事不做不行——格式化 NameNode。这步是 Hadoop 初始化元数据存储目录的唯一途径执行后会生成一个 current 目录里面包含 VERSION 文件和 fsimage 等初始文件。# 在主节点执行确保 hadoop 命令在 PATH 中 hdfs namenode -format格式化为什么要在所有配置文件修改完之后才做因为格式化时会读取 core-site.xml 里的 hadoop.tmp.dir 和 hdfs-site.xml 里的 dfs.namenode.name.dir把当前的配置固化到元数据里。你如果格式化之后再改目录路径NameNode 启动时按新路径去找元数据找不到就会自动进入安全模式并报错。这又是一处新手高频翻车点切记格式化优先级在配置之后。格式化过程中会有一次“重新格式化”的确认提示因为你的 name.dir 目录若非空它会警告你并让你输入 Y 确认。这一点也反向说明了一个事实格式化是破坏性操作执行前务必确认你的数据已经备份或本来就是一把干净的集群。准确地说执行格式化之前还有一个前置检查/opt/hadoop/tmp 目录里不能有残留数据。如果之前格式化过又没删干净格式化会失败报错信息会提示你 “Storage directory already exists”。这不是什么问题rm -rf 那个 tmp 目录重新来一遍就行。4.2 启停脚本的正确打开方式start-dfs.sh 与 start-yarn.sh在 Hadoop 3.x 版本里启动命令是分离的。HDFS 和 YARN 是两套独立的系统分别有自己的守护进程。我习惯先启动 HDFS再启动 YARN顺序不能反。反了会出现一种情况ResourceManager 起来了但 NameNode 还没就绪YARN 的节点检查会失败之后你提交的任务会卡在 ACCEPTED 状态出不来。# 主节点执行 start-dfs.sh start-yarn.sh # 顺便把历史服务器起起来跑完作业能看日志 mapred --daemon start historyserver执行 start-dfs.sh 后脚本会读取你配置的 slavesHadoop 3.3 里这个文件名改成了 workers文件通过 SSH 登录到每台机器启动对应的 DataNode。所以这个 workers 文件一定要写对# 在 $HADOOP_HOME/etc/hadoop/workers 中 hadoop02 hadoop03如果发现 start-dfs.sh 只在主节点启动了 NameNode从节点的 DataNode 没起来第一反应去检查 workers 文件第二反应看 SSH 免密通不通第三反应是看从节点机器的时间是否同步。大部分从节点起不来的问题这三点能覆盖九成原因。启动完成后的验证环节我建议做三件事按顺序来第一用 jps 命令检查进程是否齐全# 主节点应该有 NameNode、SecondaryNameNode、ResourceManager # 从节点应该有 DataNode、NodeManager jps第二访问 Web UI 检查集群状态。NameNode 的页面在hadoop01:9870注意 3.x 的端口从 50070 变成了 9870里面能看到 HDFS 容量、存活节点数、容器状态。ResourceManager 的页面在hadoop01:8088能看到当前运行的作业队列和资源使用情况。都打不开的话查一下防火墙systemctl stop firewalld systemctl disable firewalld这个操作在做实验和内部环境可以执行生产环境就不要关防火墙了改放行指定端口更安全。第三本地跑一个最基础的 MapReduce 示例验证整个计算链路是否通# 把本地文件传到 HDFS hdfs dfs -mkdir -p /test/input hdfs dfs -put /opt/hadoop/etc/hadoop/*.xml /test/input/ # 跑官方 wordcount 示例 hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.4.jar wordcount /test/input /test/output # 查看结果 hdfs dfs -cat /test/output/part-r-00000这个 wordcount 测的不只是能跑通还能测出你的 YARN 配置、Shuffle 服务、数据副本策略在当前集群里的整体表现。第一次跑可能比较慢因为要启动 JVM 跑多个 Map/Reduce 任务耗时一两分钟很正常不要以为卡死了。4.3 单点测试流程伪分布式模式其实更适合初学者先练手我在标题里的热词里看到不少人在搜“hadoop伪分布式搭建”提一嘴。伪分布式就是在一台机器上同时跑 NameNode、DataNode、ResourceManager、NodeManager它和真正的集群差别只在于节点数量配置逻辑完全一样。如果你是第一次接触 Hadoop对多节点不太自信建议先在一台机器上把伪分布式跑通理解每个进程是干什么的、日志里看什么再扩展成三节点集群会顺利得多。伪分布式最需要注意的就是 hdfs-site.xml 中的副本数在单节点上不需要 3改成 1 就够了。否则你会看到 DataNode 里一直有 BLOCK 复制任务在排队磁盘空间也被无谓占用。另外一个常见的操作是伪分布式环境经过一段时间的试验后要升级成正式集群这时候很多人的做法是在原有数据目录上重新格式化然后改配置。我的建议是直接删掉 hadoop.tmp.dir 下的所有内容也删掉 DataNode 的数据目录重新格式化。不要想着保留旧数据伪分布式阶段的数据本来就不该拿进生产环境。5. HA 高可用搭建与 Zookeeper 整合生产环境绕不开的主题5.1 为什么要做 NameNode HA单点故障是最致命的痛点前面的配置用的是单 NameNode 架构这在学习和开发阶段完全够用但生产环境必须解决一个问题NameNode 挂了怎么办HDFS 的所有元数据都存在 NameNode 的内存里一旦它宕机整个 HDFS 就不可用了。哪怕你配了 SecondaryNameNode 做定期合并恢复也需要时间而且中间产生的增量日志有丢失风险。解决思路是部署两个甚至更多的 NameNode——Active 和 Standby。Active 负责所有读写请求Standby 实时同步 Active 的元数据状态。Active 挂了Standby 立刻接管整个过程自动完成客户端基本无感知。这就是所谓的 Hadoop HA 高可用方案。要让 Standby 能实时跟上 Active 的元数据变化最常见的方式是引入 Zookeeper 和 JournalNode 集群。原理可以这样理解Active NameNode 把每一次元数据变更比如创建目录、写文件、修改副本状态写到 JournalNode 集群的一份共享日志里Standby NameNode 不停地去读这份日志把自己同步到最新状态。而 Zookeeper 负责的是故障自动切换——它维护一个锁Active NameNode 持有锁并定期发送心跳锁一旦超时未续Zookeeper 就认为 Active 挂了把锁交给 StandbyStandby 随即提升为 Active。5.2 Zookeeper 集群安装三个奇数节点选对端口和目录Zookeeper 的集群搭建比 Hadoop 本身还简单但有几个细节很容易被忽略。我给出最小可用的配置# 下载解压后进入 conf 目录 cp zoo_sample.cfg zoo.cfg编辑 zoo.cfgtickTime2000 initLimit10 syncLimit5 dataDir/opt/zookeeper/data clientPort2181 server.1hadoop01:2888:3888 server.2hadoop02:2888:3888 server.3hadoop03:2888:3888然后在每台机器的 dataDir 下创建 myid 文件内容分别写 1、2、3与上面的 server.编号对应# hadoop01 上执行 echo 1 /opt/zookeeper/data/myid # hadoop02 上执行 echo 2 /opt/zookeeper/data/myid # hadoop03 上执行 echo 3 /opt/zookeeper/data/myid说到端口这里有个容易混淆的知识点。zoo.cfg 里每个 server 后面跟着两个端口2888 是 Zookeeper 集群内部节点之间同步数据的端口3888 是选举 leader 用的端口。这两个端口必须和 Hadoop 的配置对应上否则 Zookeeper 集群起不来HA 也宣告失败。启动和验证# 三台节点都执行 zkServer.sh start # 查看状态应该能看到一台是 leader两台是 follower zkServer.sh status看到 Mode: leader / follower 就是正常的。如果全是 standalone说明配置没生效或者 myid 文件不对优先检查 dataDir 路径的权限和 zoo.cfg 的读取位置Zookeeper 默认只认 conf/zoo.cfg你还得把改好的文件放对位置。5.3 基于 ZKFC 自动故障切换的核心配置Hadoop HA 的配置量比单节点多一些但核心思路是在原有 hdfs-site.xml 和 core-site.xml 的基础上做增量修改。在 hdfs-site.xml 里增加这些property namedfs.nameservices/name valuemycluster/value /property property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /property property namedfs.namenode.rpc-address.mycluster.nn1/name valuehadoop01:9820/value /property property namedfs.namenode.rpc-address.mycluster.nn2/name valuehadoop02:9820/value /property property namedfs.namenode.http-address.mycluster.nn1/name valuehadoop01:9870/value /property property namedfs.namenode.http-address.mycluster.nn2/name valuehadoop02:9870/value /property property namedfs.namenode.shared.edits.dir/name valueqjournal://hadoop01:8485;hadoop02:8485;hadoop03:8485/mycluster/value /property property namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property property namedfs.ha.fencing.methods/name valuesshfence/value /property property namedfs.ha.fencing.ssh.private-key-files/name value/root/.ssh/id_rsa/value /property property namedfs.journalnode.edits.dir/name value/opt/hadoop/data/journalnode/value /property然后在 hdfs-site.xml 之外core-site.xml 里还要加一行指定 zookeeper 地址property nameha.zookeeper.quorum/name valuehadoop01:2181,hadoop02:2181,hadoop03:2181/value /property这些配置里的字段名看起来很长但理解后并不难记。我总结一个规律所有带 mycluster.nn1 的参数都是在为命名空间 mycluster 下的 nn1 这个 NameNode 指定地址。mycluster 这个名称可以自定义但三台机器上的配置必须一致不能一台写 mycluster 另一台写 myha那会直接无法通信。启动顺序也要注意多了一个 JournalNode先在每台节点启动 JournalNode 进程hdfs --daemon start journalnode在 nn1 上格式化hdfs namenode -format同步元数据到 nn2在 nn2 上执行hdfs namenode -bootstrapStandby格式化 ZKFC在 nn1 上执行hdfs zkfc -formatZK依次启动 dfs 和 yarn这个流程是不能乱的。先起 JournalNode 的目的是让两个 NameNode 有共享日志的落点bootstrapStandby 是为了让 Standby 能从 Active 那里完整拷贝一份元数据不是简单地从 JournalNode 读增量日志而 zkfc -formatZK 是初始化 Zookeeper 里关于 HA 状态的记录。实操心得HA 方案搭好之后强烈建议做一次故障演练——手动 kill 掉 Active NameNode 进程观察 Standby 是否在 30 秒内自动切换。这个演练操作本身很简单但能说明你的配置到底有没有生效。我见过有人把 HA 搭好之后放了一年真到出故障那天才发现 ZKFC 根本没注册上切换失败数据全在一个假 Active 上。6. 常见问题与排查技巧实录这些坑你迟早会遇上6.1 NameNode 无法启动或一直处于安全模式这个问题的出现频率仅次于 DataNode 掉线。先说安全模式NameNode 启动时会先进入安全模式在此模式下它只能提供元数据读取服务比如 list、get 操作不允许修改操作比如 put、mkdir、delete。它会通过 DataNode 的汇报数据来确认数据块副本是否达到安全阈值。默认阈值是 99.9%如果一直达不到它会无限停留在安全模式。常见原因有两个一是 DataNode 没有全部启动或者有两个 DataNode 的副本数小于配置阈值。此时执行hdfs dfsadmin -safemode leave可以强制退出但这只是治标真正的数据不完整问题还在。二是你改了副本数或者 HDFS 存储目录后没有重启所有节点导致 DataNode 上报的数据块情况和 NameNode 期望不一致。这时候最快的处理办法是重启整个集群让 DataNode 重新注册并汇报。想查看当前安全模式状态用这条hdfs dfsadmin -safemode get想确认所有 DataNode 是否在线hdfs dfsadmin -report6.2 DataNode 反复掉线报错 “java.io.IOException: Connection refused”我在前文提过时间同步问题这里再展开讲一个隐蔽的坑DataNode 连不上 NameNode 不一定是因为网络不通很可能是 DataNode 还在用旧集群的 clusterID。HDFS 集群有一个唯一的 clusterID当你格式化 NameNode 的时候会生成一个。DataNode 启动时会读取自己数据目录里保存的 clusterID如果和你 NameNode 当前集群的 clusterID 不一致它就会拒绝注册。最常见的场景是你格式化过两次 NameNode第二次的 clusterID 变了但 DataNode 的 current 目录还在坚持旧的。解决方法是把 DataNode 数据目录下的 current 目录删掉让 DataNode 重新初始化# 在每一台出问题的从节点上执行 rm -rf /opt/hadoop/data/datanode/current # 重启该从节点的 DataNode hdfs --daemon stop datanode hdfs --daemon start datanodeDataNode 重新注册时会向 NameNode 申请当前的 clusterID 和版本信息所以不用重新格式化 NameNode。这个操作在生产环境要十分谨慎毕竟它删的是本地数据块好在 Hadoop 的副本机制保证了只要其他节点有备份数据不会丢。6.3 YARN 提交作业卡在 ACCEPTED或者 Map 任务一直失败这个问题的根源大概率是内存配置不匹配。你可以在 ResourceManager 的 Web UI 里看到每个运行中 Job 的内存请求然后用free -h查看节点实际可用内存检查两者是否冲突。另一个隐藏较深的问题是 mapreduce.map.memory.mb 默认值 1024MB而 yarn.nodemanager.resource.memory-mb 设成了 2048MB。这种情况下一个节点上只能跑 2 个 Map 任务而你有 4 个 Map 任务的并发需求系统会把后 2 个排队。如果物理内存本身不够还会直接跑死节点。老手通常会把 mapreduce.map.memory.mb 和 reduce 版本调到 2048 或 3072并给 NodeManager 留更多内存但新手还是按默认来比较稳妥等熟悉了再调。如果遇到 Map 任务反复执行失败去日志里搜索 “Container killed on request”这是典型的物理内存超限被 NodeManager 杀掉的信号。这种场景下要调整 yarn.nodemanager.vmem-check-enabled 为 false或者直接增大内存配置。我一般倾向设置 vmem-check-enabled 为 false因为虚拟内存的计算在容器化环境里很容易误报。6.4 数据倾斜这个经典问题搭完集群后必会遇到虽然标题是集群搭建但搭完集群后第一个要遇到的开发问题就是数据倾斜。我在热词里看到“网约车大数据综合项目——数据清洗”“基于 Hadoop 的交通信息分析系统”这类实战场景这种数据处理任务几乎都会碰上 key 分布严重不均衡的情况。比如你按城市分区统计北京的数据量可能是二三线城市的几十倍那负责北京分区的 Reduce 任务就会成为整个作业的瓶颈。讲这类问题的排查方法时我一般分三步第一步看出没出问题。MR 任务的 Reduce 端完成度长期停在 33% 不动其他任务都跑完了只有一两个还在挣扎。第二步判断倾斜原因。是某个 key 特别多还是分区函数设计不合理或者是数据在 Shuffle 阶段没有做预处理聚合。用日志和 counter 来辅助判断关键是看每个 Reduce 拿到的数据量是否严重不均衡。第三步对症下药。常用手段是加盐salting——给热点 key 加随机前缀拆散到多个分区处理完再合并或者在 Map 端做 Combiner 预聚合减少 Shuffle 数据量。面试问数据倾斜怎么解决重点答这两招就够了。核心原理就是让每个分区的数据量相对均匀Reduce 就不会有人闲死有人忙死。6.5 常见问题速查表现象可能原因首选排查命令/操作NameNode 起不来tmp 目录被清、clusterID 不符tail -f $HADOOP_LOG_DIR/hadoop-root-namenode-hadoop01.logDataNode 一直掉线时间不同步、免密失效ntpdate 同步时间ssh hadoop02 date 验证作业卡在 ACCEPTEDResourceManager 内存不足查看 RM 页面容量检查每个 NodeManager 上报的资源Web UI 打不开防火墙未关、进程未启动systemctl stop firewalldjps 查进程磁盘空间飙升Block 副本冗余过多hdfs dfsadmin -report 查看空间和各节点使用率Shuffle 阶段报错未配置 aux-services检查 yarn-site.xml重启 NodeManager上传文件报 Quota 超限HDFS 目录配额满hdfs dfs -count -h /路径 查看配额挂载新磁盘后 DataNode 崩溃磁盘格式不对、目录不存在先创建目录并挂载再启动 DataNode7. 从集群到项目Hadoop 生态里下一步该怎么走集群搭好、WordCount 跑通很多人就以为“学完了”。这里必须泼一盆冷水Hadoop 本身只是一个分布式存储与计算底座它不能直接解决你的业务问题。你真正要写的是处理业务数据的计算逻辑而这套逻辑通常不是直接用 MapReduce 去写的。以我之前做过的一个“基于 Hadoop 的网约车订单数据分析系统”为例整体链路是这样的数据源是数千万条订单日志放在 HDFS 里按天分目录存储第一层清洗用 Hive 写 SQL做字段提取、格式转换、去重第二层按城市和时段聚合统计用 Spark SQL 跑比纯 MapReduce 快一个量级最后结果落地到 MySQL用 Flask ECharts 做可视化展示这个链路的核心思想是Hadoop 负责存储和底层的资源调度Hive 负责把 SQL 转成 MR 或 Spark 作业Spark 负责更复杂的计算MySQL 做结果的服务端前端负责呈现。你要想把这些串起来需要的不是一个“会启动集群”的人而是一个“懂数据全链路”的人。所以我的建议是集群搭建完成后不要满足于现状要立刻进入这三个方向一是学会用 Hive。这是数仓建模的基础面试必考。重点是掌握内外部表的区别、分区和分桶的原理、以及如何写出能走 MapReduce 的高效 SQL。二是学 Spark。Spark 现在已经是批处理的主流引擎它的 RDD、DataFrame 和 SQL 三层 API 要搞清楚尤其在 Spark on YARN 模式下怎么提交作业、怎么调内存和并行度都是实操中很常见的问题。三是学一个可视化框架。ECharts 本身轻量易上手配合 Flask 写接口能把 Hive 或者 Spark 算出的结果展示成图表。这类“大数据 可视化”的组合是很多毕业设计和综合项目的标配。另外一个值得尝试的方向是把自己搭的集群容器化。现在用 Docker 跑 Hadoop 镜像、K8s 调度 Hadoop 任务也越来越普遍你可以试着写个 Dockerfile 把 Hadoop 集群打进去再用 docker-compose 一键拉起三节点。这个过程会让你对端口、目录、环境变量这些细节的理解再上一个台阶。8. 版本升级和集群扩展的思路集群不是搭完一次就一劳永逸的。你在跑数据的过程中会遇到两类问题一是单台机器磁盘不够了二是算力不够了。第一种的解法是往 DataNode 上加磁盘改 dfs.datanode.data.dir 参数把新目录加进去然后滚动重启 DataNode。第二种的解法就是加节点。加 DataNode 节点的流程其实非常简单新机器按第 2 节的步骤设置 hosts、JDK、免密解压 Hadoop 安装包把主节点的 core-site.xml、hdfs-site.xml、yarn-site.xml 整个拷贝到新机器把新机器的主机名写进主节点的 workers 文件启动新节点上的 DataNode 和 NodeManagerhdfs --daemon start datanode yarn --daemon start nodemanager不需要重新格式化 NameNode新节点会自动向现有集群注册。如果没生效去 DataNode 日志里看是不是 clusterID 不匹配解决办法参照第 6.2 节删掉 current 目录重启。Hadoop 3.x 还引进了“NameNode 目录联邦”这样的新特性本质上允许你为不同的业务域创建多个独立的 NameNode 命名空间让 HDFS 的元数据压力分散。如果是做超大规模集群值得研究。但个人学习和中小项目把单 NameNode 调优到极致比盲目引入联邦更实际。关于版本升级我自己的体会是不要追新。Hadoop 社区出新版本的速度非常快但生态里的 Hive、Spark、HBase 等组件的兼容性往往滞后。生产环境用稳定版比用新版重要一万倍。你可以在测试集群上验证新版特性但生产环境尽量按“组件版本矩阵”来规划确认所有组件的版本都兼容后再动。最后再说几句我的体会写了这么多其实核心就一句话Hadoop 集群搭建是每个大数据人的基本功但真正拉开差距的是你对“为什么这么搭”的理解深度。你可能在面试中被问到的不是某某命令怎么写而是“HDFS 为什么不适合存小文件”“NameNode 元数据存内存会不会有瓶颈”“YARN 的内存模型如何规划”这些问题的答案其实都藏在你搭建集群时的每一个配置决策里。从我的经验看刚入门的人最值得花时间的地方有三块一是把 HDFS 的工作机制研究透包括块的读写流程、副本放置策略、安全模式机制二是把 YARN 的资源调度流程理清楚从提交作业到分配容器、执行任务的全过程三是亲手把集群拆了重建几遍这种“破坏性训练”比看十遍教程都有用。如果这篇文章能帮你把集群从 0 到 1 搭起来并且看懂每个参数背后的逻辑那就不白写。等你把 WordCount 跑通的那一刻恭喜你你已经是分布式计算世界里的人了。剩下的路就是不停地写作业、跑数据、看日志、调参数日复一日地在这套系统的边界上试探。也正是这个过程才会让你真正理解什么叫做“大数据”。