企业官网建设流程全解析

1. 项目概述：为什么现在还要亲手部署Hadoop集群？

Hadoop集群部署（最新版）——这六个字在2024年听到，很多人第一反应是：“不是都上云原生和Flink流批一体了吗？还搞这个干啥？”我去年在某高校大数据实验室带学生做毕业设计时也这么想，直到连续三届学生在面试中被问到“请手绘YARN资源调度流程图”“NameNode高可用如何避免脑裂”，答得磕磕绊绊；直到某公司生产环境因误删一个core-site.xml配置项导致整个离线数仓任务链路中断6小时，运维才翻出尘封的Hadoop部署手册逐行核对。Hadoop集群部署（最新版）从来不是过时技术，而是大数据工程师的“肌肉记忆”和“系统级直觉”的起点。

它解决的不是“能不能跑起来”的问题，而是“为什么这样配”“故障时看哪几行日志”“扩容时哪个组件最先扛不住”的底层认知问题。你不需要用它搭生产平台，但必须能30分钟内从零拉起一个三节点伪分布式集群，验证HDFS读写、MapReduce词频统计、YARN资源申请全流程，并准确说出dfs.namenode.handler.count设为10和30对RPC吞吐的影响边界。这个能力，直接决定你能否看懂Spark on YARN的Container分配逻辑，能否快速定位Flink Checkpoint失败是否源于HDFS小文件过多引发的NameNode GC压力。适合两类人：一是刚接触大数据栈的新手，需要建立完整的分布式存储+计算协同框架认知；二是已有经验的工程师，需补全底层原理断层，把“会用API”升级为“懂系统行为”。

我试过用Docker Compose一键启停，也试过Cloudera Manager图形化安装，但最终坚持回归手动部署——因为只有敲完每一行ssh-copy-id、改完每一个hadoop-env.sh里的JAVA_HOME路径、反复校验/etc/hosts中主机名与IP映射是否严格一致，你才会真正理解：分布式系统的稳定性，90%藏在看似琐碎的环境一致性里。这不是复古情怀，而是工程直觉的必修课。

2. 整体架构设计与方案选型逻辑

2.1 为什么放弃CDH/CDP，坚持Apache原生+手动部署？

当前主流企业确实已转向CDP或云厂商托管Hadoop服务，但手动部署Apache Hadoop最新稳定版（截至2024年，Hadoop 3.3.6是LTS版本）仍有不可替代的价值。核心逻辑在于可控性、可追溯性、教学穿透力三重需求。

• 可控性：CDH/CDP封装了大量自动化脚本和定制化组件（如Cloudera Manager Agent），当遇到DataNode无法注册到NameNode这类问题时，你看到的是“服务状态异常”的红标，而真实原因可能是/var/log/hadoop-hdfs/hadoop-hdfs-datanode-*.log里一行被忽略的java.net.UnknownHostException: namenode-host——这指向core-site.xml中fs.defaultFS配置的主机名未在/etc/hosts中解析。手动部署强制你直面每一层网络、Java、Shell环境依赖，故障排查路径清晰可见。

• 可追溯性：Hadoop 3.x引入了Erasure Coding（纠删码）、S3A FileSystem优化、RBF Router等新特性。CDP往往滞后6-12个月才集成，而手动部署可直接编译源码启用实验性功能。例如某实验室需验证HDFS EC对冷数据存储成本的影响，我们基于3.3.6源码打补丁启用dfs.namenode.ec.support.enabled=true，比等待CDP更新快4个月。

• 教学穿透力：学生通过Cloudera Manager点几下就启停服务，对ResourceManager和NodeManager的进程关系、yarn-site.xml中yarn.resourcemanager.scheduler.class与实际调度器类的映射毫无感知。手动部署要求你明确写出export HADOOP_CONF_DIR=/opt/hadoop/etc/hadoop并理解其作用域，这种“显式声明”是建立系统思维的关键。

提示：本文所有操作均基于Hadoop 3.3.6 + OpenJDK 17（LTS），这是官方文档明确支持的组合。切勿使用OpenJDK 21——尽管它更“新”，但Hadoop 3.3.6的hadoop-common模块中部分反射调用在JDK 21的强封装策略下会抛InaccessibleObjectException，这是踩过的坑。

2.2 集群规模与角色规划：三节点最小可行集群的设计依据

