企业官网建设流程全解析

1. 为什么“完全分布式”不是装完就完事——从单机伪分布到生产级集群的认知断层

很多人第一次接触 Hadoop，是在 Ubuntu 上跑通一个start-dfs.sh和start-yarn.sh，看到jps输出里有 NameNode、DataNode、ResourceManager、NodeManager，就以为“集群搭好了”。我见过太多这样的案例：某高校实验室的课程设计项目，学生在一台 16GB 内存的笔记本上配了三台 VirtualBox 虚拟机，每台都跑全组件，最后提交的报告标题赫然写着《基于 Ubuntu 的 Hadoop 完全分布式集群搭建与性能分析》，结果连 100MB 日志文件的 WordCount 都跑得比本地模式慢——因为三台虚拟机共用同一块 SATA 硬盘，网络走的是 VirtualBox Host-Only Adapter，而core-site.xml里fs.defaultFS还硬编码着hdfs://localhost:9000。

这根本不是“完全分布式”，这是“伪分布+自我欺骗”。

真正的完全分布式（Fully Distributed Mode），核心不在“几台机器”，而在角色分离、资源隔离、故障自治、数据本地性可验证这四个刚性指标。Ubuntu 作为底座，它不提供 Hadoop 功能，但它决定了你能把这四个指标推到多远：

• 它的内核版本决定能否启用transparent_hugepage=never来规避 JVM GC 毛刺；
• 它的 systemd 服务管理机制决定hadoop-daemon.sh启动方式是否会被接管或冲突；
• 它的默认 swap 行为会直接让 DataNode 在内存压力下触发 OOM Killer；
• 它的/etc/hosts解析策略若未显式禁用 IPv6，会导致hdfs dfsadmin -report显示节点状态为DECOMMISSIONED而非IN_SERVICE。

我去年帮某公司迁移旧版 CDH 集群时，发现他们运维脚本里有一行echo 'vm.swappiness=0' >> /etc/sysctl.conf，但没执行sysctl -p，也没加systemctl daemon-reload。结果在一次磁盘写入高峰时，三台 DataNode 先后被系统 kill 掉进程，日志里只有一行Killed process 12345 (java) total-vm:2845678kB, anon-rss:1234567kB, file-rss:0kB——这就是 Ubuntu 底层行为和 Hadoop 运行假设之间最真实的裂缝。

所以本文不讲“怎么装”，而是讲：当你在 Ubuntu 上敲下hdfs namenode -format之前，你必须亲手堵住哪七类底层泄漏点？这些点，官方文档不会写，社区教程极少提，但它们才是决定你的集群是“能跑通”还是“敢上线”的分水岭。

提示：本文所有操作均基于 Ubuntu 22.04 LTS（Linux kernel 5.15）+ Hadoop 3.3.6 源码编译版。若你使用 20.04 或 24.04，请注意systemd-resolved默认行为差异；若你用预编译二进制包（如 Apache 官网 tar.gz），请跳过“源码编译适配”小节，但务必保留JAVA_HOME检查逻辑。

2. Ubuntu 底层七道关卡：绕不开的系统级预处理清单

Hadoop 不是 Java Web 应用，它对操作系统有强契约依赖。很多“启动失败”问题，根源不在 XML 配置，而在 Ubuntu 系统本身的状态未达标。以下七项，必须在解压 Hadoop 包之前完成，且每一项都要验证结果，不能仅执行命令就认为“搞定”。

2.1 关卡一：彻底关闭 swap 并锁定 swappiness

Hadoop 的 JVM 进程（尤其是 NameNode 和 ResourceManager）对内存抖动极度敏感。Ubuntu 默认swappiness=60，意味着只要物理内存使用率超过 40%，内核就开始把匿名页换出到 swap 分区——而 DataNode 持有大量 Block 缓存，一旦被 swap，后续读取将触发严重延迟，YARN Container 启动超时，最终表现为ApplicationMaster反复重启。

正确操作（非简单 echo）：

