1. 这不是“背命令”，而是理解Hadoop生态的运行脉络
你搜“hadoop集群启动停止命令”，点开一堆博客，复制粘贴几行shell就完事——结果namenode起不来、yarn ResourceManager报错、spark-shell连不上master，最后卡在日志里翻到凌晨三点。我干这行十年，带过三十多个Hadoop项目，最常听到的抱怨不是“不会写MapReduce”，而是“集群启停像拆炸弹”。为什么？因为这些命令从来不是孤立存在的指令，它们是整个分布式系统状态流转的开关。namenode不是“start-dfs.sh”一敲就活了，它背后牵着ZooKeeper的选举、JournalNode的日志同步、DataNode的心跳注册；yarn的start-yarn.sh启动的不只是ResourceManager，还有NodeManager的本地资源管理器、ApplicationMaster的调度容器、甚至可能触发Spark on YARN的Driver注册流程。你看到的是五个服务（namenode、datanode、yarn、spark、hive），实际背后是至少十七个进程、三类配置文件（core-site.xml、hdfs-site.xml、yarn-site.xml）、四层依赖关系（JDK→Hadoop→ZK→YARN→Spark/Hive）。所以这篇不教你怎么“背命令”，而是带你把每个start/stop动作拆解成一次状态诊断：namenode启动时你在看什么日志？datanode连不上namenode，第一眼该扫哪三行错误？yarn nodemanager反复退出，是内存配小了还是磁盘满了？spark-submit提交后卡住，到底是driver没起来，还是application master被yarn拒绝了？hive cli连不上metastore，问题在thrift server端口，还是mysql连接池耗尽？我会用真实生产环境的截图级操作逻辑，告诉你每条命令执行前该check什么、执行中该盯什么、执行后该验什么。适合刚搭完伪分布想上真集群的运维新人，也适合开发同学排查job失败时快速定位是平台层还是应用层的问题。所有命令都基于Hadoop 3.3.6 + Spark 3.4.2 + Hive 3.1.3的主流组合，适配CentOS 7/8和Ubuntu 20.04/22.04，Windows WSL2环境也单独标注注意事项。
2. 启停命令背后的架构逻辑与状态机设计
2.1 HDFS的双节点协同：namenode与datanode不是主从，而是状态协商
很多人误以为namenode是“老板”，datanode是“员工”，start-dfs.sh就是老板发号施令。错。HDFS启动本质是一次分布式状态协商。namenode启动后进入安全模式（Safe Mode），此时它不接受任何写请求，只做一件事：等待所有datanode完成block report（块报告）。每个datanode启动时会扫描本地磁盘上的block文件，生成一个包含所有block ID、大小、校验和的清单，通过RPC发给namenode。namenode收到足够多datanode的report（默认阈值是99.9%的block已汇报），才自动退出安全模式。这就是为什么你常看到“namenode处于安全模式”的告警——不是namenode挂了，而是datanode没报完。实操中我见过最典型的三个卡点：一是datanode的dfs.datanode.data.dir路径下有残留的in_use.lock文件（强制kill进程后未清理），导致datanode拒绝启动；二是namenode的dfs.namenode.handler.count参数太小（默认10），当datanode数量超50台时，handler线程池打满，block report排队超时；三是网络MTU不一致，大块report包被分片丢弃，namenode收不到完整数据。所以start-dfs.sh执行后，你必须立刻检查两个日志：/var/log/hadoop-hdfs/hadoop-hdfs-namenode-*.log里找“Exiting safe mode”，/var/log/hadoop-hdfs/hadoop-hdfs-datanode-*.log里找“Received block report”。前者没出现，看后者是否在持续重试；后者报“Connection refused”，立刻查namenode端口9870是否监听、防火墙是否放行。
2.2 YARN的两级调度：ResourceManager与NodeManager的生命周期绑定
yarn的启动比HDFS更复杂，因为它涉及资源隔离。start-yarn.sh启动的不是单个服务，而是一个资源调度闭环：ResourceManager（RM）作为中央调度器，负责分配Container；NodeManager（NM）作为每个节点的代理，负责启动/监控Container。关键点在于：NM启动时会向RM注册，注册成功后RM才将其纳入可用节点池；而RM自身又依赖于ZooKeeper（如果启用HA）或本地文件系统（非HA）来持久化Application状态。所以当你执行start-yarn.sh后，必须验证三个状态：一是jps | grep ResourceManager确认进程存在；二是curl -s http://rm-host:8088/ws/v1/cluster/nodes返回JSON里activeNodes数量是否等于你的NM节点数；三是任意一台NM节点上执行yarn node -list，看是否显示“RUNNING”。我踩过的最大坑是：NM的yarn.nodemanager.resource.memory-mb参数设为8192MB，但物理内存只有12GB，Linux OOM Killer直接干掉NM进程，日志里只有一行“Killed process”，根本找不到yarn相关错误。解决方案不是调大内存参数，而是用free -h确认可用内存，再按70%原则设置（即12GB * 0.7 ≈ 8GB），并开启yarn.nodemanager.vmem-check-enabled=false绕过虚拟内存检查——这是生产环境标配，不是偷懒。
2.3 Spark的三种部署模式：standalone、yarn、k8s，启停逻辑天差地别
Spark本身不提供集群管理，它依赖外部资源管理器。所以“spark启动命令”必须先明确模式：
- Standalone模式：Spark自带Master/Worker进程，start-all.sh启动Master（端口8080）和Worker（端口8081），但Worker必须能SSH免密登录到所有节点，否则启动失败。实测发现CentOS 7默认禁用root SSH，需改
/etc/ssh/sshd_config的PermitRootLogin yes并重启sshd。 - YARN模式：Spark不启动任何守护进程，spark-submit提交任务时，由YARN动态分配Container运行Driver和Executor。所谓“启动Spark”其实是确保YARN正常，然后用
spark-shell --master yarn测试连通性。重点检查yarn.resourcemanager.address配置是否指向正确RM地址，以及spark.yarn.jars是否指向HDFS上的spark-jars目录（hdfs dfs -ls /spark-jars）。 - Kubernetes模式：需要kubectl权限和spark-operator，启停命令变成
kubectl apply -f spark-master.yaml。但当前热词里没提k8s，本文聚焦前两种。
特别提醒：Spark 3.x默认启用AQE（Adaptive Query Execution），如果yarn.scheduler.maximum-allocation-mb小于spark.sql.adaptive.enabled=true要求的最小内存，job会卡在“Waiting for resources”，日志里看不到ERROR，只有一堆INFO。解决方案是关掉AQE或调大yarn内存上限。
2.4 Hive的元数据服务：metastore不是可选组件，而是单点故障核心
Hive的启动最容易被误解。“hive”命令只是CLI客户端，真正服务端是HiveServer2（HS2）和Metastore。HS2处理SQL解析和执行，Metastore管理表结构、分区、统计信息等元数据。两者可合并在一个JVM（--service hiveserver2），也可分离部署（推荐生产环境）。分离时，必须先启动metastore（nohup hive --service metastore > /var/log/hive/metastore.log 2>&1 &），再启动HS2（nohup hiveserver2 > /var/log/hive/hiveserver2.log 2>&1 &）。常见错误是metastore连不上MySQL：一是jdbc url写错（jdbc:mysql://mysql-host:3306/metastore?createDatabaseIfNotExist=true少了个问号）；二是MySQL用户没授权（GRANT ALL ON metastore.* TO 'hive'@'%' IDENTIFIED BY 'pwd'; FLUSH PRIVILEGES;）；三是MySQL max_connections不够（Hive默认连接池20，10个并发查询就打满）。我在线上曾因MySQL连接数爆满，HS2日志循环打印“Unable to open a test connection”，实际是metastore服务早挂了，但HS2还在傻等。所以检查Hive，永远先看metastore.log，再看hiveserver2.log。
3. 实操命令详解与参数精调指南
3.1 HDFS启停：从单节点调试到百节点集群的渐进式验证
3.1.1 单节点伪分布式环境（开发/测试必备）
# 1. 格式化namenode（仅首次执行！重复执行会清空所有数据） hdfs namenode -format # 2. 启动HDFS（等价于 start-dfs.sh） $HADOOP_HOME/sbin/hadoop-daemon.sh start namenode $HADOOP_HOME/sbin/hadoop-daemon.sh start datanode # 3. 验证（三步法） # a) 进程检查 jps | grep -E "NameNode|DataNode" # b) 端口检查（namenode默认9870，datanode默认9864） netstat -tuln | grep -E ":9870|:9864" # c) Web UI检查（浏览器打开） # http://localhost:9870 -> 查看Live Nodes数量 # http://localhost:9864 -> datanode的Web UI（需在datanode节点访问）提示：
hadoop-daemon.sh是底层脚本，start-dfs.sh是封装好的启动器。调试时建议用前者，因为start-dfs.sh会同时启动secondarynamenode（如果配置了），增加干扰项。
3.1.2 多节点集群启动（生产环境标准流程）
# 1. 确保所有节点时间同步（NTP是底线！） ntpdate pool.ntp.org # 或配置chronyd # 2. 在namenode节点执行（注意：不是所有节点都执行！） $HADOOP_HOME/sbin/start-dfs.sh # 3. 检查顺序（严格按此顺序，跳过一步可能误判） # Step 1: namenode日志 tail -100f $HADOOP_HOME/logs/hadoop-*-namenode-*.log | grep -E "STARTUP|Safe mode is OFF" # Step 2: 任一datanode日志（选负载最低的节点） tail -100f $HADOOP_HOME/logs/hadoop-*-datanode-*.log | grep -E "Registered|Block report" # Step 3: HDFS健康检查 hdfs dfsadmin -report | head -20 # 查看Live Nodes、Dead Nodes、Decommissioning Nodes # Step 4: 文件系统测试（创建目录+上传文件） hdfs dfs -mkdir -p /test/input echo "hello world" | hdfs dfs -put - /test/input/test.txt hdfs dfs -cat /test/input/test.txt注意：
start-dfs.sh会读取$HADOOP_HOME/etc/hadoop/slaves文件，里面每行一个datanode主机名。务必确保该文件内容与实际节点一致，且所有节点的/etc/hosts里能解析这些主机名。我遇到过slaves文件写错IP，脚本尝试SSH到不存在的IP，超时60秒后才报错，浪费大量时间。
3.1.3 安全模式强制退出（应急场景）
当namenode卡在安全模式，且确认datanode已全部上线，可手动退出：
# 方法1：等待自动退出（推荐，观察日志） # 方法2：强制退出（仅限紧急情况） hdfs dfsadmin -safemode leave # 方法3：调整安全模式阈值（永久方案） # 编辑 hdfs-site.xml，添加： <property> <name>dfs.namenode.safemode.threshold-pct</name> <value>0.95</value> <!-- 默认0.999，改为0.95表示95% block汇报即退出 --> </property> # 执行刷新：hdfs dfsadmin -refreshNodes警告：
-safemode leave是危险操作！如果datanode确实没报完block，强行退出会导致部分block丢失，后续MR job报“No live nodes contain block”。
3.2 YARN启停：资源调度器的精细化控制
3.2.1 ResourceManager单点启动（非HA模式）
# 1. 启动ResourceManager（仅在RM节点执行） $HADOOP_HOME/sbin/yarn-daemon.sh start resourcemanager # 2. 启动NodeManager（在每个worker节点执行） $HADOOP_HOME/sbin/yarn-daemon.sh start nodemanager # 3. 验证（四维检查） # a) 进程：jps | grep -E "ResourceManager|NodeManager" # b) RM端口：netstat -tuln | grep :8088 # c) NM端口：netstat -tuln | grep :8042 # d) Web UI：http://rm-host:8088/cluster -> 查看Active Nodes数量3.2.2 YARN HA模式启动（双RM高可用）
# 1. 启动ZooKeeper集群（前提条件） zkServer.sh start # 2. 在第一个RM节点启动（自动成为Active） $HADOOP_HOME/sbin/yarn-daemon.sh start resourcemanager # 3. 在第二个RM节点启动（自动成为Standby） $HADOOP_HOME/sbin/yarn-daemon.sh start resourcemanager # 4. 验证HA状态 yarn rmadmin -getServiceState rm1 # 返回 active yarn rmadmin -getServiceState rm2 # 返回 standby # 5. 模拟故障切换（测试用） yarn rmadmin -transitionToStandby rm1 # 将rm1切为standby yarn rmadmin -transitionToActive rm2 # 将rm2切为active实操心得：YARN HA依赖ZooKeeper，所以
yarn.resourcemanager.zk-address必须配置正确。我曾因ZK地址写成localhost:2181（实际ZK在另一台机器），两个RM都卡在“Connecting to ZooKeeper”，日志里疯狂重试。正确写法是zk-host1:2181,zk-host2:2181,zk-host3:2181。
3.2.3 NodeManager内存调优（避免OOM Killer）
# 关键参数（编辑 yarn-site.xml） <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>8192</value> <!-- NM可分配的最大内存，单位MB --> </property> <property> <name>yarn.nodemanager.resource.cpu-vcores</name> <value>8</value> <!-- NM可分配的最大vcore数 --> </property> <property> <name>yarn.nodemanager.vmem-check-enabled</name> <value>false</value> <!-- 关闭虚拟内存检查，防OOM Killer --> </property> <property> <name>yarn.nodemanager.pmem-check-enabled</name> <value>false</value> <!-- 关闭物理内存检查 --> </property> # 生产环境建议：内存按物理内存70%计算，vcore按CPU核数*0.8计算 # 例如：32核64GB服务器 -> memory-mb=45056(64*0.7*1024), vcores=25(32*0.8)3.3 Spark启停：从本地模式到YARN集群的无缝切换
3.3.1 Spark Standalone模式（小规模集群）
# 1. 启动Master（在master节点） $SPARK_HOME/sbin/start-master.sh # 2. 启动Worker（在每个worker节点，需SSH免密） $SPARK_HOME/sbin/start-slave.sh spark://master-host:7077 # 3. 验证 # Master Web UI: http://master-host:8080 -> 查看Workers数量 # Worker日志: $SPARK_HOME/logs/spark-*-org.apache.spark.deploy.worker.Worker-*.out # 4. 提交测试job $SPARK_HOME/bin/spark-submit \ --master spark://master-host:7077 \ --class org.apache.spark.examples.SparkPi \ $SPARK_HOME/examples/jars/spark-examples_2.12-3.4.2.jar \ 10注意：
start-slave.sh的URL必须是spark://协议，不能是http://。如果Worker启动后Web UI不显示，检查spark-env.sh里的SPARK_MASTER_HOST是否设为master节点IP，而非localhost。
3.3.2 Spark on YARN模式（生产主力）
# 1. 确保YARN已启动（见3.2节） # 2. 配置Spark连接YARN（编辑 spark-defaults.conf） spark.master yarn spark.submit.deployMode client # 或 cluster spark.yarn.jars hdfs://namenode:9000/spark-jars/* # HDFS上的jar包路径 # 3. 上传Spark jars到HDFS（一次执行） hdfs dfs -mkdir -p /spark-jars hdfs dfs -put $SPARK_HOME/jars/*.jar /spark-jars/ # 4. 提交job（client模式：driver在提交节点运行） spark-submit \ --master yarn \ --deploy-mode client \ --class org.apache.spark.examples.SparkPi \ --executor-memory 2g \ --executor-cores 2 \ $SPARK_HOME/examples/jars/spark-examples_2.12-3.4.2.jar \ 10 # 5. 查看YARN Application（job是否提交成功） yarn application -list | grep SPARK # 返回类似：application_1699999999999_0001 SPARK RUNNING 2023-10-01 10:00:00 user实操技巧：client模式便于调试（driver日志在终端输出），cluster模式适合生产（driver在YARN Container内运行，提交节点断开不影响job）。但cluster模式下，driver日志需用
yarn logs -applicationId application_xxx查看，比client模式多一步。
3.4 Hive启停：元数据服务的稳定性保障
3.4.1 Metastore独立部署（生产推荐）
# 1. 启动Metastore（后台运行，日志重定向） nohup hive --service metastore > /var/log/hive/metastore.log 2>&1 & # 2. 验证Metastore（检查端口和日志） netstat -tuln | grep :9083 # 默认thrift端口 tail -50f /var/log/hive/metastore.log | grep "Starting DBStore" # 3. 启动HiveServer2（HS2） nohup hiveserver2 > /var/log/hive/hiveserver2.log 2>&1 & # 4. 验证HS2 netstat -tuln | grep :10000 # 默认thrift端口 tail -50f /var/log/hive/hiveserver2.log | grep "HiveServer2 started" # 5. 测试连接（用beeline CLI） beeline -u jdbc:hive2://hs2-host:10000 -n hiveuser -p hivepass # 进入后执行：show databases;注意：
hive --service metastore和hiveserver2命令本质是Java进程，所以nohup后必须加&，否则会前台阻塞。如果忘记加&，Ctrl+C中断后进程其实还在，要用ps aux | grep metastore杀掉。
3.4.2 Hive配置关键参数（避坑清单）
<!-- hive-site.xml 必配项 --> <property> <name>javax.jdo.option.ConnectionURL</name> <value>jdbc:mysql://mysql-host:3306/metastore?createDatabaseIfNotExist=true&useSSL=false&serverTimezone=UTC</value> </property> <property> <name>javax.jdo.option.ConnectionDriverName</name> <value>com.mysql.cj.jdbc.Driver</value> </property> <property> <name>javax.jdo.option.ConnectionUserName</name> <value>hive</value> </property> <property> <name>javax.jdo.option.ConnectionPassword</name> <value>hivepassword</value> </property> <property> <name>hive.server2.thrift.port</name> <value>10000</value> </property> <property> <name>hive.metastore.uris</name> <value>thrift://metastore-host:9083</value> <!-- HS2连接metastore的地址 --> </property>常见错误：
useSSL=false和serverTimezone=UTC必须加上，否则MySQL 8.0+连接失败；&在XML中要写成&，否则配置解析失败；hive.metastore.uris必须指向metastore服务地址，不能写localhost（HS2和metastore通常不在同一台机器）。
4. 故障排查实战：从日志碎片到根因定位
4.1 HDFS典型故障速查表
| 现象 | 日志关键词 | 根因分析 | 解决方案 |
|---|---|---|---|
namenode处于安全模式 | Safe mode is ON | datanode未完成block report | 检查datanode日志是否有Block report，确认网络连通性 |
datanode无法注册到namenode | Call From dn-host to nn-host:9820 failed | namenode未监听9820端口，或防火墙拦截 | netstat -tuln | grep :9820，iptables -L -n |
hdfs dfs -ls 报错 Connection refused | java.net.ConnectException: Connection refused | namenode进程未启动，或core-site.xml的fs.defaultFS配置错误 | jps | grep NameNode，检查fs.defaultFS=hdfs://namenode-host:9000 |
DataNode: java.io.IOException: Incompatible clusterIDs | Incompatible clusterIDs | datanode的VERSION文件clusterID与namenode不匹配 | 删除datanode的data目录，重新格式化namenode |
实操心得：HDFS日志里最有效的线索不是ERROR，而是INFO级别的状态流转。比如namenode日志里连续出现
BLOCK* NameSystem#addBlock: block ... added，说明block写入正常；如果突然停止，大概率是datanode挂了。我习惯用grep -A 5 -B 5 "Exception\|FATAL" hadoop-hdfs-namenode-*.log抓上下文，比单纯搜ERROR更准。
4.2 YARN资源调度故障定位
| 现象 | 日志关键词 | 根因分析 | 解决方案 |
|---|---|---|---|
yarn application -list 返回空 | No applications found | ResourceManager未启动，或yarn.resourcemanager.address配置错误 | jps | grep ResourceManager，检查yarn.resourcemanager.address=rm-host:8032 |
NodeManager反复退出 | Killed process | Linux OOM Killer干掉NM进程 | 调小yarn.nodemanager.resource.memory-mb，或关闭内存检查 |
spark-submit卡住，无日志输出 | Client: Waiting for application | YARN资源不足，或spark.yarn.jars路径错误 | yarn node -list看节点状态，hdfs dfs -ls /spark-jars确认jar存在 |
ApplicationMaster启动失败 | AM Container exited with exitCode: -1000 | Container内存超限，或本地磁盘空间不足 | yarn logs -applicationId app_xxx看AM日志，检查yarn.nodemanager.local-dirs磁盘使用率 |
排查技巧：YARN的Application日志分散在多个地方。Driver日志在提交节点（client模式）或AM Container（cluster模式）；Executor日志在对应NodeManager节点的
$YARN_HOME/logs/userlogs目录。最快方法是yarn logs -applicationId application_xxx > app.log，然后grep -E "ERROR\|Exception" app.log。
4.3 Spark on YARN作业失败诊断链
Spark job失败不是单一环节问题，而是YARN调度→Container启动→Executor初始化→Task执行的链条断裂。我的标准排查链：
- YARN层：
yarn application -status application_xxx→ 看FinalStatus是SUCCEEDED还是FAILED - AM层：
yarn logs -applicationId application_xxx \| grep "ApplicationMaster"→ 看AM是否启动成功 - Executor层：
yarn logs -applicationId application_xxx \| grep "Executor"→ 看Executor是否注册 - Task层：
yarn logs -applicationId application_xxx \| grep "TaskSetManager"→ 看Task是否调度
常见断点：
- AM启动失败：通常是
spark.yarn.jars路径不存在，或HDFS权限问题（hdfs dfs -ls /spark-jars返回Permission denied） - Executor注册失败：
spark.executor.memory设得太大，YARN分配Container时超限，日志报Requested container exceeds memory limits - Task失败：
spark.sql.files.maxPartitionBytes设得太小，产生海量小task，拖垮调度器
4.4 Hive元数据服务崩溃复原
Hive故障90%出在Metastore。当beeline连不上，按此顺序检查：
- 网络层：
telnet metastore-host 9083→ 端口不通？检查metastore进程、防火墙、SELinux - Metastore层：
tail -100f /var/log/hive/metastore.log→ 找Exception或Connection refused - MySQL层：
mysql -uhive -phivepass -h mysql-host -e "use metastore; show tables;"→ 连接失败？检查MySQL服务、用户权限、max_connections - HS2层：
tail -100f /var/log/hive/hiveserver2.log→ 如果metastore正常但HS2报错，可能是hive.metastore.uris配置错误
紧急恢复：如果MySQL损坏，Hive元数据不可逆丢失。唯一办法是从备份恢复MySQL库。所以生产环境必须每天
mysqldump -u hive -p hivepass metastore > /backup/metastore_$(date +%F).sql，并验证备份可还原。
5. 高级运维技巧：自动化启停与健康巡检
5.1 一键启停脚本（适配多节点集群）
#!/bin/bash # cluster-control.sh # Usage: ./cluster-control.sh {start|stop} {hdfs|yarn|spark|hive} SERVICE=$2 ACTION=$1 case $SERVICE in hdfs) if [ "$ACTION" = "start" ]; then echo "Starting HDFS..." $HADOOP_HOME/sbin/start-dfs.sh sleep 10 hdfs dfsadmin -report | head -10 else echo "Stopping HDFS..." $HADOOP_HOME/sbin/stop-dfs.sh fi ;; yarn) if [ "$ACTION" = "start" ]; then echo "Starting YARN..." $HADOOP_HOME/sbin/start-yarn.sh sleep 10 yarn node -list else echo "Stopping YARN..." $HADOOP_HOME/sbin/stop-yarn.sh fi ;; hive) if [ "$ACTION" = "start" ]; then echo "Starting Hive Metastore..." nohup hive --service metastore > /var/log/hive/metastore.log 2>&1 & sleep 5 echo "Starting HiveServer2..." nohup hiveserver2 > /var/log/hive/hiveserver2.log 2>&1 & else echo "Stopping Hive..." ps aux | grep "metastore" | grep -v grep | awk '{print $2}' | xargs kill -9 ps aux | grep "hiveserver2" | grep -v grep | awk '{print $2}' | xargs kill -9 fi ;; esac使用方式：
./cluster-control.sh start hdfs启动HDFS，./cluster-control.sh stop hive停止Hive。脚本加入sleep和状态检查，避免启停不同步。
5.2 集群健康巡检脚本（每日自动执行）
#!/bin/bash # health-check.sh # 检查HDFS/YARN/Spark/Hive核心指标 echo "=== HDFS Health Check ===" hdfs dfsadmin -report | grep -E "Live Nodes|Dead Nodes|Decommissioning Nodes" hdfs fsck / -files -blocks -locations 2>/dev/null | head -10 echo "=== YARN Health Check ===" yarn node -list | grep -E "Total Nodes|RUNNING" yarn application -list -appStates RUNNING | wc -l echo "=== Spark on YARN Check ===" if yarn application -list 2>/dev/null | grep -q "SPARK"; then echo "Spark jobs running" else echo "No Spark jobs running" fi echo "=== Hive Metastore Check ===" nc -z metastore-host 9083 && echo "Metastore OK" || echo "Metastore DOWN" echo "=== HiveServer2 Check ===" nc -z hs2-host 10000 && echo "HS2 OK" || echo "HS2 DOWN"部署：
crontab -e添加0 2 * * * /path/to/health-check.sh >> /var/log/cluster-health.log 2>&1，每天凌晨2点执行。
5.3 生产环境启停黄金法则
- 启停顺序不可逆：启动按HDFS→YARN→Hive→Spark；停止按Spark→Hive→YARN→HDFS。原因：Spark依赖YARN，YARN依赖HDFS，Hive依赖HDFS和MySQL。反序启停会导致服务等待超时。
- 滚动重启策略：百节点集群不要
stop-all.sh，而是逐台重启NodeManager：先yarn-daemon.sh stop nodemanager，等该节点所有Container结束，再start。避免瞬间资源缺口。 - 配置版本管理：所有
core-site.xml等配置文件用Git管理，每次修改提交commit，并在注释里写明变更原因（如“2023-10-01 调整dfs.blocksize为256MB，适配大文件场景”）。 - 日志保留策略：Hadoop日志默认只存最近10个，生产环境改
$HADOOP_HOME/etc/hadoop/log4j.properties：hadoop.root.logger=INFO,RFA，log4j.appender.RFA.MaxBackupIndex=30，保留30天日志。
我在某金融客户现场，曾因未遵守启停顺序，先停了HDFS再停YARN，导致YARN的Application状态丢失，所有正在运行的Spark job被强制kill，业务方投诉。后来我们把启停流程固化成Ansible Playbook，每次执行前自动校验依赖状态，再也没出过问题。技术细节决定成败，而流程规范保障稳定。