很多教程推荐“五节点集群”，但实际教学和验证场景，三节点（1 Master + 2 Worker）是最优解。理由如下：

• 资源开销最小化：Hadoop 3.x默认启用dfs.namenode.replication.min=1，单DataNode即可满足最小副本要求；YARN的yarn.nodemanager.resource.memory-mb可设为2048MB，两台Worker总内存仅需4GB，普通笔记本虚拟机即可承载。

• 故障模式覆盖完整：三节点能复现90%核心故障。NameNode单点故障？启用HA后即暴露ZKFC脑裂风险；DataNode宕机？触发Block重新复制逻辑；NodeManager失联？暴露yarn.resourcemanager.nm.liveness-monitor.interval-ms心跳超时机制。五节点反而因冗余掩盖关键路径。

• 网络拓扑最简：三节点只需确保Master与Worker间SSH免密、时间同步、主机名解析三要素，避免多节点间防火墙规则、DNS轮询等复杂配置。我曾见团队在七节点集群中因一台Worker的ntpd服务未启动，导致JournalNode日志出现Clock skew detected错误，排查耗时3小时——三节点让这类问题无处遁形。

具体角色分配如下表（所有节点均安装完整Hadoop套件，仅启动不同服务）：

注意：ZooKeeper采用三节点Quorum模式（master+worker1+worker2），而非单点。这是为后续NameNode HA做铺垫，避免二次改造。ZK端口2181需在所有节点开放，且zoo.cfg中server.1、server.2、server.3必须与各节点myid文件内容严格对应。

2.3 网络与安全基线：被90%教程忽略的致命细节

Hadoop对网络环境有隐性强约束，手动部署成败常取决于此：

• 主机名解析必须双向精确：/etc/hosts中不能只写192.168.56.10 hadoop-master，必须补充192.168.56.10 hadoop-master.local（带域名后缀）。因为Hadoop内部使用InetAddress.getCanonicalHostName()获取规范主机名，若无域名后缀，返回值可能为IP地址，导致NameNode拒绝DataNode注册（日志报Invalid datanode）。实测发现，Ubuntu 22.04默认hostname -f返回localhost，必须手动修改/etc/hostname并重启systemd-hostnamed。

• 时间同步误差必须<10ms：HDFS HA依赖ZooKeeper的zxid（事务ID）排序，若节点间时间偏差>10ms，ZK会拒绝写入，导致JournalNode无法同步EditLog。chrony比ntpd更优，因其支持makestep指令强制校正大偏差。配置/etc/chrony/chrony.conf添加makestep 1.0 -1，并执行sudo chronyc makestep立即生效。

• SELinux必须禁用：CentOS/RHEL系默认开启SELinux，会拦截DataNode绑定50010端口（avc: denied { name_bind } for ... port=50010）。setenforce 0仅临时生效，需修改/etc/selinux/config中SELINUX=disabled并重启。Ubuntu系则需确认ufw状态：sudo ufw status应为inactive，若为active，执行sudo ufw disable。

这些不是“高级技巧”，而是Hadoop集群能启动的最低生存门槛。跳过它们，你将陷入“服务进程显示运行中，但hdfs dfs -ls /始终超时”的黑洞。

3. 核心组件部署与配置详解

3.1 Java环境：OpenJDK 17的精准适配

Hadoop 3.3.6官方支持OpenJDK 8/11/17，但实测OpenJDK 17是平衡性最优选择：既规避JDK 8的TLS 1.3缺失（影响S3A连接），又避免JDK 11的-XX:+UseG1GC默认参数在大堆内存下引发长GC停顿。部署步骤必须严格遵循以下顺序：

1. 卸载系统默认Java：Ubuntu常预装openjdk-11-jre，需彻底清除：

   sudo apt purge openjdk-11-jre openjdk-11-jdk sudo apt autoremove

2. 下载并解压OpenJDK 17：从Adoptium官网获取Eclipse Temurin 17.0.8+7（LTS版本），解压至/usr/lib/jvm/：

   sudo tar -xzf temurin-17.0.8+7-jdk_x64_linux_hotspot.tar.gz -C /usr/lib/jvm/ sudo ln -s /usr/lib/jvm/jdk-17.0.8+7 /usr/lib/jvm/java-17-temurin

3. 配置全局JAVA_HOME：编辑/etc/environment，添加：

   JAVA_HOME="/usr/lib/jvm/java-17-temurin" PATH="/usr/lib/jvm/java-17-temurin/bin:$PATH"

   执行source /etc/environment并验证：java -version应输出17.0.8+7，echo $JAVA_HOME应为指定路径。