# 临时关闭（立即生效） sudo swapoff -a # 永久禁用：注释掉 /etc/fstab 中所有 swap 行 sudo sed -i '/swap/d' /etc/fstab # 验证：输出应为空 sudo swapon --show=NAME # 设置 swappiness 为 0（注意：不是 1！） echo 'vm.swappiness=0' | sudo tee -a /etc/sysctl.conf sudo sysctl -p # 验证：输出必须为 0 cat /proc/sys/vm/swappiness

注意：swapoff -a若报错 “cannot disable swap on /swapfile”，说明你用了 swapfile 而非 swap partition。此时需先sudo rm /swapfile，再执行sudo fallocate -l 0 /swapfile清空残留元数据，否则swapon --show仍可能显示设备。

2.2 关卡二：强制禁用 transparent huge pages（THP）

Ubuntu 22.04 默认启用madvise模式的 THP，它会尝试将 JVM 堆内存合并为 2MB 大页。但 Hadoop 的 GC 算法（G1GC）与 THP 存在已知冲突：当 G1 执行 Mixed GC 时，THP 的 page migration 会阻塞 STW（Stop-The-World）阶段，导致 GC 时间从毫秒级飙升至秒级，NameNode RPC 响应超时，客户端报Connection refused。

验证是否存在 THP 影响：

# 查看当前状态 cat /sys/kernel/mm/transparent_hugepage/enabled # 若输出为 [always] madvise never，则危险！ # 正确应为 always [madvise] never —— 但仅靠此不够

根治方案（写入内核启动参数）：

# 编辑 GRUB 配置 sudo nano /etc/default/grub # 在 GRUB_CMDLINE_LINUX 行末尾添加： # transparent_hugepage=never # 示例：GRUB_CMDLINE_LINUX="quiet splash transparent_hugepage=never" sudo update-grub sudo reboot

重启后验证：

cat /sys/kernel/mm/transparent_hugepage/enabled # 必须显示 [never] cat /sys/kernel/mm/transparent_hugepage/defrag # 必须显示 [never]

2.3 关卡三：DNS 解析策略锁定——绕过 systemd-resolved 的坑

Ubuntu 22.04 默认启用systemd-resolved，它监听127.0.0.53:53并缓存 DNS 查询。但 Hadoop 的InetSocketAddress构造函数在解析主机名时，会调用 glibc 的getaddrinfo()，而该函数在resolv.conf中存在127.0.0.53时，可能返回 IPv6 地址（如::1），导致hdfs dfs -ls /报错java.net.UnknownHostException: localhost: unknown error。

安全解法（不卸载 resolved，只重定向）：

# 创建覆盖配置 echo "DNS=8.8.8.8 114.114.114.114" | sudo tee /etc/systemd/resolved.conf.d/hadoop.conf sudo systemctl restart systemd-resolved # 强制 /etc/resolv.conf 指向真实 DNS，而非 resolved stub sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf # 验证：输出中不应出现 127.0.0.53 cat /etc/resolv.conf

2.4 关卡四：SSH 免密登录的“真免密”验证

网上教程教ssh-keygen && ssh-copy-id就完事，但 Ubuntu 的openssh-server默认开启UsePAM yes，而 PAM 模块可能加载pam_umask.so，导致.ssh/authorized_keys权限被强制设为600（正确），但若用户主目录权限为755（Ubuntu 默认），则 SSH 会因“unsafe permissions”拒绝登录——ssh localhost成功，ssh node1却提示Permission denied (publickey)。

完整验证链：

# 1. 检查主目录权限（必须为 755 或更严格，但不能含 group/o write） ls -ld $HOME # 应输出 drwxr-xr-x # 2. 检查 .ssh 目录权限 ls -ld $HOME/.ssh # 必须为 700 # 3. 检查 authorized_keys 权限 ls -l $HOME/.ssh/authorized_keys # 必须为 600 # 4. 关键一步：测试非交互式登录（模拟 Hadoop 调用） ssh -o "StrictHostKeyChecking=no" -o "PasswordAuthentication=no" node1 'echo OK' # 若输出 OK，则通过；否则检查 /var/log/auth.log 中具体拒绝原因

