1. 先把思路理清Playground脚本到底帮你干了什么5分钟搭好Hadoop集群这个口号乍一听像标题党但用对工具后它真不是吹牛。我见过太多人卡在Hadoop部署这一步官网下载了一堆压缩包翻教程配XML配置文件折腾一两天最后jps一看进程少了一半连DataNode都没起来。问题往往不是你不会而是手动铺开三台、五台机器的时候重复劳动太多一步漏了就得推倒重来。顺手先给刚接触大数据的朋友补个基础Hadoop集群从功能上拆核心就两大部分一个是HDFS负责存数据里面有NameNode管元数据、DataNode存真实数据块另一个是YARN负责算数据ResourceManager统管资源NodeManager干具体活。你要部署的所谓Hadoop集群本质就是把角色分配到几台机器上然后让它们互相认识、协同工作。Playground脚本做的事情就是把这个分配角色、互相认识的过程变成敲一次命令、喝口水的功夫。我这边说的Playground脚本是一套围绕Hadoop 3.3.x精简部署整理的自动化脚本集合它做了三件事环境初始化、配置生成与同步、集群启动与校验。你只要在一台主控机器上填好节点清单脚本会自动往其他机器推送JDK、解压Hadoop、生成各个组件需要的XML配置再一键启动所有角色的进程。整个过程不做花哨的操作就是把一个熟练工程师手动执行的步骤固化成脚本少让你熬夜。这篇文章是系列第一篇重点讲清楚思路、环境准备和单主节点集群的完整搭建。像高可用HA、联邦、跟Hive/Spark/Flink这些组件打通后面文章再展开。先把地基打牢跑通一个能正常读写数据的集群比什么都重要。2. 动手前必看环境准备与依赖安装清单2.1 服务器与系统规划别一上来就装软件部署Hadoop前先把机器规划好。我见过有人拿一台2核4G的云服务器硬跑三节点集群结果内存直接爆掉ResourceManager被系统杀掉还以为是脚本有问题。先算账再动手这是原则。以最常见的三节点集群为例我用的是1台主节点加2台从节点的方案节点角色主机名IP规划示例核心角色进程最低配置参考主节点hadoop-master192.168.10.10NameNode、ResourceManager、SecondaryNameNode4核8G起步从节点1hadoop-worker1192.168.10.11DataNode、NodeManager2核4G起步从节点2hadoop-worker2192.168.10.12DataNode、NodeManager2核4G起步操作系统我建议直接用CentOS 7.9或者Ubuntu 20.04/22.04 LTS都行。如果你手头只有Windows机器也可以先装虚拟机或者买几台按量付费的云主机练手。系统选64位是必须的Hadoop在32位系统上编译很麻烦没必要给自己挖坑。节点规划里最容易被忽略的是主机名和hosts解析。集群节点之间通过主机名互相通信你如果不改hosts后期启动脚本和Web界面里到处是IP排查问题直观性差很多。规划好IP和主机名后先统一确认每台机器的系统时间一致Hadoop的内部心跳机制对时间偏差比较敏感差太多会出现节点莫名失联的情况。2.2 JDK版本选择与安装思路Hadoop是基于Java开发的JDK装不对后面全白搭。Hadoop 3.3.x版本官方要求Java 8或Java 11我自己的经验是老老实实用JDK 8。不是说JDK 11不行而是很多从节点上的额外组件、后续要接的Hive、Spark版本跟JDK 8的兼容性最稳社区踩坑案例也最少。不要一味追求新版本大数据生态讲究的是版本配对齐步走。JDK尽量用官方tarball方式安装不要图省事用系统自带的OpenJDK。原因很简单一是版本可控二是所有节点解压到统一目录后比如/opt/java/jdk1.8.0_202路径一致脚本好写权限好管。安装完记得配置JAVA_HOME和PATH这一步是部署脚本自动完成的但如果手动搭集群很容易忘记写JAVA_HOME导致Hadoop自带的启动脚本找不到Java环境。2.3 SSH免密登录配置一键部署的命脉Playground脚本能在主控节点上远程操作所有机器依赖的就是主节点到所有节点包括自己的SSH免密登录。这个不配好脚本执行到一半会卡在密码输入上自动化就断了。配置思路很直接在主节点生成一对密钥把公钥分发到所有节点的authorized_keys里。具体命令如下# 在主节点执行一路回车即可 ssh-keygen -t rsa -b 4096 -P -f ~/.ssh/id_rsa # 分发公钥到所有节点包括自己 ssh-copy-id hadoop-master ssh-copy-id hadoop-worker1 ssh-copy-id hadoop-worker2 # 验证免密是否生效能直接出主机名就代表OK ssh hadoop-worker1 hostname这里我吃过一次亏手动改了authorized_keys文件的权限给了组用户和其他用户读权限反而导致SSH客户端认为文件不安全拒绝使用公钥登录。记住~/.ssh目录权限最好是700authorized_keys权限最好是600。脚本里加了个自动修复的函数但大家在手动排查时也要记住这个细节。2.4 获取Playground脚本并准备好Hadoop安装包机器和SSH都搞定了接下来就是把脚本和安装包放到主节点的固定目录。我的习惯是统一放在/opt/playground-hadoop下面目录结构长这样/opt/playground-hadoop/ ├── bin/ │ ├── init-env.sh # 初始化环境JDK、Hadoop解压、hosts写入 │ ├── sync-all.sh # 把配置和安装包同步到所有从节点 │ ├── create-configs.sh # 根据节点清单生成XML配置 │ ├── start-cluster.sh # 一键格式化并启动集群 │ └── verify-cluster.sh # 检查进程、端口和Web UI状态 ├── conf/ │ ├── masters # 主节点角色清单 │ ├── workers # 从节点清单 │ └── env.sh # 集群全局环境变量如JAVA_HOME、HADOOP_HOME └── packages/ ├── jdk-8u202-linux-x64.tar.gz └── hadoop-3.3.6.tar.gz关于下载地址我建议直接去Apache官网的archive页面找历史版本的hadoop-3.3.6.tar.gz国内用户如果下载慢可以找镜像站。JDK的tar包同理。把这些包提前下载好放到packages目录后面脚本执行会快很多也防止了安装在半路网络抽风导致中断。3. 配置不抓瞎核心参数逐项解读与内存规划3.1 脚本怎么帮你生成Hadoop配置文件很多小白被Hadoop劝退就是被一堆XML配置劝退的。说实话Hadoop核心配置文件就四个core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml。剩下masters、workers这两个是纯文本列表写主机名用的。Playground脚本的create-configs.sh干的事是先读conf/workers和conf/masters再读conf/env.sh里的变量最后用模板生成四个XML文件分发给所有节点。这里有个关键的工程思路配置文件只维护一份模板变量化所有跟节点相关的差异内容。比如core-site.xml里的fs.defaultFS因为取决于主节点的hostname脚本里就自动替换成hdfs://hadoop-master:8020而不是让你在每台机器上手动改。3.2 核心参数怎么调从项目实际需求出发新手最常见的错误就是照抄网上的配置根本不理解参数含义。我这里挑几个跟运行稳定性强相关的参数用大白话拆开讲第一个是hdfs-site.xml里的dfs.replication默认值是3意思是每个数据块在集群里存3份副本。三节点集群配置3没问题但如果你的集群只有两台机器还硬配3那DataNode会一直报副本不足的警告因为根本无法满足3份副本的物理存储位置。我在脚本里做了个简单判断节点总数少于3时自动把副本数调整为节点数减一避免新手踩这个坑。第二个是dfs.namenode.name.dir和dfs.datanode.data.dir这俩是数据存放目录。很多教程让你直接写/tmp下重启机器数据就没了这种坑属于低级但常见。脚本默认创建/opt/hadoop_data/namenode和/opt/hadoop_data/datanode挂在独立数据盘上最好。注意目录权限给运行Hadoop的用户我习惯用hadoop用户授权chown -R hadoop:hadoop否则格式化NameNode时会报Permission denied。第三个是yarn-site.xml里的yarn.nodemanager.resource.memory-mb和yarn.scheduler.maximum-allocation-mb这俩决定每个从节点能给Spark、MapReduce任务分配多少内存。无脑调大反而会出问题因为操作系统自己也要内存你把NodeManager能用的内存配置成整机物理内存极端情况下系统OOMNodeManager被杀掉整个集群都抖。下面是我在8G内存从节点上的一组实测合理的配置参考参数名推荐值解释yarn.nodemanager.resource.memory-mb6144给YARN容器用的内存预留2G给系统yarn.scheduler.minimum-allocation-mb1024单个容器最少给1Gyarn.scheduler.maximum-allocation-mb3072单个容器最多给3G防止单个任务吃光资源mapreduce.map.memory.mb1536单个Map任务默认内存mapreduce.reduce.memory.mb2048单个Reduce任务默认内存dfs.namenode.handler.count100NameNode并发线程数100以内足够内存分配有个大概感觉就行系统预留15%到20%剩下的给YARN和DataNode共享NameNode进程单独给堆内存2G到4G。16G以内的机器按这个比例走翻车概率很低。3.3 masters和workers文件怎么填才能让角色自动分配配置完XML还得处理masters和workers文件。这两个文件决定了脚本把进程启动在哪些机器上。masters文件放的是SecondaryNameNode的宿主注意不是NameNodeNameNode是通过core-site.xml的fs.defaultFS确定的workers文件则列出所有DataNode和NodeManager的节点。以三节点集群为例masters文件里写hadoop-masterworkers文件里写hadoop-master hadoop-worker1 hadoop-worker2这里有个容易困惑的点masters节点也就是hadoop-master同时也可以作为DataNode和NodeManager运行所以它也出现在workers列表里。这样安排的好处是主节点承担了管理角色的同时也利用空闲IO和网络带宽参与数据存储和计算。对于8G以上内存的主节点这样没问题如果主节点内存本身很紧张就别往workers里塞了毕竟NameNode和ResourceManager都是吃内存的大户。4. 实操全程从空机器到跑起来的一键部署流程4.1 写节点清单和环境变量实际操作前先把conf/env.sh这个全局文件改了。它里面有几个变量是整个集群的大脑# conf/env.sh 核心配置示例 export JAVA_HOME/opt/java/jdk1.8.0_202 export HADOOP_HOME/opt/playground-hadoop/hadoop-3.3.6 export HDFS_NAMENODE_USERhadoop export HDFS_DATANODE_USERhadoop export HDFS_SECONDARYNAMENODE_USERhadoop export YARN_RESOURCEMANAGER_USERhadoop export YARN_NODEMANAGER_USERhadoop export HADOOP_DATA_DIR/opt/hadoop_data export HADOOP_MASTER_HOSThadoop-master export HADOOP_REPLICATION3这里要特意提一下HDFS_NAMENODE_USER这类变量在Hadoop 3.x版本中如果非root用户启动HDFS和YARN不设置这两个变量脚本会直接报权限错误提示Cannot set priority of namenode process。这个是Hadoop 3.0以后加入的安全限制网上很多老教程根本没提新手第一次跑就摔在这里。4.2 一键执行init-env、sync-all、create-configs、start-cluster环境变量填好后执行顺序基本是固定的。我把脚本分成了4个步骤每个步骤职责单一失败了也容易定位cd /opt/playground-hadoop/bin # 第一步主节点初始化JDK、Hadoop创建数据目录和用户 bash init-env.sh # 第二步把安装包、配置模板同步到所有从节点 bash sync-all.sh hadoop-worker1 hadoop-worker2 # 第三步基于模板生成所有XML配置并同步 bash create-configs.sh # 第四步格式化NameNode、启动HDFS和YARN bash start-cluster.sh先解释第一步init-env.sh做了什么它会检查每台机器上有没有装JDK没有就从packages目录解压检查Hadoop目录是否存在不存在就解压同时创建/opt/hadoop_data目录写入hosts解析记录确保所有节点能通过主机名互相访问。这里有个隐患如果你的机器之前装过其他版本的JDKPATH顺序可能导致Hadoop用了错误的Java版本所以脚本里会在hadoop-env.sh里强写JAVA_HOME这比在/etc/profile里设置更稳定。第二步sync-all.sh相对机械用rsync把整个playground-hadoop目录推送到从节点的相同路径。rsync比scp的优势在于增量传输第二次执行时几十秒就完事了。注意从节点上要先创建好hadoop用户并且目录属主是hadoop。第三、第四步我放在下面小节细讲。4.3 格式化NameNode前必须确认的3件事start-cluster.sh里有一步关键操作hdfs namenode -format。这一步是把NameNode的元数据存储目录初始化为空白的文件系统镜像。执行格式化之前我总结了必须确认的三件事每一条都是踩过坑才记住的第一确认所有DataNode的数据目录是干净的。如果之前部署过HadoopDataNode目录里有旧的clusterID格式化NameNode后会出现clusterID不匹配导致DataNode虽然进程活着但一直连接不上NameNodejps看起来正常Web UI里Live Nodes却为0。我在脚本里加了个逻辑格式化前先检查所有节点的VERSION文件发现旧的clusterID就自动备份并清空目录。第二确认NameNode的RPC端口没被占用。默认是8020被其他服务占了的话格式化本身能过但是起NameNode会立刻失败。执行ss -lntp | grep 8020看看如果被占用就改core-site.xml里的fs.defaultFS端口。第三格式化操作只允许在主节点执行一次。如果你在格式化后又格式化第二次会把之前的元数据全清掉整个集群的数据就再也找不回来了。脚本里我加了个标志文件第一次格式化后自动创建下次执行直接跳过格式化步骤就是为了防止误操作。4.4 启动与验证jps、端口、Web UI三连查启动完成后先别急着写MapReduce任务做一轮基础体检最重要。在每台机器上执行jps看进程是不是跟规划的对应主节点上应该看到NameNode、ResourceManager、SecondaryNameNode如果主节点也在workers列表里还有DataNode和NodeManager。从节点上应该看到DataNode和NodeManager。再看端口监听情况# 在主节点检查 ss -lntp | grep -E 8020|9870|80888020是NameNode RPC端口9870是HDFS Web UI端口Hadoop 3.x版本2.x版本是500708088是YARN Web UI端口。这三个能监听到集群基本盘就稳了。最后打开浏览器访问http://hadoop-master:9870和http://hadoop-master:8088看到Volume Health和Active Nodes都正常整个部署就算成功。这里有个浏览器访问的判断细节9870里datanode数量跟workers里的数量不一致时别慌先看其他节点防火墙有没有放行端口。云服务器的话安全组里也得同时放行8020、9870、8088、9864这些端口。我见过太多人卡在这一步本地jps一切正常Web UI死活连不上归根结底是安全组规则忘配了。5. 踩坑实录集群起不来怎么办的排查清单5.1 常见问题的现象、原因与处理速查表新手第一次跑完整流程100%会遇到几个问题我整理了一份排查清单覆盖我帮助别人部署时遇到的高频故障现象可能原因排查与处理jps没有NameNode进程格式化失败或端口被占用查看$HADOOP_HOME/logs/hadoop-hadoop-namenode-*.log端口冲突就改端口NameNode活着但DataNode全掉clusterID不匹配或防火墙拦截对比namenode和datanode目录里的VERSION文件clusterID不一致就清空datanode目录重启Web UI的Live Nodes为0从节点无法解析主节点主机名回到所有节点执行ping hadoop-master确认hosts配置全部生效ResourceManager启动失败YARN服务用户未设置检查env.sh里YARN_RESOURCEMANAGER_USER和YARN_NODEMANAGER_USER是否正确运行wordcount任务卡死内存配置过小或过大查看YARN Web UI的资源总量确认nodemanager.resource.memory-mb配置DataNode日志一直报disk空间不足数据盘满了或巡检保留不足清理日志检查dfs.datanode.data.dir挂载盘余量表格里列的是高频问题但日志永远是第一手信息。Hadoop日志路径默认在$HADOOP_HOME/logs下Java进程的启动报错、心跳失败原因、RPC连接问题几乎所有线索都在那里面。很多新手两眼一抹黑连日志都不看就来问人我建议养成先看日志再百度的习惯。5.2 几个价值极高的独门排查技巧除了上面的常规排查还有几个技巧是我在实际运维中觉得特别管用但很多教程不讲的技巧一是用hdfs dfsadmin -report命令看集群视角的运行状态。这个命令会直接输出每个DataNode的容量、剩余空间、是否正常比你在Web UI上找半天快得多。如果某个DataNode显示状态为In Service但容量为0大概率是它的数据目录挂载有问题。技巧二是手动单进程启动法。脚本一键启动没问题时可以用hdfs --daemon start datanode这样手动把一个进程拉起来看它在终端里直接输出的日志。脚本把进程放到后台后有些报错被吞到日志文件里单进程启动能把报错直接砸你脸上排查效率极高。技巧三是用netstat抓心跳。如果DataNode一直在尝试连接NameNode但连不上在从节点上执行netstat -anp | grep 8020看看TCP连接是不是SYN_SENT状态如果是几乎可以判断是网络层问题赶紧去查安全组和防火墙不用怀疑应用配置。5.3 我踩过一次最大印象的坑格式化前的目录清理有一年我给客户部署生产集群因为机器是从另一个项目里回收过来的DataNode的数据目录还残留着旧环境的VERSION文件。我格式化NameNode后三台DataNode进程全起来了但Web UI里Live Nodes一直显示0。排查日志发现每次DataNode注册时都被NameNode拒了原因是clusterID不一致。这次踩坑让我对自动化脚本里的防御性检查有了执念。现在就特别强调如果集群不是全新机器格式化之前必须把每台DataNode的data.dir清干净。Playground脚本里专门加了一个--clean参数会SSH到所有节点执行rm -rf $HADOOP_DATA_DIR/datanode/*用来兜底解决这个问题。这里也提醒各位线上环境操作前一定要确认目录路径防止误删数据盘。6. 集群起来之后验证读写和后续扩展方向6.1 别急着上业务先跑一遍上传下载集群启动后我强烈建议先做一轮HDFS基本读写测试别急着直接跑计算框架。测试命令很简单# 创建测试目录 hdfs dfs -mkdir /test # 上传一个本地文件 hdfs dfs -put /etc/hosts /test/hosts.txt # 查看文件是否存储成功 hdfs dfs -ls /test/hosts.txt # 把文件下载下来对比md5 hdfs dfs -cat /test/hosts.txt这轮测试能验证NameNode的元数据读写、DataNode的数据块传输、副本复制是否正常。如果上传后能立即看到文件大小和2-3个副本的块信息说明HDFS基本是健康的。再进一步可以跑一个MapReduce自带的wordcount去验证YARN资源调度链路。命令如下hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar wordcount /test /test/output这个任务跑通后ResourceManager分配容器、NodeManager执行任务、HDFS中间结果写入这一整条链路就算真正打通了。跑完记得看一眼输出目录里的part-r-00000文件内容跟预期一致就可以放心让业务介入了。6.2 部署完成后还要做哪些必要的优化集群能跑只是第一步。我接手过不少能跑但很难用的集群基本都是部署完懒得做三项基础调优。第一项是关闭不必要的文件系统检查在core-site.xml里加fs.trash.interval1440设置回收站保留1天防止误删数据后无法找回开发环境尤其建议开。第二项是调大容器执行线程数yarn.nodemanager.resource.cpu-vcores在8核机器上建议设4到6让单机并发计算能力被尽量用起来。第三项是给NameNode配定期元数据镜像备份把dfs.namenode.name.dir指向两个不同磁盘的路径单个磁盘挂掉不至于整个元数据一起丢。这些优化看着琐碎但对集群长期稳定运行影响很大值得在脚本里固化下来每次新建集群直接套用同一份优化模板。6.3 往后可以怎么继续玩从单主节点到高可用这篇讲的是单主节点集群主节点一挂整个集群就不可用了这在生产环境是不能接受的。所以往后的扩展方向很清晰做NameNode高可用HA用Zookeeper实现自动故障切换两台机器一个Active一个Standby主节点挂掉后自动切换同时给ResourceManager也做高可用彻底解决单点故障问题。除了高可用还可以把Hive接进来做SQL查询、把Spark接进来做内存计算、把HBase接进来做实时读写。这些组件都是搭建在HDFS和YARN之上的前面这个集群起得越稳后面接生态组件越省心。按我自己的经验给刚上手的朋友一个建议也是我做这套Playground脚本的初衷第一次部署集群不要追求一次成功率高而是在跑通整个流程后回到第3章、第4章亲手把那些参数重新改一遍观察改动后集群状态的变化比单纯抄配置理解深刻得多。这套脚本做得再顺手也只是帮你把繁琐重复的步骤压缩掉真正的Hadoop运维能力还是得靠一遍遍实操和排错来积累。下一篇我会把Zookeeper和HA的整合部署思路展开讲把单主节点的集群升级成生产可用形态。