实操心得：切勿在~/.bashrc中设置JAVA_HOME！Hadoop守护进程（如hadoop-daemon.sh）以root用户启动，读取的是/root/.bashrc而非普通用户文件。/etc/environment是系统级环境变量唯一可靠位置。曾因在此处漏写PATH，导致hdfs namenode -format报command not found，排查2小时才发现是java命令未加入PATH。

3.2 Hadoop核心配置：core-site.xml与hdfs-site.xml的参数深挖

Hadoop配置文件的精髓在于理解每个参数背后的系统行为，而非机械复制。以最关键的两个文件为例：

core-site.xml：定义全局文件系统抽象

<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://hadoop-master:9000</value> <description>默认文件系统URI。注意：此处必须用主机名hadoop-master，而非IP！</description> </property> <property> <name>hadoop.tmp.dir</name> <value>/opt/hadoop/tmp</value> <description>Hadoop临时目录。必须赋予hadoop用户完全权限：chown -R hadoop:hadoop /opt/hadoop/tmp</description> </property> <property> <name>io.compression.codecs</name> <value>org.apache.hadoop.io.compress.GzipCodec,org.apache.hadoop.io.compress.BZip2Codec</value> <description>启用Gzip/BZip2压缩，减少网络传输量。MapReduce作业默认不启用，需在job中显式设置</description> </property> </configuration>

• fs.defaultFS为何必须用主机名？
  HDFS客户端通过InetAddress.getByName("hadoop-master")解析IP，若/etc/hosts中hadoop-master映射正确，则返回192.168.56.10；若此处写IP，客户端将尝试连接192.168.56.10:9000，但NameNode绑定的是hadoop-master:9000（由dfs.namenode.rpc-address指定），导致连接拒绝。这是新手最高频错误。

• hadoop.tmp.dir权限陷阱：
  该目录被NameNode、DataNode、SecondaryNameNode共同使用。若权限为755且属主为root，DataNode启动时会因无法创建/opt/hadoop/tmp/dfs/data/current/VERSION而失败，日志报Permission denied。必须chown -R hadoop:hadoop /opt/hadoop/tmp，且hadoop用户需在所有节点存在（useradd -m hadoop）。

hdfs-site.xml：HDFS行为精细化控制

<configuration> <property> <name>dfs.replication</name> <value>2</value> <description>块副本数。三节点集群设为2，既保证容错（容忍1节点宕机），又避免3副本带来的写放大</description> </property> <property> <name>dfs.namenode.name.dir</name> <value>file:///opt/hadoop/dfs/name</value> <description>NameNode元数据存储路径。强烈建议使用绝对路径，且独立于系统盘</description> </property> <property> <name>dfs.datanode.data.dir</name> <value>file:///opt/hadoop/dfs/data</value> <description>DataNode数据块存储路径。同上，必须独立磁盘分区，避免IO争抢</description> </property> <property> <name>dfs.namenode.handler.count</name> <value>10</value> <description>NameNode处理客户端RPC请求的线程数。计算公式：max(10, 2 * CPU核心数)。双核VM设10足够</description> </property> <property> <name>dfs.client.use.datanode.hostname</name> <value>false</value> <description>客户端连接DataNode时使用主机名还是IP。设false（默认）可避免DNS解析失败，提升稳定性</description> </property> </configuration>

• dfs.replication=2的合理性：
  HDFS默认dfs.replication=3，但在三节点集群中，3副本意味着每个块存满三台机器。当hadoop-worker1宕机，NameNode需立即启动复制，将worker1上的块复制到worker2，此时worker2磁盘IO和网络带宽将达峰值。设为2后，仅需在worker2上补足缺失副本，压力减半。实测在2GB内存VM上，replication=3导致DataNode频繁OOM，replication=2则稳定运行。

• dfs.namenode.handler.count的计算依据：
  该参数直接影响NameNode并发处理能力。线程数过少（如设为5），高并发listStatus请求将排队，客户端超时；过多（如设为50），线程上下文切换开销反超收益。Hadoop官方建议值为2 * CPU核心数，但实测在低配VM上，10是性能与资源消耗的黄金平衡点。可通过jstack <namenode_pid> | grep "IPC Server handler"验证实际线程数。