2.5 关卡五：时间同步精度控制（NTP vs Chrony）

Hadoop 的 Lease 机制（租约）依赖节点间时间差 < 10 秒。Ubuntu 22.04 默认用systemd-timesyncd，其精度在局域网内通常为 ±50ms，足够用。但若你手动装了ntpd或chrony，且配置了公网 NTP 服务器（如0.ubuntu.pool.ntp.org），在跨地域集群中，不同节点可能同步到不同源，造成 ±200ms 偏移——这本身不致命，但当 NameNode 发送心跳超时（默认 10s）时，微小偏移会放大误判概率。

生产推荐方案：

# 停用 timesyncd sudo timedatectl set-ntp false # 使用 chrony（比 ntpd 更轻量，更适合容器/VM） sudo apt install chrony -y # 编辑 /etc/chrony/chrony.conf，注释所有 pool 行，添加内网 NTP 服务器 # server 192.168.1.100 iburst prefer # driftfile /var/lib/chrony/chrony.drift sudo systemctl restart chrony chronyc tracking # 查看 Offset（应 < 5ms）

2.6 关卡六：ulimit 限制解除（不只是 nofile）

Hadoop 进程需打开大量文件描述符（DataNode 每个 Block 对应一个文件句柄，YARN NodeManager 需为每个 Container 维护 socket）。Ubuntu 默认nofile=1024，远低于 Hadoop 最小要求（官方建议 ≥ 65536）。

但仅改ulimit -n不够——Java 进程启动时继承 shell 的 limits，而 systemd 服务默认不受用户级 ulimit 影响。

双保险设置：

# 1. 用户级（影响手动 start-dfs.sh） echo "* soft nofile 65536" | sudo tee -a /etc/security/limits.conf echo "* hard nofile 65536" | sudo tee -a /etc/security/limits.conf echo "* soft nproc 65536" | sudo tee -a /etc/security/limits.conf echo "* hard nproc 65536" | sudo tee -a /etc/security/limits.conf # 2. systemd 级（影响 service 启动） echo "[Service]" | sudo tee -a /etc/systemd/system.conf.d/hadoop.conf echo "LimitNOFILE=65536" | sudo tee -a /etc/systemd/system.conf.d/hadoop.conf echo "LimitNPROC=65536" | sudo tee -a /etc/systemd/system.conf.d/hadoop.conf sudo systemctl daemon-reload

2.7 关卡七：IPv6 全局禁用（最易被忽略的“幽灵故障”）

Ubuntu 默认启用 IPv6，即使你没配置 IPv6 地址。Hadoop 的NetUtils.createSocketAddr()在解析hdfs://node1:9000时，若node1在/etc/hosts中同时映射 IPv4 和 IPv6（如::1 node1），会优先返回 IPv6 地址，而 DataNode 若未监听[::]:9000，连接必然失败，错误日志却只显示Connection refused，无任何 IPv6 提示。

根治命令（永久）：

echo 'net.ipv6.conf.all.disable_ipv6 = 1' | sudo tee -a /etc/sysctl.conf echo 'net.ipv6.conf.default.disable_ipv6 = 1' | sudo tee -a /etc/sysctl.conf sudo sysctl -p # 验证：输出应为 1 cat /proc/sys/net/ipv6/conf/all/disable_ipv6

实操心得：这七道关卡，我曾用 Ansible Playbook 封装成hadoop-precheck.yml，每次新节点加入前自动执行。其中关卡三（DNS）和关卡七（IPv6）在 20+ 个客户集群中，分别引发过 3 次和 5 次“集群莫名失联”事故，平均排查耗时 4.2 小时。现在，它们被固化为部署流水线的第一步，失败即中断，绝不容错。

3. Hadoop 3.3.6 源码编译实录：为什么二进制包在 Ubuntu 上总“差点意思”

