简介这是一份可直接使用的 Hadoop 3.1.4 预配置压缩包面向需要快速搭建大数据实验环境或生产原型的学习者、开发者和运维人员。压缩包为 gz 格式体积约 332.2MB省去自行下载安装、调整系统环境变量与逐步编写多份配置文件的准备过程。Hadoop 3.1.4 融合了 HDFS 分布式文件系统与 MapReduce 并行计算模型前者具备高容错、高可用和高吞吐能力即使在硬件故障时也能保障数据完整性后者可将大规模任务拆分到集群节点并行执行。同时增强后的 YARN 资源管理器支持 Spark、Flink 等更多框架共享集群算力便于数据挖掘、离线批量处理等场景落地。使用者解压后按照随包说明完成简单启动流程即可运行无需从零格式化、调参与排错。目前已有 531 人学习下载。这份资源把原本复杂的环境初始化工作前置完成适合想要绕过繁琐配置、直接上手分布式文件操作与并行计算任务的人群也能为进一步研究 Hadoop 调优或混合计算框架提供稳定基础。 想起前阵子给团队交付环境我直接把一份配置好的hadoop-3.1.4.tar.gz扔到内网新同事解压、改个 hostname、启动全程不到十分钟就把 HDFS 和 YARN 跑起来了。那种“拿来即用”的畅快感说实话比自己从头搭一套要爽太多了。这篇就把这份预配置包的思路、改动细节和部署流程完整记录下来。如果你也在折腾 Hadoop 环境不管是伪分布式练手、还是准备搭一个小集群这份配置都能让你少走不少弯路。我会尽量讲清楚“为什么这么配”而不是只让你抄配置。1. 整体设计思路为什么要做“配置好再打包”的 Hadoop1.1 从零搭建的痛点Hadoop 生态链里最劝退新手的就是环境搭建。官方 tar 包解压出来只是个裸环境你需要先配 JDK、设环境变量、改一堆 XML、做 SSH 免密、格式化 NameNode中间任何一个环节出错报错信息对新手来说基本是“天书”。比如JAVA_HOME is not set这种经典报错看起来简单但在不同机器上触发原因可能完全不同。我这次做“预配置再打包”核心思路就是把所有机器无关的配置固化进包内只保留极少数机器相关的参数在外面让使用者自行调整。具体来说这样做的收益有三点交付速度快新环境从解压到跑起来只需要改 hostname、IP 和少量内存参数一个小时内能跑通全流程。配置标准统一团队里不会出现“你改你的、我改我的”导致的排查困难大家都在同一套配置基线上。生产可复用这份配置稍微调一下内存和副本数就能从单机伪分布式平滑过渡到多节点集群不用推倒重来。1.2 为什么选 Hadoop 3.1.4选 3.1.4 不是随便拍的版本。这个版本是 Apache Hadoop 3.1.x 系列里公认比较稳定的一个支持 JDK 8兼顾了 3.x 的新特性比如 YARN Timeline Service v2、HDFS 纠删码和生态兼容性。市面上很多组件像 Hive、Spark、Flink对 Hadoop 版本的兼容矩阵里3.1.x 基本都在“稳妥可用”那一档。如果用太新的版本比如 3.3.x、3.4.x部分老版本的 Hive 或 Spark 可能会因为 RPC 协议变化出现莫名其妙的兼容问题用 2.x 呢又少了 3.x 的架构优化。所以如果你没有特殊需求3.1.4 是个比较折中、省心的选择。1.3 拿到这份包后你需要准备什么先说清楚“拿来即用”的前提条件免得有人解压完发现跑不起来就开喷操作系统LinuxCentOS 7/8、Ubuntu 18.04 我都实测过没问题Windows 的话需要额外装 WinUtils这篇不展开。JDK必须是 1.8也就是 JDK 8。Hadoop 3.1.4 官方文档明确只支持 Java 8。机器配置伪分布式最低 2 核 4G推荐 4 核 8G。低于这个配置NameNode 和 DataNode 同时跑在一台上会频繁 GC体验很差。只要这三个条件满足剩下的就是修改少量配置、做免密、格式化然后启动。2. 预配置包里的核心细节拆解2.1 目录结构规划解压后我建议你把 Hadoop 固定放在/opt/hadoop这个路径因为包里的配置文件都用了绝对路径或者基于HADOOP_HOME的约定路径统一能避免很多“找不到文件”的问题。/opt/hadoop ├── bin ├── etc/hadoop │ ├── core-site.xml │ ├── hdfs-site.xml │ ├── yarn-site.xml │ ├── mapred-site.xml │ └── workers ├── sbin ├── logs └── tmp (运行时生成)我把运行时的临时目录dfs.namenode.name.dir、dfs.datanode.data.dir统一指向/opt/hadoop/tmp这样打包时只要排除tmp目录就能打出干净的分发包别人的机器上首次启动会自动重新创建目录结构不会残留上一台机器的元数据。2.2 环境变量与 JAVA_HOME 处理环境变量这块儿是“拿来即用”最容易翻车的地方。不同机器的 JDK 安装路径可能不一样你不能假设每台机器 JDK 都装在同一个位置。我的处理方法是在etc/hadoop/hadoop-env.sh中把JAVA_HOME写成相对探测方式核心是在文件里加一段脚本自动从which java反推 JAVA_HOME 路径。这样使用者不用手动改这一项包内的脚本会自动找到 JDK。使用者只需要在/etc/profile.d/hadoop.sh里配置HADOOP_HOME/opt/hadoop和 PATH 追加。# /etc/profile.d/hadoop.sh export HADOOP_HOME/opt/hadoop export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin注意这一段是机器相关的所以没有打进 tar 包。在我的分发文档里这是“两步必须手动操作”里的第一步。为什么不把它也加进去因为/etc/profile.d/属于系统级配置分发 tar 包时覆盖它权限不够而且每台机器已有配置可能冲突手动追加最稳妥。2.3 核心 XML 配置解读预配置包里最关键的四个 XML 文件我逐个说一下我配了什么、为什么这么配。core-site.xmlconfiguration property namefs.defaultFS/name valuehdfs://node01:9000/value /property property namehadoop.tmp.dir/name value/opt/hadoop/tmp/value /property property namehadoop.proxyuser.root.hosts/name value*/value /property property namehadoop.proxyuser.root.groups/name value*/value /property /configurationfs.defaultFS里的node01是机器相关的我默认用的主机名是node01你在自己机器上部署时需要把 hosts 里加上映射或者把它改成你的实际 IP。hadoop.proxyuser.root这两个配置是为了后续接 Hive、Spark 时避免代理用户权限问题提前放开 root 代理不然后面跑 Hive 会报Failed to connect to metastore这类头疼的错。hdfs-site.xmlconfiguration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name valuefile:///opt/hadoop/tmp/namenode/value /property property namedfs.datanode.data.dir/name valuefile:///opt/hadoop/tmp/datanode/value /property property namedfs.namenode.http-address/name valuenode01:9870/value /property property namedfs.permissions.enabled/name valuefalse/value /property /configurationdfs.replication我设置为 1因为大多数场景下是单机伪分布式或少量节点的测试集群副本数设 3 只会白白浪费磁盘而且如果 DataNode 数量少于副本数HDFS 会一直处于Under replicated告警状态日志刷个不停。dfs.permissions.enabled关掉权限检查是因为测试和学习阶段频繁遇到权限问题太影响效率但生产环境千万别学我。yarn-site.xmlconfiguration 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 property nameyarn.resourcemanager.hostname/name valuenode01/value /property property nameyarn.nodemanager.resource.memory-mb/name value4096/value /property property nameyarn.scheduler.maximum-allocation-mb/name value3072/value /property /configurationyarn.nodemanager.resource.memory-mb是我预留在包里的“机器相关参数”因为每台机器的物理内存不一样。4G 内存的机器建议改成 20488G 内存的机器用 4096 没问题。这里有个隐形坑这个值不能超过机器物理内存减去系统和其他进程需要的内存否则 Container 一启动就可能被系统 OOM Killer 直接杀掉。mapred-site.xmlconfiguration property namemapreduce.framework.name/name valueyarn/value /property property namemapreduce.application.classpath/name value$HADOOP_HOME/share/hadoop/mapreduce/*:$HADOOP_HOME/share/hadoop/mapreduce/lib/*/value /property /configuration第二个参数是 Hadoop 3.x 里很容易被忽略的一个点。3.x 的mapreduce.application.classpath如果没设置跑 MapReduce 作业时经常报ClassNotFoundException: org.apache.hadoop.mapreduce.Job但明明 jar 包就在那里。这是因为默认的 classpath 不包含 mapreduce 的 lib 目录。提前配好后面跑 WordCount 就省得现查了。2.4 workers 文件与 SSH 免密workers文件3.x 里叫 workers2.x 里叫 slaves默认写的是node01如果你是单机伪分布式这就不用改。如果要扩成集群就在里面一行一个节点加 hostname。SSH 免密我强烈建议单独做不要打进包内因为私钥属于个人凭证。命令如下ssh-keygen -t rsa -P -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys然后在~/.ssh/config里把node01指到对应 IP不需要配其他节点。伪分布式一定要做免密否则start-dfs.sh每次启动都要你输密码压测时重启集群会让人崩溃。3. 打包与部署实操过程3.1 打包前的清理工作这一步是最容易“翻车”的地方也是决定你的包是不是“干净”的关键。如果直接拿跑过的 Hadoop 目录打包你会把上一台机器的临时数据、日志、pid 文件全部打进去别人解压后 NameNode 格式化时会撞上 VERSION 文件不一致报一堆诡异的错。我每次打包前会执行清理脚本# 停止所有服务 /opt/hadoop/sbin/stop-dfs.sh /opt/hadoop/sbin/stop-yarn.sh # 清理运行时数据 rm -rf /opt/hadoop/tmp/* rm -rf /opt/hadoop/logs/* rm -rf /tmp/hsperfdata_* # 排查是否残留 pid 文件 find /opt/hadoop -name *.pid -exec rm -f {} \; # 打包 cd /opt tar -czf hadoop-3.1.4-configured.tar.gz --excludehadoop/tmp hadoop--excludehadoop/tmp保证了元数据不会被打进包里。日志目录我保留但清空内容因为目录结构在启动时会自动创建留着也没关系。这样打出来的包体积大概会从原始的 400MB 左右减到 380MB因为排除了数据和日志。3.2 新机器上的三步部署流程我写了一个部署脚本放在包外单独分发方便到新机器上一键执行#!/bin/bash # deploy_hadoop.sh set -e HADOOP_DIR/opt/hadoop # Step 1: 解压到指定目录 tar -xzf hadoop-3.1.4-configured.tar.gz -C /opt/ # Step 2: 追加环境变量 if ! grep -q HADOOP_HOME /etc/profile.d/hadoop.sh 2/dev/null; then echo export HADOOP_HOME/opt/hadoop /etc/profile.d/hadoop.sh echo export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin /etc/profile.d/hadoop.sh fi source /etc/profile.d/hadoop.sh # Step 3: 设置 hosts 映射按需修改 echo 192.168.1.100 node01 /etc/hosts echo 部署完成请手动修改 core-site.xml 和 hdfs-site.xml中的node01为实际主机名/IP echo 然后执行: hdfs namenode -format start-dfs.sh start-yarn.sh整个脚本核心思路就是三步解压、配环境、跑启动。之所以把格式化放到手动步骤里是因为hdfs namenode -format是个“一次性危险操作”如果脚本里自动执行第二次运行脚本时格式化会清掉已有 NameNode 上的所有元数据这种事故我踩过以后再也不敢把它放到自动脚本里。3.3 首次启动完整流程与验证新机器上跑完部署脚本后关键的启动流程这么走# 1. 修改 hostname 和 hosts hostnamectl set-hostname node01 bash # 2. 确认 JAVA_HOME 被自动探测到 /opt/hadoop/bin/hadoop version # 3. 格式化 NameNode只需一次 hdfs namenode -format # 4. 启动 HDFS start-dfs.sh # 5. 启动 YARN start-yarn.sh # 6. 验证进程 jps正常的话jps应该看到五个进程NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager。少了任何一个说明对应组件没起来。再验证一下 Web UIHDFS 管理界面http://node01:98703.x 默认端口不是 2.x 的 50070YARN 管理界面http://node01:8088然后跑一个最简单的文件操作命令确认 HDFS 正常hdfs dfs -mkdir -p /user/test hdfs dfs -ls /如果目录创建成功且ls能看到/user/test说明 HDFS 读写链路是通的。到这里“拿来即用”的目标已经基本达成。4. 实际部署中的高频问题与排查记录虽然我极力把这份包做得“傻瓜化”但新环境千奇百怪还是有一些问题会反复出现。我把踩过的坑整理成排查清单按频率排个序。4.1 启动后jps看不到 NameNode这是最常见的现象很多人第一反应是“启动脚本出问题了”。实际上大部分情况是启动日志里有隐藏错误。排查思路是这样# 看启动日志 tail -100 /opt/hadoop/logs/hadoop-root-namenode-node01.log我遇到过的典型原因有三个dfs.namenode.name.dir指定的目录没有创建成功导致 NameNode 启动直接失败。解决办法手动创建目录修改属主chown -R root:root /opt/hadoop/tmp再重新格式化。格式化失败残留了部分元数据报错信息里有Storage directory already exists。解决办法清空tmp目录重新格式化。端口被占用9000 或 9870 被其他进程占用。用netstat -ntlp | grep 9000查看杀掉占用进程或者改端口。4.2 SSH 免密配置了但还是要求输密码这个问题在伪分布式上也很常见。有时候明明ssh localhost不要求密码了但start-dfs.sh还是卡在密码输入。关键点在于start-dfs.sh是根据workers文件里的主机名去 SSH 的如果你是ssh node01而不是ssh localhost两个是不同的认证路径。解决办法就是保证~/.ssh/authorized_keys里同时有 localhost 和 node01 的公钥或者干脆用ssh-copy-id node01把公钥推一遍。还有个细节是.ssh目录权限~/.ssh必须是 700authorized_keys必须是 600。权限太开放SSH 服务会直接忽略这个文件这个坑够隐蔽的。4.3 内存不足导致 DataNode 或 NodeManager 闪退如果你在 2G 内存的机器上强跑默认配置大概率会遇到 DataNode 刚起来就被系统杀掉的情况。日志里会看到Killed字样。排查方法是dmesg | grep -i killed process如果是被 OOM Killer 杀的就把 yarn 配置里的内存调低同时降低HADOOP_HEAPSIZE# hadoop-env.sh 中 export HADOOP_HEAPSIZE1024 export HADOOP_NAMENODE_OPTS-Xms512m -Xmx512m一开始我是按 8G 内存标准做的配置分发前你最好先看一下机器内存再自己调节。这不是配置包的问题是“拿来即用”和“自适应”之间的天然矛盾我也只能优先照顾大多数场景。4.4 格式化 NameNode 失败或卡住hdfs namenode -format出现异常比较少见但一旦卡住或提示NameNode is not formatted我建议优先检查 java.io.tmpdir 是否有问题。Hadoop 格式化时会写一些临时文件到/tmp如果/tmp权限不对或空间满了格式化就会失败。一个容易踩的坑是格式化时提示WARN ... Invalid value for resource这类内容其实不影响启动是正常的 warning不用太紧张。真正需要在意的是最后有没有出现successfully formatted字样。5. 扩展思路从“拿来即用”到“集群可跑”这份预配置包虽然初衷是为了快速交付但稍微改改它完全可以作为小集群的构建基础。我的做法是把workers文件里加一行一个新节点比如node02。把core-site.xml里的fs.defaultFS改成 NameNode 所在节点的 IP。在新节点上同样解压这个包配置环境变量和 SSH 免密。只在主节点执行hdfs namenode -format然后启动全集群。DataNode 和 NodeManager 不需要在每个节点单独格式化它们的数据目录会自动创建。这一点经常有人误会以为每个节点都要格式化一次真要这么干了集群 ID 不一致DataNode 同样会启动失败。集群模式下唯一要小心的是dfs.replication需要改成大于 1 的值否则有 DataNode 宕机时HDFS 会一直告警数据块副本数不足。测试集群改成 2 就够用了能容忍单节点故障。6. 最后再说点实际的这份hadoop-3.1.4.tar.gz预配置包本质上是把所有“可标准化的部分”固化了下来把“机器相关的部分”留给了使用者。花点时间打磨这份包长期看节省的是自己和团队大量的重复环境搭建时间。如果你在部署中发现了其他我没提到的问题欢迎交流。我自己也是踩了无数坑才把这套流程固定下来很多细节都是一个个日志抠出来的经验。希望这份记录能让你在 Hadoop 这条路上少走些弯路把精力留给真正值得研究的业务和调优问题。本文还有配套的精品资源点击获取