3.3 YARN资源配置：内存与CPU的硬性配比

YARN的资源管理是集群稳定的核心，错误配置会导致ApplicationMaster无法启动或Container被Kill。关键在于物理内存与虚拟内存的映射关系：

<!-- yarn-site.xml --> <configuration> <property> <name>yarn.resourcemanager.hostname</name> <value>hadoop-master</value> </property> <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>2048</value> <description>NodeManager可分配给Container的总物理内存（MB）</description> </property> <property> <name>yarn.nodemanager.resource.cpu-vcores</name> <value>2</value> <description>NodeManager可分配给Container的总CPU虚拟核数</description> </property> <property> <name>yarn.scheduler.minimum-allocation-mb</name> <value>512</value> <description>单个Container申请的最小内存（MB）。必须整除resource.memory-mb</description> </property> <property> <name>yarn.scheduler.maximum-allocation-mb</name> <value>1024</value> <description>单个Container申请的最大内存（MB）。建议设为resource.memory-mb的一半，防止单任务占满资源</description> </property> <property> <name>yarn.nodemanager.vmem-pmem-ratio</name> <value>2.1</value> <description>虚拟内存与物理内存的比率。Linux默认为2.1，必须与此一致，否则Container因vmem超限被Kill</description> </property> </configuration>

• vmem-pmem-ratio=2.1的强制性：
  Linux内核通过/proc/sys/vm/swappiness控制swap使用，vmem-pmem-ratio是YARN模拟此行为的参数。若设为3.0，YARN允许Container使用3倍物理内存的虚拟内存，但Linux内核实际限制为2.1倍，导致Container在申请内存时被OOM Killer终结，日志报Container [pid=...,containerID=...] is running beyond virtual memory limits。必须cat /proc/sys/vm/swappiness确认值为60（对应ratio≈2.1），否则需调整。

• minimum-allocation-mb=512的实践意义：
  MapReduce的Mapper/Reducer默认内存为1024MB，若minimum-allocation-mb设为1024，则单个Mapper将独占NodeManager全部2048MB内存，第二个任务无法启动。设为512后，一个Mapper可申请1024MB（2个slot），另一个可申请512MB（1个slot），资源利用率提升50%。可通过yarn node -list查看各NodeManager的Memory Total和Memory Used实时验证。

3.4 ZooKeeper集成：为NameNode HA奠基

Hadoop HA依赖ZooKeeper协调NameNode状态，三节点ZK集群是基础。部署非独立ZK，而是复用Hadoop Worker节点，降低资源消耗：

1. 下载解压ZooKeeper 3.8.3（与Hadoop 3.3.6兼容）：

   wget https://downloads.apache.org/zookeeper/zookeeper-3.8.3/apache-zookeeper-3.8.3-bin.tar.gz sudo tar -xzf apache-zookeeper-3.8.3-bin.tar.gz -C /opt/ sudo ln -s /opt/apache-zookeeper-3.8.3-bin /opt/zookeeper

2. 配置zoo.cfg（三节点相同）：

   tickTime=2000 initLimit=10 syncLimit=5 dataDir=/opt/zookeeper/data clientPort=2181 # 三节点Quorum配置 server.1=hadoop-master:2888:3888 server.2=hadoop-worker1:2888:3888 server.3=hadoop-worker2:2888:3888

3. 创建myid文件（每节点唯一）：

   • hadoop-master：echo "1" > /opt/zookeeper/data/myid
   • hadoop-worker1：echo "2" > /opt/zookeeper/data/myid
   • hadoop-worker2：echo "3" > /opt/zookeeper/data/myid

4. 启动ZK并验证：

   # 所有节点执行 /opt/zookeeper/bin/zkServer.sh start # 验证状态（应显示Mode: follower或Mode: leader） /opt/zookeeper/bin/zkServer.sh status

注意：ZK的2888端口用于Follower与Leader同步数据，3888用于选举。防火墙必须开放这两个端口。若zkServer.sh status报Error contacting service, 检查/opt/zookeeper/logs/zookeeper-*.out中是否有Address already in use，常见于端口被占用或/etc/hosts解析失败。

4. 集群启动与验证全流程

4.1 启动顺序与依赖关系：一步错，全盘崩

Hadoop组件启动有严格依赖链，违反顺序将导致服务无法注册或数据不一致：

1. ZooKeeper集群：所有节点zkServer.sh start，zkServer.sh status确认至少一个leader和两个follower。