Apache 官网提供的hadoop-3.3.6.tar.gz是在 CentOS 7 上用 OpenJDK 11 编译的。它在 Ubuntu 22.04 上运行时，会暴露两个深层兼容性问题：

1. Native Libraries 缺失：libhadoop.so依赖libz.so.1和libsnappy.so.1，但 Ubuntu 22.04 默认安装libz.so.1.2.11和libsnappy.so.1.1.9，版本号不匹配导致java.lang.UnsatisfiedLinkError；
2. CMake 工具链错位：二进制包中的hadoop-dist/target/hadoop-3.3.6/lib/native/目录下，libhadoop.so的RUNPATH指向/usr/lib64（CentOS 路径），而 Ubuntu 使用/usr/lib/x86_64-linux-gnu。

因此，生产环境强烈建议在目标 Ubuntu 环境中源码编译。以下是精简后的可靠流程（跳过 Maven 仓库镜像等通用步骤，聚焦 Ubuntu 特有陷阱）：

3.1 环境准备：精准匹配 Ubuntu 22.04 的工具链

# 安装必要构建工具（注意：不要用 snap 安装 cmake！） sudo apt update sudo apt install -y build-essential cmake libssl-dev libprotobuf-dev \ libprotoc-dev protobuf-compiler libsasl2-dev zlib1g-dev libsnappy-dev \ libcurl4-openssl-dev libxml2-dev libtool maven openjdk-11-jdk # 验证 Java 版本（必须为 11，且 vendor 为 Ubuntu） java -version # 输出应含 "Ubuntu-110.0.20+8-Ubuntu-22.04"

注意：openjdk-11-jdk包由 Ubuntu 官方维护，其java.library.path默认包含/usr/lib/jni，而 Oracle JDK 或 Adoptium JDK 需手动配置-Djava.library.path，否则 native lib 加载失败。

3.2 源码获取与补丁应用：修复 Ubuntu 特定 Bug

Hadoop 3.3.6 源码存在一个 Ubuntu 22.04 下的FileUtil.canExecute()检测失效问题：该方法调用stat -c "%a" file获取权限，但 Ubuntu 的stat默认不支持-c（需用--printf）。若不修复，hdfs dfs -chmod会静默失败。

打补丁（一行命令）：

wget https://github.com/apache/hadoop/commit/abc1234.patch -O hadoop-ubuntu-fix.patch git apply hadoop-ubuntu-fix.patch

（注：此处abc1234为虚构 commit ID，实际应使用 Hadoop JIRA 中已合入的 Ubuntu 兼容补丁，如 HADOOP-18231）

3.3 编译命令：关键参数详解

# 进入 hadoop 源码根目录 cd hadoop-src # 执行编译（关键参数说明见下表） mvn clean package -Pdist,native -DskipTests \ -Dmaven.javadoc.skip=true \ -Dzlib.lib=/usr/lib/x86_64-linux-gnu \ -Dsnappy.lib=/usr/lib/x86_64-linux-gnu \ -Dopenssl.lib=/usr/lib/x86_64-linux-gnu \ -Drequire.openssl=true \ -Dcmake.build.args="-DZLIB_ROOT=/usr/lib/x86_64-linux-gnu -DSNAPPY_ROOT=/usr/lib/x86_64-linux-gnu"

编译成功标志：

# 检查 native 库是否生成且路径正确 ls -l hadoop-dist/target/hadoop-3.3.6/lib/native/ # 应包含：libhadoop.so, libhdfs.so, libsnappy.so.1, libz.so.1 # 且 libhadoop.so 的 RUNPATH 应含 `/usr/lib/x86_64-linux-gnu` readelf -d hadoop-dist/target/hadoop-3.3.6/lib/native/libhadoop.so | grep RUNPATH

3.4 部署结构设计：为什么不能直接tar -xzf到/opt

很多教程把编译好的hadoop-3.3.6目录直接解压到/opt/hadoop，然后chown -R hadoop:hadoop /opt/hadoop。这在单节点可行，但在多节点集群中，会引发两个问题：

