简介Apache Hadoop 3.3.3 是面向大数据分布式计算领域的核心开源框架适用于高校学生、大数据初学者及运维开发人员用于搭建本地伪分布式或集群环境开展HDFS存储、MapReduce/YARN计算模型实践与调优实验。资源包为官方二进制发行版 hadoop-3.3.3.tar.gz总大小615.16MB含22536个文件其中HTML文档18870个构成完整离线API与配置手册JAR包449个提供运行时核心类库Shell脚本75个支持集群启停与环境配置CSS/JS/IMG等前端资源超2000个支撑Web UI界面另有原生库文件如libhadoop.so、libhdfs.so等保障本地编译与C API调用能力。目前已有640人学习下载资源结构完整、开箱即用包含全部conf模板、bin工具链、sbin服务脚本及native动态库可直接部署验证Hadoop高可用机制与故障容错设计原理。 Apache Hadoop 这个名字在大数据圈子里几乎绕不开。最近我在整理集群部署文档顺手把 hadoop-3.3.3.tar.gz 这个安装包重新拉了一遍从下载、解压到三节点集群跑通整个过程踩了不少坑也攒了不少经验。这篇就围绕 3.3.3 这个具体版本把从零搭集群的完整流程、核心配置、常见故障以及要不要跟风升到 apache hadoop 3.5.0 的问题放在一起聊透。如果你正准备搭一套 Hadoop 环境或者手上有一套老集群想整理维护这篇文章应该能帮你省下几个周末的试错时间。我会尽量把每一步背后的原因讲清楚不啰嗦也不藏着掖着。配置文件为什么这么写、启动脚本执行时发生了什么、报错日志去哪找这些你都能在下面看到。1. 版本定位为什么是hadoop-3.3.3.tar.gz1.1 从2.x到3.x为什么3.3.3最常用Apache Hadoop 从 2.x 走到 3.x中间经历了很长的生态磨合期。2.x 时代大家习惯的是 MapReduce 跑批、YARN 做资源调度、HDFS 做底层存储。到了 3.x社区把很多积压的架构问题一次性改了Web 端口从 50070 改成 9870RPC 通信全面转向基于协议的方式HDFS 支持纠删码YARN 的 Timeline Service 也重写了。也就是说3.x 不只是一次大版本升级而是对很多基础机制动了刀子。hadoop-3.3.3.tar.gz 是 3.3.x 分支里的一个稳定小版本。我印象最深的是它同时兼容 Java 8 和 Java 11对旧环境特别友好。相比 3.3.6 这种分支末版本以及后来居上的 3.4.x、3.5.x3.3.3 是各类教程、企业部署和课程环境里出现频率最高的一个版本。网上能搜到的资料多遇到问题容易找到答案周边工具大多也是基于这个版本测试的。说白了技术选型里新不等于稳。对一个要长期运行的集群来说生态成熟度和问题可查性往往比版本号新鲜更重要。这也是我到现在还在围绕 3.3.3 写部署文档的原因。1.2 解压hadoop-3.3.3.tar.gz后每个目录是干什么的hadoop-3.3.3.tar.gz 解压之后目录结构并不复杂但很多人一开始会搞混以为 bin 目录下的脚本什么都能干。其实不是。hadoop-3.3.3/ ├── bin # 用户常用命令hdfs、yarn、mapred 都在这里 ├── etc # 所有配置文件所在目录 │ └── hadoop # 核心配置 xml 和 env.sh 都在这里 ├── sbin # 管理员启停脚本start-dfs.sh、stop-dfs.sh 等 ├── lib # 本地动态库主要放 native 压缩库 ├── share # 依赖 jar 包和自带文档 ├── logs # 运行日志部署排障第一站 └── tmp # 默认临时目录生产环境要单独指定我见过不少新手直接改 bin 底下的脚本这是误区。日常操作应该集中在 etc/hadoop 和 sbin 两个目录etc 负责配置调整sbin 负责集群启停。学习环境可以全默认但上生产环境至少要把 logs 和 tmp 挪到单独挂载点避免日志和临时文件把系统盘写满。2. 部署前的环境准备与节点规划2.1 三节点集群规划内存和磁盘怎么分配部署之前想清楚节点规划比闷头改配置重要得多。我用得最多的是三节点方案一台 NameNode ResourceManager两台 DataNode NodeManager。小规模学习、开发联调完全够用。如果磁盘总量要求高可以扩到五节点甚至更多但角色划分套路是一样的。我习惯在做表格事先把集群角色和资源对应起来方便后面分配内存节点角色内存建议磁盘建议node01NameNode, ResourceManager8GB 起步系统盘和数据盘分离node02DataNode, NodeManager4~8GB数据盘尽量大node03DataNode, NodeManager4~8GB数据盘尽量大内存分配直接影响 NameNode 的元数据容量和 YARN 的容器数量。实际部署时要对着总内存切分操作系统留 1~2GBNameNode 堆内存调成总内存的 25%~35%其余留给 YARN。别把所有内存都塞进 JVM容器环境尤其要注意否则系统 OOM 之后你会看到各种奇奇怪怪的现象。2.2 JDK、SSH免密、hosts解析一个都不能少Hadoop 安装的基本盘是 JDK、SSH 免密、系统 hosts 解析这三样没弄好后面全是玄学错误。先装 JDK。3.3.3 支持 Java 8 和 11我推荐 8不是因为它新而是生态兼容最好。安装完必须确认JAVA_HOME写进/etc/profile或每个节点用户的~/.bashrc然后java -version验证。Hadoop 的启动脚本会严格找JAVA_HOME找不到会直接报错退出。然后是 SSH 免密。至少要做到 NameNode 到所有节点包括自己免密登录。操作很固定在 NameNode 上ssh-keygen -t rsa -P -f ~/.ssh/id_rsa然后ssh-copy-id到每个目标节点。测试时直接ssh node02能免密进去才算过。系统参数这块很多人忽略 /etc/hosts。集群内通信用主机名不需要 DNS只要保证每个节点的 /etc/hosts 都有一份一致的映射。如果某个 DataNode 总是失联先看 hosts 对不对。我在排障时见过太多因为 IP 和主机名不匹配导致的诡异问题。2.3 安装包下载与sha512校验下载安装包建议直接从 Apache 官方镜像站或可信 CDN 拿千万别随手搜一个链接。下载后用官方发布的 sha512 文件校验避免包损坏也防替换风险。wget https://archive.apache.org/dist/hadoop/common/hadoop-3.3.3/hadoop-3.3.3.tar.gz wget https://archive.apache.org/dist/hadoop/common/hadoop-3.3.3/hadoop-3.3.3.tar.gz.sha512 sha512sum hadoop-3.3.3.tar.gz把sha512sum输出的哈希值和.sha512文件内容比对一致再继续。我遇到过网络中断导致包不完整解压时报错最后排查半天才发现是包的问题。校验这一步 30 秒能省下大量调试时间。3. 核心配置拆解手把手改好每个xml3.1 hadoop-env.shJAVA_HOME和NameNode堆内存设置装完 Hadoop 之后第一批要改的文件就是etc/hadoop/hadoop-env.sh。至少需要设置两个东西JAVA_HOME和 NameNode 的堆内存。export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 export HADOOP_OPTS$HADOOP_OPTS -Djava.library.path$HADOOP_HOME/lib/native堆内存一般写在HADOOP_NAMENODE_OPTS比如 8GB 内存的节点可以给 NameNode 3GBexport HADOOP_NAMENODE_OPTS-Xms3g -Xmx3g $HADOOP_NAMENODE_OPTS注意-Xms和-Xmx设置成一样防止 JVM 运行时动态伸缩引发 GC 抖动。DataNode 的堆内存默认就够用吞吐型场景不需要调太大。这个设置看起来简单但直接影响 NameNode 能管理的文件数量上限文件越多内存压力越大。3.2 core-site.xmlfs.defaultFS与hadoop.tmp.dircore-site.xml是整个 Hadoop 的地基因为fs.defaultFS定义了默认文件系统地址。集群部署时这里填 NameNode 的 RPC 地址configuration property namefs.defaultFS/name valuehdfs://node01:8020/value /property property namehadoop.tmp.dir/name value/data/hadoop/tmp/value /property /configurationfs.defaultFS配好之后访问文件不再需要写全路径hdfs dfs -ls /就能直接指向集群。hadoop.tmp.dir是默认的临时目录NameNode 的元数据如果没有单独指定dfs.namenode.name.dir就会存在这里。生产环境一定要把它指到大容量磁盘否则 NameNode 首次启动物理空间或 inode 不够后面会很痛苦。3.3 hdfs-site.xml副本数、元数据目录、块大小hdfs-site.xml的配置项非常多但核心就几个副本数、NameNode 元数据目录、DataNode 数据目录。configuration property namedfs.replication/name value2/value /property property namedfs.namenode.name.dir/name value/data/hadoop/name/value /property property namedfs.datanode.data.dir/name value/data/hadoop/data/value /property property namedfs.namenode.secondary.http-address/name valuenode01:9868/value /property property namedfs.blocksize/name value134217728/value /property /configurationdfs.replication在 2.x 默认是 3如果只有两个 DataNode3 副本根本存不下所以三节点环境我习惯设 2。dfs.namenode.name.dir和dfs.datanode.data.dir要指向真实挂载的大容量目录不能放系统盘。块大小dfs.blocksize默认 128MB也就是 134217728 字节不用改跑测试任务时越小的块越容易触发调度开销。这里有个容易忽略的点dfs.namenode.name.dir支持逗号分隔多个目录写两个不同磁盘路径就能实现镜像保护。我有一次只配了一个目录磁盘产生坏道后元数据直接受影响教训很深刻。3.4 yarn-site.xml和mapred-site.xml资源调度与classpathYARN 和 MapReduce 是配合使用的。yarn-site.xml里最关键的是 ResourceManager 地址和 NodeManager 可用资源configuration property nameyarn.resourcemanager.hostname/name valuenode01/value /property property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property property nameyarn.nodemanager.resource.memory-mb/name value4096/value /property property nameyarn.scheduler.maximum-allocation-mb/name value4096/value /property /configurationyarn.nodemanager.aux-services必须设成mapreduce_shuffle否则 MapReduce 任务会卡在 Shuffle 阶段。yarn.nodemanager.resource.memory-mb表示该节点上 YARN 可用的物理内存总量别超过节点实际内存减掉系统、DataNode、NameNode 后的余量。MapReduce 那边需要mapred-site.xml把运行时框架指到 YARN并补上 classpath避免高版本 Hadoop 在跑任务时找不到基础类configuration 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 /configuration3.5 让所有节点知道彼此workers文件和hosts解析Hadoop 3.x 用etc/hadoop/workers文件老版本叫 slaves声明所有 DataNode 和 NodeManager 所在的主机。一行一个节点名不能有空格和多余符号node01 node02 node03配合 hosts 解析start-dfs.sh才会通过 SSH 到这些节点上拉起 DataNode。我踩过的一个坑是 workers 文件里写了 IP 而不是 hostname后面hdfs dfsadmin -report里所有 DataNode 都显示为同一个 IP排查非常费劲。建议统一用 hostname并且每个节点上的 hosts 内容保持一致。4. 集群初始化与启动验证4.1 首次启动前为什么要格式化NameNode配置文件全部就位后第一件大事是格式化 NameNode。命令很简单就一行hdfs namenode -format它做的事情是在dfs.namenode.name.dir指定的目录下生成初始的 fsimage 和 edits 文件。可以理解成给一块新硬盘做分区表没有这个步骤NameNode 启动会认为集群从未初始化直接拒绝工作。注意格式化会清空 NameNode 元数据目录里已有的一切。所以不要在已经存了数据的集群上随手执行这条命令否则等于把整个文件系统的目录索引删了。生产环境做任何升级或迁移前先备份 name 目录。第一次启动环境看到日志里出现Storage directory ... has been successfully formatted就代表成功了。4.2 start-dfs.sh与start-yarn.sh启停流程Hadoop 把启停逻辑封装成了 sbin 下的脚本。启动顺序是 HDFS 先行然后 YARNstart-dfs.sh start-yarn.shstart-dfs.sh会根据配置文件启动 NameNode 和 SecondaryNameNode再根据 workers 文件到各节点拉起 DataNode。start-yarn.sh类似启动 ResourceManager 和 NodeManager。停止时分别执行stop-dfs.sh和stop-yarn.sh。启动之后第一件事是jps检查进程三节点上应分别看到对应角色node01NameNode、SecondaryNameNode、ResourceManagernode02/node03DataNode、NodeManager只看到进程还不够最好再敲一行hdfs dfsadmin -report确认所有 DataNode 都上报了存储容量。这一步才是真正验证集群状态的手段。4.3 通过Web UI验证集群9870和8088端口2.x 时代大家习惯访问http://namenode:50070到 3.x 之后 HDFS 的 Web UI 端口改成了 9870YARN 的 ResourceManager UI 还是 8088。所以 3.3.3 的验证地址是HDFShttp://node01:9870YARNhttp://node01:8088打开 HDFS UI 能看到文件系统概览、DataNode 列表和内存使用情况。打开 YARN UI 能看到活跃应用、队列资源。如果页面打不开先检查防火墙、监听端口和 hosts 解析别急着改配置。4.4 用自带示例跑通wordcount和Pi任务集群起来之后跑通一个小作业比任何检查都有说服力。MapReduce 自带的 wordcount 是最经典的验证任务pi 计算则是测试资源调度最轻量的方式。先在 HDFS 上建目录、放测试文件hdfs dfs -mkdir -p /test/input hdfs dfs -put /etc/profile /test/input/然后跑 wordcounthadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.3.jar wordcount /test/input /test/output跑完看输出hdfs dfs -cat /test/output/part-r-00000如果看到统计结果说明 HDFS 的读写、YARN 的调度、MapReduce 的执行链路是通的。再去 YARN UI 看应用状态确认不是只起了进程但容器调度有问题。pi 任务可以这样跑hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.3.jar pi 2 1000Number of Maps 设 2Number of Samples 设 1000能快速出结果。如果这个任务跑不通多数是 YARN 内存或 classpath 问题。5. 实操中常见故障排查实录5.1 NameNode起不来的排查思路NameNode 启动失败是集群初期遇到最多的故障。有人喜欢反复重启其实日志里已经把原因说得明明白白。默认日志在$HADOOP_HOME/logs/hadoop-user-namenode-host.log启动失败时重点看ERROR之前的堆栈。我碰到过三种情况dfs.namenode.name.dir的目录没有写权限启动时无法创建 fsimage直接失败。hadoop.tmp.dir指定到了不存在且 Hadoop 无权创建的路径。端口 8020 或 9870 被其他进程占用导致 RPC 或 Web 服务绑定失败。常规排查顺序是先tail -200看日志再netstat -lntp确认端口最后检查目录权限。这三步能解决九成启动问题。5.2 DataNode注册不上先查hosts和防火墙DataNode 启动成功了但dfsadmin -report里看不到它或者 Web UI 显示 Live Nodes 少了几个。原因通常不是配置写错而是 hostname 解析和防火墙策略。DataNode 启动时会向 NameNode 注册自己的 hostnameNameNode 向外返回信息也用这个 hostname。如果集群里解析不一致DataNode 可能在自己的节点上能解析 hostnameNameNode 端解析不了注册就会失败。所以 hosts 文件必须全员一致。还有就是防火墙DataNode 到 NameNode 的 8020、9868 端口要放通别只放 SSH。5.3 安全模式卡住怎么办HDFS 启动会进入安全模式此时文件系统只读块上报达到阈值后自动退出。但有时集群一直卡在Safe mode is ON常见原因是 DataNode 上报的副本数不足。一句话解释NameNode 启动时会检查当前可见的块副本数和配置的dfs.replication如果可用副本数达不到阈值它担心数据不完整就不退出安全模式。排查路径hdfs dfsadmin -safemode get hdfs dfsadmin -report看到大量Under-Replicated Blocks时先确认 DataNode 是否都活着。如果是副本数配置高于实际节点数比如三节点配了 3 副本块刚写入还没复制完等它慢慢复制即可。临时应急可以执行hdfs dfsadmin -safemode leave但前提是你确认数据状态健康。强制退出只是让 NameNode 取消保护不会修复底层副本问题。5.4 YARN容器内存溢出的调参方法YARN 任务报Container is running beyond physical memory limits是集群搭建期另一个高频问题。报错时 Container 会被强杀MapReduce 任务失败。排查思路是先看 NodeManager 日志再对照yarn.nodemanager.resource.memory-mb、mapreduce.map.memory.mb、mapreduce.reduce.memory.mb。如果单个 Map Task 需要 1GB但 NodeManager 总资源只有 4GB并发调上 5 个容器就超了。要么加大 NodeManager 总内存要么调低单任务内存两者要匹配。我的经验是测试环境把yarn.scheduler.maximum-allocation-mb和yarn.nodemanager.resource.memory-mb设成同一个值避免调度器分配给 Container 的内存超过 NodeManager 真实可用量。镜像环境下还要考虑权限问题不过那是另一个话题了。6. 从3.3.3到3.5.0要不要升级6.1 3.5.0有哪些实质变化Apache Hadoop 3.5.0 是 3.x 系列的一个比较新的版本社区讨论热度确实上来了。从官方发布说明来看3.5.0 主要是围绕稳定性、性能和生态兼容性做了大量修复同时引入了若干新特性。注意3.5.0 不是另起炉灶的框架它还是继承 HDFS YARN 的主线思路只是内部组件和 API 有不少变化。我在测试环境用过一段时间 3.5.0最直观的感受是部分默认值和兼容性策略有调整比如某些废弃参数被移除启动脚本对 JDK 版本的检查更严格。这意味着直接把 3.3.3 的配置文件拷过去跑大概率会碰到参数不识别的情况。6.2 升级前要做的三个检查如果你考虑升级我的建议是不要直接在生产环境操作至少先完成下面三件事。第一备份 NameNode 元数据。升级过程中任何一步失败回滚都需要完整 fsimage。先把dfs.namenode.name.dir整个目录复制到安全位置。第二对比旧版本的废弃参数。在 3.3.3 上启动时确认日志里有没有警告或者直接翻阅当前etc/hadoop里的配置逐个排查哪些是 3.5.0 已不支持的项。最简单的方式是先用 3.5.0 的默认配置启动再逐个加回自定义参数避免一次引入大量不兼容项。第三在测试集群里跑一遍核心业务作业。升级不仅是版本号变化它可能改变 RPC 行为、调度策略。至少要把读、写、计算、UI 访问都过一遍再决定是否推生产。6.3 究竟要不要升级我个人对升级持有的态度是没有明确收益就不要折腾。3.3.3 用了这么长时间社区知识库、周边工具、公司内部脚本全都验证过了稳定性是实打实的。如果 3.5.0 的新特性对你的业务没有直接帮助保持 3.3.3 是完全合理的做法。但如果你在搭新集群或者因为安全整改必须升级到受支持的版本可以按上一节顺序走一遍。升级过程和搭建新集群的差异不大关键还是配置兼容性的处理。多留一份旧版本安装包也就多留一条退路。最后分享一个我自己踩过坑之后形成的小习惯每次改动配置文件前先cp一份带日期的备份比如core-site.xml.20250101。集群出问题时能快速回到上一个已知能用的状态。这个习惯看起来不起眼但关键时刻真的能救命。本文还有配套的精品资源点击获取