2. JournalNode集群：HDFS HA必需，独立于NameNode运行。在所有三节点执行：

   # 创建JournalNode数据目录 sudo mkdir -p /opt/hadoop/journalnode sudo chown -R hadoop:hadoop /opt/hadoop/journalnode # 启动JournalNode sudo -u hadoop /opt/hadoop/bin/hdfs --daemon start journalnode # 验证端口监听 ss -tuln | grep 8485 # JournalNode RPC端口

3. 格式化NameNode并同步元数据：

   # 在hadoop-master执行（首次） sudo -u hadoop /opt/hadoop/bin/hdfs namenode -format # 将NameNode元数据同步到JournalNode sudo -u hadoop /opt/hadoop/bin/hdfs namenode -initializeSharedEdits

4. 启动NameNode与DataNode：

   # hadoop-master启动NameNode sudo -u hadoop /opt/hadoop/bin/hdfs --daemon start namenode # 所有Worker节点启动DataNode sudo -u hadoop /opt/hadoop/bin/hdfs --daemon start datanode # 验证HDFS状态 sudo -u hadoop /opt/hadoop/bin/hdfs dfsadmin -report

5. 启动YARN服务：

   # hadoop-master启动ResourceManager sudo -u hadoop /opt/hadoop/bin/yarn --daemon start resourcemanager # 所有Worker节点启动NodeManager sudo -u hadoop /opt/hadoop/bin/yarn --daemon start nodemanager # 验证YARN节点 sudo -u hadoop /opt/hadoop/bin/yarn node -list

关键检查点：hdfs dfsadmin -report输出中，Live datanodes数量应为2，且每台DataNode的Configured Capacity与DFS Remaining值合理（如Configured Capacity: 10737418240即10GB）。若显示0，检查dfs.datanode.data.dir路径权限及磁盘空间。

4.2 核心功能验证：从HDFS读写到MapReduce运行

部署完成不等于可用，必须通过四层验证：

第一层：HDFS基础读写

# 创建测试目录 sudo -u hadoop /opt/hadoop/bin/hdfs dfs -mkdir -p /test/input # 上传本地文件（生成10MB随机数据） dd if=/dev/urandom of=/tmp/test.txt bs=1M count=10 sudo -u hadoop /opt/hadoop/bin/hdfs dfs -put /tmp/test.txt /test/input/ # 验证文件存在且大小正确 sudo -u hadoop /opt/hadoop/bin/hdfs dfs -ls /test/input/ sudo -u hadoop /opt/hadoop/bin/hdfs dfs -du -h /test/input/

预期结果：/test/input/test.txt显示大小为10.0 M。若-du显示0，说明DataNode未成功写入，检查/opt/hadoop/logs/hadoop-hdfs-datanode-*.log中Block pool <BP-...> (Datanode Uuid <...>) is scanning block files日志，确认扫描完成。

第二层：NameNode高可用切换测试

启用HA后，需验证故障转移：

# 查看当前Active NameNode sudo -u hadoop /opt/hadoop/bin/hdfs haadmin -getServiceState nn1 # 手动杀死Active进程（模拟宕机） sudo pkill -f "NameNode.*nn1" # 等待30秒，检查Standby是否升为Active sudo -u hadoop /opt/hadoop/bin/hdfs haadmin -getServiceState nn2 # 验证HDFS仍可读写 sudo -u hadoop /opt/hadoop/bin/hdfs dfs -ls /test/input/

注意：hdfs haadmin命令中的nn1/nn2是hdfs-site.xml中dfs.ha.namenodes.mycluster定义的逻辑名称，非主机名。若切换失败，检查ZK中/hadoop-ha/mycluster路径是否存在，zkCli.sh -server hadoop-master:2181 ls /hadoop-ha/mycluster应返回ActiveBreadCrumb等子节点。

第三层：YARN资源调度验证

# 提交一个空ApplicationMaster测试资源申请 sudo -u hadoop /opt/hadoop/bin/yarn jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.3.6-tests.jar sleep -m 1 -r 1 -mt 1000 -rt 1000 # 查看Application状态 sudo -u hadoop /opt/hadoop/bin/yarn application -list # 进入YARN Web UI：http://hadoop-master:8088，确认Application显示FINISHED