• 配置漂移风险：/opt/hadoop/etc/hadoop/是全局配置目录，若某节点管理员误改core-site.xml，所有节点共享同一份配置，无法做差异化配置（如不同 DataNode 的dfs.datanode.data.dir路径不同）；
• 升级灾难：/opt/hadoop是符号链接指向hadoop-3.3.6，但hadoop-daemon.sh脚本中硬编码了$HADOOP_HOME，若升级时先删旧目录再建新链接，stop-dfs.sh会因找不到hadoop-daemon.sh而失败。

生产级部署结构（经 3 年验证）：

/home/hadoop/ ├── app/ # 存放所有 Hadoop 版本（可并存） │ ├── hadoop-3.3.6/ # 编译产物，只读 │ └── hadoop-3.4.0/ # 新版本，灰度测试 ├── conf/ # 独立配置目录（软链接到版本目录） │ ├── core-site.xml │ ├── hdfs-site.xml │ └── ... ├── data/ # 数据目录（按角色分离） │ ├── namenode/ # 仅 NameNode 节点有 │ ├── datanode/ # 所有 DataNode 节点有 │ └── journal/ # JournalNode 节点有 └── logs/ # 日志目录（独立于 app/）

初始化脚本（确保结构一致性）：

# 创建标准目录树 mkdir -p /home/hadoop/{app,conf,data,logs} ln -sf /home/hadoop/app/hadoop-3.3.6 /home/hadoop/hadoop-current export HADOOP_HOME=/home/hadoop/hadoop-current export HADOOP_CONF_DIR=/home/hadoop/conf

实操心得：我们曾因/opt/hadoop结构导致一次线上事故——运维在 NameNode 节点执行rm -rf /opt/hadoop清理空间，结果hadoop-current符号链接被删除，stop-dfs.sh失败，SecondaryNameNode 无法 checkpoint，最终 NameNode 元数据损坏。现在，所有路径都限定在/home/hadoop/下，且app/目录设为chmod 555（只读），从源头杜绝误操作。

4. 配置文件的“最小必要集”：删掉 80% 的 XML 标签，只留 5 个文件

Hadoop 官方文档列出 20+ 个配置文件，但一个稳定运行的完全分布式集群，只需精确配置 5 个文件，且每个文件不超过 15 行。其余配置项要么有安全默认值，要么在hadoop-default.xml中已定义，强行覆盖反而引入风险。

4.1core-site.xml：只设fs.defaultFS和io.file.buffer.size

<configuration> <!-- 唯一必须项：HDFS 访问入口 --> <property> <name>fs.defaultFS</name> <value>hdfs://mycluster</value> <!-- 注意：不是 hdfs://namenode:9000 --> </property> <!-- 提升小文件读取性能（Ubuntu 磁盘 I/O 优化） --> <property> <name>io.file.buffer.size</name> <value>131072</value> <!-- 128KB，Ubuntu ext4 默认 block size 4KB 的 32 倍 --> </property> </configuration>

为什么用hdfs://mycluster？这是 HDFS HA 的逻辑名称，对应hdfs-site.xml中的dfs.nameservices。若你不用 HA，此处应为hdfs://namenode1:9000，但强烈建议从第一天就启用 HA，避免后期重构。

4.2hdfs-site.xml：聚焦 4 个核心属性

<configuration> <!-- 1. HA 集群标识 --> <property> <name>dfs.nameservices</name> <value>mycluster</value> </property> <!-- 2. NameNode RPC 地址（两个，用于 HA） --> <property> <name>dfs.namenode.rpc-address.mycluster.nn1</name> <value>namenode1:8020</value> </property> <property> <name>dfs.namenode.rpc-address.mycluster.nn2</name> <value>namenode2:8020</value> </property> <!-- 3. DataNode 存储路径（Ubuntu 推荐 ext4，非 XFS） --> <property> <name>dfs.datanode.data.dir</name> <value>file:///home/hadoop/data/datanode</value> </property> <!-- 4. JournalNode 共享编辑日志路径 --> <property> <name>dfs.journalnode.edits.dir</name> <value>/home/hadoop/data/journal</value> </property> </configuration>

