简介：这是 Apache Hadoop 3.3.6 的二进制安装包，主要面向需要搭建大数据存储与计算环境的开发人员、运维工程师以及分布式系统学习者。Hadoop 提供 HDFS 分布式文件系统、YARN 资源调度和 MapReduce 计算框架等核心组件，使用户无需深入掌握分布式底层细节，便能编写和运行分布式程序，适合单机实验、集群搭建、离线数据处理与生产环境部署等多种场景。资源包共约两千个文件，压缩后大小为 696.28MB。文件类型涵盖丰富的 HTML 文档、网站素材图片、CSS 样式、JAR 依赖库、XML 配置文件、Shell 启动脚本、TXT 说明等，部署时便于检索配置参数并快速定位相关命令与依赖。目前已有 1344 人浏览学习。通过这份安装包，可直接获得完整的 Hadoop 目录结构与默认配置，免去源码编译环节；结合官方文档，即可完成环境初始化、集群启动、任务提交以及基础参数调优，为后续学习大数据生态组件或建设生产集群打下稳定基础。 最近在重新整理部门的数据基础设施，刚好需要给几台新机器装上 Hadoop 环境。考虑到之前生产环境一直跑在 2.x 上，这次想一步到位直接上 3.x，最终锁定了hadoop-3.3.6.tar.gz 安装包。这个版本在 NameNode 高可用、YARN 调度、云原生适配方面都成熟了不少，而且修复了一批 CVE 安全漏洞，用它做新集群的基线版本很合适。
这篇文章我不会只写“下载解压然后启动”，而是把从拿到 tar.gz 到集群跑通的全过程拆开讲清楚——包括为什么选 3.3.6、装之前要准备什么、伪分布式怎么快速验证、真实集群和单机配置差在哪、还有新手最容易栽进去的几个坑（格式化失败、DataNode 起不来、端口不通这类）。无论你是课程设计要用、自学搭环境，还是生产环境做升级评估，这篇文章的步骤和建议都可以直接照着操作。
1. 为什么是 3.3.6：版本选择与安装包获取
1.1 3.x 相比 2.x 到底改了什么
很多教程还在教 2.7.x 或 2.10.x 的玩法，但 3.x 已经不是“新特性预告”级别了，在很多关键设计上跟 2.x 有本质区别。直接说几个影响日常使用的点：
- 端口体系重构：NameNode Web UI 从 50070 变成了 9870，DataNode 从 50075 变成了 9864。如果你以前背过 2.x 的端口号，到 3.x 得改一下肌肉记忆。
- 支持 JDK 8 和 11：Hadoop 3.3.x 官方同时支持 JDK 8 和 JDK 11，这点比 3.1/3.2 时代只推荐 JDK 8 要宽松。JDK 11 的垃圾回收和性能表现更好，生产环境建议直接上 JDK 11。
- YARN 资源调度增强：Capacity Scheduler 默认开启，对多租户场景更友好；节点 label 也支持了，可以把 GPU 节点和 CPU 节点分开调度。
- 纠删码（Erasure Coding）：以前为了可靠性，HDFS 默认三副本，存储开销 200%。3.x 支持纠删码，比如 RS-6-3 策略下 6 个数据块加 3 个校验块，存储开销只有 50%，可靠性还比三副本高。这个特性对冷数据存储特别香。
- 不兼容变化提醒：3.x 对 MapReduce 的一些内部 API 做了清理，老代码编译可能会报警告甚至直接失败。
3.3.6 属于 3.3.x 分支的一个稳定补丁版本，修复了包括 HDFS 的多个信息泄露漏洞和 YARN 的资源管理问题。从维护节奏看，3.3.x 是当前社区主推的稳定分支之一，网上踩坑资料也最全，遇到问题基本能搜到对应解决方案。
1.2 下载渠道、MD5 校验与目录规划
下载 Hadoop 安装包看起来是小事，但选错渠道会带来安全风险。官方 Apache 站点的下载速度在国内不太稳定，建议优先用以下方式：
- 清华大学 TUNA 镜像源
- 阿里云镜像源
- Apache 官方下载站的 CDN
文件名就是hadoop-3.3.6.tar.gz，大概 700 多 MB。下载完必须做完整性校验，我习惯用 MD5 或 SHA-512 双重检查。首先到 Apache 官方发布目录拿到.md5和.sha512文件，然后本地执行：
md5sum hadoop-3.3.6.tar.gz sha512sum hadoop-3.3.6.tar.gz对比哈希值一致后再进行解压，这一步能避免拿到被篡改的二进制包，也能排除下载过程中文件损坏的可能。
目录规划上，我习惯把安装目录统一放在/opt下，数据目录单独放：
/opt/hadoop-3.3.6 # 软件安装目录，解压后改名 hadoop 做软链 /opt/hadoop/data # HDFS 数据目录（name 和 data 子目录分开放） /opt/hadoop/logs # 运行日志目录这样后续升级时只需要切换软链，不需要动数据目录，也不会误删运行日志。很多初学者图省事把数据目录放在安装包内，后面一旦重装或误删安装目录，整个 HDFS 数据就全没了，这个教训我踩过太多次。
2. 解压前的环境准备：JDK 版本、用户与 SSH
2.1 JDK 安装与 JAVA_HOME 配置
Hadoop 是 Java 写的，没有 JDK 什么都跑不起来。Hadoop 3.3.6 官方要求 JDK 8 或 11，不建议用更高版本。实际测试中，JDK 17 虽然能启动部分组件，但 YARN 和 MapReduce 会出现各种诡异的序列化异常，没必要给自己找麻烦。生产环境我推荐OpenJDK 11，内存管理和 GC 表现比 JDK 8 更好。
下载完 JDK 后，在/etc/profile或/etc/environment中写入：
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 export PATH=$PATH:$JAVA_HOME/bin注意：
hadoop-env.sh里也要确认JAVA_HOME指向正确。这个文件默认带的JAVA_HOME往往是空的，不设的话启动脚本会直接报错找不到 Java 环境。
2.2 创建专用用户与 SSH 免密登录
日常操作不建议用 root 跑 Hadoop，权限太大容易误删数据，而且部分脚本在 root 下会有奇怪行为。单独创建一个用户：
useradd -m hadoop passwd hadoop mkdir -p /home/hadoop/.ssh chown -R hadoop:hadoop /home/hadoop/.ssh接下来配置 SSH 免密，这是很多教程一笔带过但实际部署时最耗时间的环节。伪分布式模式只需要本机免密，集群模式每台机器之间都要互通。生成密钥并分发：
su - hadoop ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys # 集群模式需要把公钥复制到所有节点 ssh-copy-id hadoop@node1 ssh-copy-id hadoop@node2免密验证用ssh localhost测试，如果不需要输入密码就说明配置成功。这里有个细节：authorized_keys的权限必须是 600，.ssh目录权限必须是 700，否则 SSH 会出于安全考虑拒绝信任这个文件，排查起来还不好发现是权限问题。
2.3 操作系统级参数调整（不是可选项）
HDFS 是高 IO 应用，操作系统默认的文件描述符限制太小会直接导致 DataNode 崩溃。启动前必须调整：
ulimit -n 65536 echo "hadoop soft nofile 65536" >> /etc/security/limits.conf echo "hadoop hard nofile 65536" >> /etc/security/limits.conf另外建议关闭防火墙或者在防火墙中放行 Hadoop 相关端口。很多“启动成功但页面访问不了”的案例，最后定位全是防火墙把 9870/8088 端口给拦了。如果你的环境是云服务器，还需要在安全组规则里放行这些端口：
| 组件 | 端口 | 说明 |
|---|---|---|
| NameNode Web UI | 9870 | HDFS 管理界面 |
| DataNode Web UI | 9864 | 数据节点状态界面 |
| NameNode RPC | 9000 | 客户端访问 HDFS 的 RPC 端口 |
| YARN ResourceManager Web UI | 8088 | 集群资源管理界面 |
| MapReduce JobHistory | 19888 | 查看历史任务日志 |
3. tar.gz 解压、环境变量与核心配置文件解读
3.1 解压命令与目录结构
拿到hadoop-3.3.6.tar.gz之后，解压操作本身很简单：
mv hadoop-3.3.6.tar.gz /opt/ cd /opt/ tar -zxvf hadoop-3.3.6.tar.gz ln -s /opt/hadoop-3.3.6 /opt/hadoop chown -R hadoop:hadoop /opt/hadoop-3.3.6这里做了个软链/opt/hadoop指向具体版本目录，好处是环境变量里的路径不用写死，以后升级 3.3.7 只需要把新包解压后改一下软链就行。解压后先别急着配置，重点看这几个目录：
etc/hadoop/：所有核心配置文件所在地sbin/：启动和停止集群的脚本（start-dfs.sh、start-yarn.sh）bin/：hdfs、yarn、mapred 等命令行工具share/hadoop/mapreduce/：自带的 MapReduce 示例 jar 包
3.2 环境变量配置
export HADOOP_HOME=/opt/hadoop export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop设置完执行source /etc/profile然后敲hadoop version，能输出版本信息就说明基础环境没问题。这个验证步骤虽然简单，但能提前暴露 JAVA_HOME 配置错误、PATH 没生效等一堆低级问题，属于花十秒省十分钟的操作。
3.3 四个核心配置文件逐项说明
Hadoop 配置的难点不在文件多，而在于叫法相似的参数太多。新手最容易搞混的就是core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml这四个文件各自管什么。我画个简单的分工图帮你记：
core-site.xml管全局，比如 HDFS 访问地址、临时目录hdfs-site.xml管 HDFS 自身，比如副本数、NameNode 和 DataNode 数据存储路径yarn-site.xml管资源调度，比如 ResourceManager 地址、NodeManager 的附属服务mapred-site.xml管计算框架，主要是选择 MapReduce 跑在 YARN 上
伪分布式最小配置：
<!-- core-site.xml --> <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/opt/hadoop/data/tmp</value> </property> </configuration><!-- hdfs-site.xml --> <configuration> <property> <name>dfs.replication</name> <value>1</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>file:///opt/hadoop/data/name</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>file:///opt/hadoop/data/data</value> </property> </configuration><!-- mapred-site.xml --> <configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> </configuration><!-- yarn-site.xml --> <configuration> <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> </configuration>这里单独说明几个关键参数：
dfs.replication=1是伪分布式的固定配置。因为只有一个 DataNode 节点，副本数如果按默认的 3 配置，HDFS 会一直处于“副本不足”的健康告警状态，但实际上没有报错，新手很容易被这种状态搞蒙。
hadoop.tmp.dir决定了 HDFS 的 NameNode 和 DataNode 的元数据默认存储位置。如果你不设置dfs.namenode.name.dir和dfs.datanode.data.dir，系统会默认放在/tmp/hadoop-${user}下，而这个目录重启后可能被系统清空，导致 NameNode 启动时找不到元数据，只能重新格式化，这是一个很隐蔽的坑。
mapred-site.xml这个文件默认不存在，需要先复制模板：
cp /opt/hadoop/etc/hadoop/mapred-site.xml.template /opt/hadoop/etc/hadoop/mapred-site.xml如果不设置mapreduce.framework.name=yarn，JobHistoryServer 能启动但任务跑不起来，日志里会提示找不到 ApplicationMaster。这里注意，mapred-site.xml文件名是mapred，不是mapreduce。
4. 伪分布式搭建实战：格式化、启动与第一个 WordCount
4.1 格式化 NameNode 的操作逻辑
第一次启动 HDFS 之前，必须格式化 NameNode。很多新手忽略了这个步骤，直接执行 start-dfs.sh，然后发现进程起不来，再去查日志才看到NameNode is not formatted之类的报错。
格式化命令：
su - hadoop hdfs namenode -format执行成功后，会在/opt/hadoop/data/name/current目录下生成VERSION文件，里面最重要的是clusterID，这个 ID 后续会写入所有 DataNode 的 VERSION 文件中，用来保证整个集群属于同一个命名空间。
关键提醒：格式化操作只在第一次部署时执行一次。格式化会清空 NameNode 的元数据目录，如果已有数据，格式化就相当于直接把集群“清零”了，数据全部丢失，而且不可恢复。不要因为节点启动失败就习惯性重新格式化，先看日志找原因。
4.2 启动 HDFS 与 YARN
格式化完成后，依次启动 HDFS 和 YARN：
start-dfs.sh start-yarn.sh jpsjps是 JDK 自带的一个小工具，能列出当前用户启动的所有 Java 进程。正常启动后，你应该看到以下 4 个进程：
NameNodeDataNodeSecondaryNameNode（只在伪分布式模式下存在，用于合并 edit logs）ResourceManagerNodeManager
等等，start-dfs.sh和start-yarn.sh一起跑完，总共应该有 NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager 这 5 个进程。如果少了任何一个，说明对应的配置或启动脚本出了问题。此时先去对应的日志目录$HADOOP_HOME/logs/查找错误信息，而不是盲目重启。
如果你经常直接敲start-all.sh，这个脚本在 Hadoop 3.x 中已经被标记为过时，官方推荐分开启动 HDFS 和 YARN。分开的好处是定位问题更清晰，HDFS 出错不会掩盖 YARN 的启动日志。
4.3 跑一个真实的 WordCount 验证集群
配置完成并启动进程后，下一步必须用一个真实的计算任务验证集群可用性，而不是单纯看进程存在。WordCount 就是 Hadoop 的 hello world，自带示例 jar 里就有：
hadoop fs -mkdir -p /input echo "hello hadoop hello hdfs" > /tmp/words.txt hadoop fs -put /tmp/words.txt /input/ hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar wordcount /input /output hadoop fs -cat /output/part-r-00000执行后会看到 MapReduce 的进度日志，从map 100% reduce 100%到最终输出结果。如果顺利输出词频统计，说明整个 HDFS 存储、YARN 调度、MapReduce 计算链路已经完全打通。
这里有几个实操细节：
第一，默认执行用户是 hadoop，如果文件权限不对会报Permission denied。第二，/output目录如果事先存在，任务会直接失败，因为 Hadoop 不允许覆盖已有输出目录，这是设计上的安全机制。第三，执行期间最好实际打开浏览器访问http://localhost:8088看任务的 Running 状态，这一步能直观感受到 ResourceManager 的调度界面，同时确认 Web UI 端口的连通性。
5. 从伪分布式到真实集群：配置差异与多节点部署要点
5.1 集群规划与 hosts 配置
伪分布式只是学习验证用，真实场景至少需要 3 台机器。我习惯用 3 节点的最小化集群来说明：
| 节点 | 角色 | 职责 |
|---|---|---|
| node1 | NameNode + ResourceManager | 主节点，存储元数据，负责任务调度 |
| node2 | DataNode + NodeManager | 数据节点，存储数据块并执行计算任务 |
| node3 | DataNode + NodeManager | 数据节点，存储数据块并执行计算任务 |
先把/etc/hosts配置好，不推荐用 IP 直接配置 hostname，因为集群扩缩容时改配置文件很麻烦，而且 IP 有时候会变：
192.168.1.10 node1 192.168.1.11 node2 192.168.1.12 node35.2 集群模式的核心配置差异
现在重点说伪分布式和集群模式的配置差异，这个搞清楚了，集群部署基本就懂了一半：
首先是core-site.xml中fs.defaultFS的值从localhost改成主节点 hostname：
<property> <name>fs.defaultFS</name> <value>hdfs://node1:9000</value> </property>其次是hdfs-site.xml中dfs.replication从 1 改成 2（3 台节点可以配 2 副本或 3 副本，取决于你对可靠性和存储成本的权衡）：
<property> <name>dfs.replication</name> <value>2</value> </property>然后是yarn-site.xml中新增 ResourceManager 主机名配置：
<property> <name>yarn.resourcemanager.hostname</name> <value>node1</value> </property>最后是workers文件（3.x 版本用这个文件名，2.x 是slaves），把每台 DataNode 的 hostname 写进去，每行一个：
node1 node2 node3主节点包括它自己也可以作为 DataNode 运行，所以把自己写进 workers 也合理。这样start-dfs.sh才会通过 SSH 登录到所有节点拉起 DataNode。
5.3 集群启动的正确顺序与验证
集群模式第一次启动：
- 在 node1 上执行
hdfs namenode -format，只格式化主节点 - 把 node1 的配置目录
etc/hadoop同步到 node2 和 node3（可以用 scp） - 在主节点执行
start-dfs.sh - 在主节点执行
start-yarn.sh
启动完成后，分别在 node2 和 node3 上用jps确认DataNode和NodeManager进程已经启动。然后在任意节点的浏览器访问http://node1:9870，点开 Datanodes 标签页，能看到所有节点的状态、存储容量和最后心跳时间，这比看进程列表更能确认集群健康状况。
很多人配置完集群后喜欢重新格式化 NameNode，这是最恶劣的操作。集群已经写入了数据，格式化之后 clusterID 变化，所有 DataNode 因为 clusterID 不一致而拒绝连接 NameNode，数据全部丢失。记住：格式化只做一次，除非你想彻底清空重建。
6. 高频故障排查：格式化失败、DataNode 异常与端口不通
6.1 格式化失败的完整排查链路
格式化 NameNode 报java.io.IOException: NameNode is not formatted或者直接报文件路径错误，先别慌，按照这个顺序排查：
第一步，确认dfs.namenode.name.dir指向的目录存在且有写权限。很多折腾过的机器上，/opt/hadoop/data/name根本不存在，需要先mkdir -p并chown -R hadoop:hadoop。
第二步，查看格式化日志。格式化信息会同时输出到控制台和$HADOOP_HOME/logs/hadoop-hadoop-namenode-*.log。常见错误是Directory is not empty，处理办法是把 name 目录内容备份后手动清空再格式化。
第三步，确认 JDK 版本。如果安装的是 JDK 17，格式化时可能抛出IllegalAccessError或模块访问异常，因为 Hadoop 3.3.6 还没完全适配高版本 JDK。切换回 JDK 11 再试。
6.2 格式化成功后 DataNode 启动失败
这个故障非常经典：NameNode 启动正常，Web 界面也能打开，但 DataNode 进程启动后十几秒就自动退出或一直处于InSafeMode。排查日志hadoop-hadoop-datanode-nodeX.log，最常见的报错是：
java.io.IOException: Incompatible clusterIDs in ... NameNode clusterID = CID-xxx DataNode clusterID = CID-yyy这个问题的根源是 clusterID 不一致。简单说，格式化 NameNode 时会生成一个新的 clusterID，这个 ID 会写在 NameNode 的元数据目录。当 DataNode 第一次连接 NameNode 时，会把 NameNode 返回的 clusterID 写入自己的数据目录 VERSION 文件。如果之前 DataNode 连过另一个 clusterID 的 NameNode，或者你重新格式化过集群，两边 ID 就对不上了。
解决方案有两种，推荐第二种：
# 方案一：手动修改 DataNode 的 VERSION 文件，把 clusterID 改成 NameNode 的一致 vim /opt/hadoop/data/data/current/VERSION # 方案二（推荐）：停止所有进程，清理数据目录后重新格式化 stop-all.sh rm -rf /opt/hadoop/data/name /opt/hadoop/data/data /opt/hadoop/data/tmp hdfs namenode -format start-all.sh方案二适用于还没有重要数据的场景。如果集群里已经有业务数据，绝对不能重新格式化，只能手动修改 VERSION 文件，或者在 NameNode 上通过hdfs dfsadmin -report查看实际状态后做数据迁移。
6.3 端口检查的正确姿势
Web UI 打不开或客户端连接超时，通常跟进程无关，而是端口问题。先用jps确认进程存活，然后检查端口监听状态：
netstat -tlnp | grep 9870 ss -tlnp | grep 8088如果没有任何输出，说明相关进程的 Web 端口没有启动成功。此时需要确认配置文件中是否写错了端口参数，重点检查dfs.namenode.http-address和yarn.resourcemanager.webapp.address。
如果端口已经在 LISTEN，但外部访问不到，问题基本是防火墙或云安全组。这个环节最容易让人抓狂，因为进程正常、端口正常、本机能访问、其它机器不能访问。最有效的排查方法是先在另一台机器上telnet node1 9870，如果连接超时，直接去看防火墙和安全组配置，而不是继续纠结 Hadoop 本身的配置。
6.4 我的排错习惯
在这个问题上我个人的经验是：所有的故障排查都从日志开始，而不是靠猜。很多新手遇到节点启动不了，第一反应就是反复重启、反复格式化。但 Hadoop 这个框架的日志已经写得非常详细了，每一个启动失败的原因、每一项配置错误，都会在 logs 目录下的.log文件里留下明确的调用栈和错误信息。我们要做的是顺着日志定位到具体配置项，然后有针对性地修复。
第二个经验是：改完任何一个配置文件，都需要重启对应的组件才能生效。有些参数改了却不生效，折腾半天发现是没重启。Hadoop 不会自动热加载配置文件，每次修改后都必须完整执行stop-all.sh再start-all.sh。
第三个经验：jps只是最基础的检查工具，更实用的是hdfs dfsadmin -report和yarn node -list这两个命令行，前者能告诉你每个 DataNode 的存储容量和健康状态，后者能列出所有注册到 ResourceManager 的节点。进程存在不一定代表服务正常，通过管理命令看到的才是集群真实状态。
本文还有配套的精品资源，点击获取
优化CNN-BiLSTM-Attention的风电功率预测研究附Matlab代码)
)