若Application卡在ACCEPTED状态，检查ResourceManager日志中Failed to assign container，常见原因是yarn.scheduler.maximum-allocation-mb大于yarn.nodemanager.resource.memory-mb，导致NodeManager拒绝接收Container。

第四层：MapReduce词频统计实战

# 准备输入文本（含重复单词） echo "hello world hello hadoop world hadoop" > /tmp/input.txt sudo -u hadoop /opt/hadoop/bin/hdfs dfs -put /tmp/input.txt /test/input/ # 运行官方WordCount示例 sudo -u hadoop /opt/hadoop/bin/hadoop jar \ /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar \ wordcount /test/input /test/output # 查看输出结果 sudo -u hadoop /opt/hadoop/bin/hdfs dfs -cat /test/output/part-r-00000

预期输出：

hadoop 2 hello 2 world 2

若报java.lang.RuntimeException: java.lang.ClassNotFoundException: Class org.apache.hadoop.mapred.TextInputFormat，说明mapred-site.xml未正确配置mapreduce.framework.name=yarn。

4.3 Web UI监控与日志诊断：故障排查的第一现场

Hadoop提供丰富的Web界面，是日常监控和故障定位的入口：

• NameNode UI：http://hadoop-master:9870
  关键指标：Live Nodes（应为2）、Total Blocks（应>0）、Under Replicated Blocks（应为0）。若Under Replicated持续增长，说明DataNode心跳丢失或磁盘空间不足。

• ResourceManager UI：http://hadoop-master:8088
  关键指标：Nodes（应为2）、Memory Total（应为4096 MB）、Running Applications（提交任务后应>0）。点击Nodes链接，可查看各NodeManager的Health Report，若显示UNHEALTHY，检查/opt/hadoop/logs/hadoop-yarn-nodemanager-*.log中DiskErrorException。

• DataNode UI：http://hadoop-worker1:9864（各Worker节点独立端口）
  关键指标：Capacity（总容量）、DFS Used（已用）、Non DFS Used（系统占用）。若Non DFS Used异常高，检查/opt/hadoop/dfs/data所在分区是否被其他进程写满。

实操心得：日志文件按日期滚动，hadoop-hdfs-datanode-*.log是核心。搜索关键词：ERROR（致命错误）、WARN（警告，如Slow ReadProcessor表示磁盘慢）、Starting DataNode（启动成功标志）。曾遇DataNode启动后立即退出，日志无ERROR，仅有一行INFO ... ShutdownHookManager: Shutdown hook called，最终发现是/opt/hadoop/dfs/data目录属主为root，chown hadoop:hadoop后解决。日志是真相的唯一来源，别猜，查。

5. 常见问题与独家避坑指南

5.1 启动失败类问题速查表

5.2 性能瓶颈类问题深度解析

问题：DataNode频繁Full GC，HDFS写入缓慢

现象：jstat -gc <datanode_pid>显示FGCT（Full GC时间）持续增长，hdfs dfs -put100MB文件耗时>5分钟。
根因分析：DataNode默认JVM堆内存为1GB（hadoop-env.sh中HADOOP_DATANODE_OPTS="-Xmx1024m"），当处理大文件时，Block元数据对象堆积，触发CMS GC失败后的Serial Old GC，造成STW（Stop-The-World）。
解决方案：

1. 编辑/opt/hadoop/etc/hadoop/hadoop-env.sh，增加：

   export HADOOP_DATANODE_OPTS="-Xmx2048m -XX:+UseG1GC -XX:MaxGCPauseMillis=200"

2. 重启DataNode：sudo -u hadoop /opt/hadoop/bin/hdfs --daemon stop datanode && sudo -u hadoop /opt/hadoop/bin/hdfs --daemon start datanode
3. 验证：jstat -gc <datanode_pid>中G1GGC（G1 GC次数）上升，FGCT趋近于0。

问题：ResourceManagerWeb UI响应迟缓，yarn application -list超时

现象：UI页面加载>30秒，application -list返回Connection refused。
根因分析：ResourceManager默认HTTP服务器线程池为10（yarn.resourcemanager.webapp.rest.csrf.enabled=false关闭CSRF后，线程池未扩容），高并发请求排队。
解决方案：
在yarn-site.xml中添加：

<property> <name>yarn.resourcemanager.webapp.http.address</name> <value>hadoop-master:8088</value> </property> <property> <name>yarn.resourcemanager.webapp.https.address</name> <value>hadoop-master:8090</value> </property> <