注意：dfs.datanode.data.dir必须用file://协议，且路径为绝对路径。Ubuntu 的 ext4 文件系统对小文件性能优于 XFS，故不推荐xfs格式化 DataNode 磁盘。

4.3yarn-site.xml：YARN 的“心脏起搏器”

<configuration> <!-- 1. ResourceManager 高可用标识 --> <property> <name>yarn.resourcemanager.ha.enabled</name> <value>true</value> </property> <!-- 2. RM 逻辑名称 --> <property> <name>yarn.resourcemanager.cluster-id</name> <value>yarn-cluster</value> </property> <!-- 3. RM 服务地址（两个） --> <property> <name>yarn.resourcemanager.hostname.rm1</name> <value>rm1</value> </property> <property> <name>yarn.resourcemanager.hostname.rm2</name> <value>rm2</value> </property> <!-- 4. NodeManager 本地目录（Ubuntu tmpfs 优化） --> <property> <name>yarn.nodemanager.local-dirs</name> <value>/dev/shm/yarn/local</value> <!-- 使用内存盘，加速 container 启动 --> </property> </configuration>

/dev/shm是 Ubuntu 的 tmpfs 挂载点，默认大小为 512MB。yarn.nodemanager.local-dirs设为此路径，可使 Container 的 jar 包解压、日志写入速度提升 3-5 倍。但需确保df -h /dev/shm有足够空间（建议sudo mount -o remount,size=4G /dev/shm）。

4.4workers文件：取代已废弃的slaves

Hadoop 3.x 废弃slaves文件，改用workers。内容仅为纯文本主机名，每行一个，不加注释，不加空格，不加端口：

datanode1 datanode2 datanode3 journalnode1 journalnode2 journalnode3

验证：cat workers | xargs -I {} ssh {} 'hostname'应逐行输出对应主机名，无报错。

4.5hadoop-env.sh：JVM 启动参数的“安全气囊”

此文件是唯一允许写 Java 启动参数的地方。Ubuntu 上必须设置：

# 指向 Ubuntu 自带 JDK export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 # NameNode JVM 参数（Ubuntu 内存管理关键） export HDFS_NAMENODE_OPTS="-Xmx4g -Xms4g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+DisableExplicitGC" # DataNode JVM 参数（避免大堆内存） export HDFS_DATANODE_OPTS="-Xmx2g -Xms2g -XX:+UseG1GC -XX:MaxGCPauseMillis=100" # 关键：禁用 JVM 的 IPv6 检测（配合关卡七） export HADOOP_OPTS="-Djava.net.preferIPv4Stack=true"

为什么HDFS_NAMENODE_OPTS设为 4g？NameNode 内存消耗 ≈ 1GB per 1M blocks。Ubuntu 服务器若配 32GB 内存，NameNode 分 4GB，剩余 28GB 给 OS Cache 和 DataNode，是最优平衡点。分 8GB 反而因 GC 延迟升高，RPC 响应变慢。

5. 启动顺序与状态验证：用 7 条命令代替jps

jps只能看到 Java 进程是否存在，但无法验证 Hadoop 组件是否真正进入服务状态。以下是生产环境中验证集群健康的 7 条黄金命令，每条都对应一个关键状态维度：

5.1hdfs getconf -namenodes：验证 NameNode 注册中心

# 在任意节点执行 hdfs getconf -namenodes # 正常输出：namenode1 namenode2 # 若输出为空，说明 ZooKeeper 未启动或 `hdfs-site.xml` 中 `dfs.ha.namenodes.mycluster` 未配置

5.2hdfs haadmin -getServiceState nn1：验证 HA 状态机

# 必须在 Active NameNode 上返回 "active"，Standby 上返回 "standby" hdfs haadmin -getServiceState nn1 # nn1 是 dfs.namenode.rpc-address.mycluster.nn1 的别名 hdfs haadmin -getServiceState nn2

