简介这是 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 变成了 9870DataNode 从 50075 变成了 9864。如果你以前背过 2.x 的端口号到 3.x 得改一下肌肉记忆。支持 JDK 8 和 11Hadoop 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 版本、用户与 SSH2.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 hadoopnode1 ssh-copy-id hadoopnode2免密验证用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 UI9870HDFS 管理界面DataNode Web UI9864数据节点状态界面NameNode RPC9000客户端访问 HDFS 的 RPC 端口YARN ResourceManager Web UI8088集群资源管理界面MapReduce JobHistory19888查看历史任务日志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.shbin/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 namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/opt/hadoop/data/tmp/value /property /configuration!-- hdfs-site.xml -- configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name valuefile:///opt/hadoop/data/name/value /property property namedfs.datanode.data.dir/name valuefile:///opt/hadoop/data/data/value /property /configuration!-- mapred-site.xml -- configuration property namemapreduce.framework.name/name valueyarn/value /property /configuration!-- yarn-site.xml -- configuration property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property /configuration这里单独说明几个关键参数dfs.replication1是伪分布式的固定配置。因为只有一个 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.nameyarnJobHistoryServer 能启动但任务跑不起来日志里会提示找不到 ApplicationMaster。这里注意mapred-site.xml文件名是mapred不是mapreduce。4. 伪分布式搭建实战格式化、启动与第一个 WordCount4.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 和 YARNstart-dfs.sh start-yarn.sh jpsjps是 JDK 自带的一个小工具能列出当前用户启动的所有 Java 进程。正常启动后你应该看到以下 4 个进程NameNodeDataNodeSecondaryNameNode只在伪分布式模式下存在用于合并 edit logsResourceManagerNodeManager等等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 节点的最小化集群来说明节点角色职责node1NameNode ResourceManager主节点存储元数据负责任务调度node2DataNode NodeManager数据节点存储数据块并执行计算任务node3DataNode 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改成主节点 hostnameproperty namefs.defaultFS/name valuehdfs://node1:9000/value /property其次是hdfs-site.xml中dfs.replication从 1 改成 23 台节点可以配 2 副本或 3 副本取决于你对可靠性和存储成本的权衡property namedfs.replication/name value2/value /property然后是yarn-site.xml中新增 ResourceManager 主机名配置property nameyarn.resourcemanager.hostname/name valuenode1/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 的节点。进程存在不一定代表服务正常通过管理命令看到的才是集群真实状态。本文还有配套的精品资源点击获取