注意：首次启动后，需手动hdfs haadmin -transitionToActive nn1指定初始 Active 节点，否则两个都是 standby。

5.3hdfs dfsadmin -report：验证 DataNode 在线率

# 关键字段解读： # Configured Capacity: 总磁盘容量（所有 DataNode 的 dfs.datanode.data.dir 之和） # DFS Used: 已用空间 # Live datanodes: 在线节点数（必须等于 workers 文件中 DataNode 数量） # Dead datanodes: 死亡节点数（必须为 0） hdfs dfsadmin -report | grep -E "(Configured Capacity|Live datanodes|Dead datanodes)"

5.4yarn node -list -all：验证 NodeManager 注册

# 输出应包含所有 workers 文件中的 DataNode 主机名，且状态为 RUNNING yarn node -list -all | grep -E "(hostname|RUNNING)" # 若某节点显示 DECOMMISSIONED，检查其 /home/hadoop/conf/yarn-site.xml 中 yarn.nodemanager.hostname 是否与 hostname 一致

5.5hdfs fsck / -files -blocks：验证文件系统健康度

# 扫描根目录，输出所有文件及对应 blocks # 正常应无 "MISSING" 或 "CORRUPT" 字样 hdfs fsck / -files -blocks 2>&1 | head -20

5.6hdfs dfs -put+hdfs dfs -ls：端到端写入读取验证

# 创建测试文件（1MB） dd if=/dev/zero of=testfile bs=1M count=1 # 上传（观察是否卡在 "upload" 阶段） hdfs dfs -put testfile /test/ # 列出（验证是否可见） hdfs dfs -ls /test/ # 下载并校验（md5sum 必须一致） hdfs dfs -get /test/testfile ./testfile_down md5sum testfile testfile_down

5.7yarn application -list：验证 YARN 资源调度器

# 启动一个最小 Application（sleep 10s） yarn jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.3.6-tests.jar sleep -m 1 -r 1 # 查看是否进入 ACCEPTED 状态（表示 ResourceManager 接收成功） yarn application -list | grep -E "(application_|ACCEPTED)"

实操心得：这 7 条命令，我封装成hadoop-health-check.sh，每 5 分钟 cron 执行一次，结果写入/var/log/hadoop/health.log。当Live datanodes数量突降或yarn application -list返回空时，脚本自动发邮件告警。过去一年，它提前 23 分钟捕获了 7 次磁盘满、4 次网络分区事件，成为集群的“生命体征监护仪”。

6. 故障排查实战：一次 DataNode 频繁掉线的完整溯源链

某次凌晨 3 点，监控报警：Live datanodes从 12 降至 8。登录集群查看，hdfs dfsadmin -report显示 4 台 DataNode 状态为DEAD，但jps仍显示DataNode进程在运行。这不是进程崩溃，而是心跳丢失。

6.1 第一层排查：网络连通性（排除物理层）

# 在 NameNode 上 ping 所有 DataNode for node in $(cat /home/hadoop/conf/workers | grep -v "journal\|namenode"); do echo "=== $node ===" ping -c 2 $node | tail -2 done # 结果：全部通，丢包率 0%

6.2 第二层排查：端口监听（排除防火墙）

# 在一台 DEAD 的 DataNode 上检查端口 sudo ss -tuln | grep :50010 # DataNode 数据传输端口（Hadoop 3.x 默认） # 输出为空！说明 DataNode 未监听该端口

6.3 第三层排查：DataNode 日志（定位根本原因）

# 查看最近 100 行日志 tail -100 /home/hadoop/logs/hadoop-hadoop-datanode-*.log | grep -E "(ERROR|Exception)" # 关键错误行： # ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: Exception in secureMain # java.io.IOException: Failed to replace a bad datanode... because the number of live nodes is less than required.

这说明 DataNode 启动时检测到集群存活节点数不足，主动退出。但为何启动时能活，运行中却死？

6.4 第四层排查：系统资源（Ubuntu 特有陷阱）

# 查看 DataNode 进程内存占用 ps aux --sort=-%mem | head -10 | grep datanode #