聊 Hadoop 故障排除这个话题我心里其实挺感慨的。入行大数据这么多年从最早搭伪分布式开始到后来管理几十台、上百台节点的集群几乎每天都在跟各种莫名其妙的“坑”打交道。很多人觉得 Hadoop 难学、难维护其实归根结底就一句话你不会看日志就不会排障。所谓“故障排查”从来不是靠猜而是一套有章法、有顺序、能落地的思路。这篇东西没什么高深理论就是想把我这些年踩过的坑、用过的排查命令、总结出来的套路一次性倒给你。不管你是刚学 Hadoop 的初学者还是在生产环境里被集群故障折磨得焦头烂额的运维这篇文章都值得你花二十分钟认真看看。我会从最底层的问题诊断逻辑讲起然后按 HDFS、YARN/MapReduce、高可用和生态组件几个维度把那些“高频疑难杂症”一个一个掰开揉碎了说清楚。你看完之后至少再遇到同类问题不会再手足无措。1. 故障排查的底层逻辑一切从日志和监控开始很多新手遇到集群出问题第一反应是去网上搜报错信息搜了半天发现每个人都有不同说法越搞越乱甚至会把一个好好的集群越改越坏。我自己的经验是——别急着动手先建立“定位链”。1.1 日志永远是第一现场Hadoop 的日志分散在不同组件、不同节点上但规律非常清晰。NameNode 日志在$HADOOP_HOME/logs/hadoop-hdfs-namenode-hostname.logDataNode 日志是hadoop-hdfs-datanode-hostname.logResourceManager 对应的则是yarn-resourcemanager-hostname.logNodeManager 的日志也类似。MapReduce 作业跑完以后真正的执行日志在 YARN 的聚合日志里路径通常在http://rm-address:19888/jobhistory/logs也可以直接用命令行拉取。实操心得排查故障别只看最后几十行日志。很多异常是周期性出现的比如频繁 GC、连接超时、磁盘写满这些前置信号往往在真正 Outage 之前就已经在日志里出现过好几轮了。所以我会习惯用grep结合时间戳过滤比如排查某个时间段内的 ERRORgrep 2025-03-11 14:00 hadoop-hdfs-namenode-*.log | grep -i error | tail -n 100这么做的好处是能快速还原故障发生前几分钟内集群到底经历了什么。1.2 监控数据比报错信息更早暴露问题说个非常常见的场景集群节点没有宕机进程也都在但整个 HDFS 读写就是异常卡顿。这时候盯着日志可能什么都看不出来因为系统压根没抛异常只是性能在劣化。必须依赖监控指标去定位。HDFS 侧重点看 NameNode 的 JVM 堆内存使用率、Full GC 次数、RPC 处理延迟、DataNode 的磁盘 IO 使用率YARN 侧重点看集群可用资源yarn.scheduler.maximum-allocation-mb等配置、队列待执行任务数、Container 启动失败率。这些指标在 Ambari、Cloudera Manager 里一目了然就算你用的是裸装开源版也要想办法用 Prometheus 把jmx端口拉起来。核心心得日志告诉你“发生了什么”监控告诉你“正在发生什么”。两者结合才是一个完整的排障闭环。我见过太多人只看监控曲线发现某个指标飙升却不知道对应时间点日志里报了什么错误最后也是白折腾。1.3 从“三层模型”快速缩小故障范围我自己习惯把 Hadoop 故障排查分成三层这样能非常快地确定“病因”在哪一层层级代表组件常见病症排查入口硬件/OS 层CPU、内存、磁盘、网络磁盘只读、网卡丢包、内存溢出导致进程被杀dmesg、df -h、iostat、vmstatHadoop 组件层HDFS、YARN、ZooKeeperNameNode 安全模式、NodeManager 失联、ZK 会话超时组件日志、Web UI、hdfs dfsadmin -report作业/数据层MapReduce、Hive、Spark数据倾斜、OOM、小文件过多、任务重试失败YARN 日志、任务 Counter、yarn logs遇到问题先问自己一句这个故障影响的是“整个集群”还是“某个组件”还是“某个作业”如果整个集群都挂了大概率是底层硬件或者 NameNode/ResourceManager 出事了要是只有某个作业失败那问题多半出在数据或代码层面。这三层思路理顺了排查路径基本不会跑偏。2. HDFS 高频故障从安全模式到数据均衡HDFS 是整个 Hadoop 的存储地基这块出问题的概率最高、影响也最致命。我碰到的 HDFS 故障场景里以下几个占了八成以上。2.1 NameNode 安全模式先分清“合法进入”和“异常退出”多数新手一看到日志里出现Safe mode is ON就慌了以为集群挂了。其实 NameNode 启动时默认会进入安全模式目的是让 DataNode 先上报块信息、NameNode 加载完元数据。这个阶段同步检查阈值配置dfs.namenode.safemode.threshold-pct默认是 0.999意思是必须收到 99.9% 的块汇报之后才会自动退出安全模式。真正的问题是集群刚启动时 DataNode 还没全部注册回来如果阈值配得太高安全模式一直退不出去这时候 HDFS 只能读不能写。我遇到过一个实际案例集群断电重启后有大约 5% 的 DataNode 因为磁盘文件系统异常卡在启动过程中导致块上报数量不足NameNode 一直卡在安全模式。处理步骤先看当前汇报状态hdfs dfsadmin -safemode get。再看节点存活情况hdfs dfsadmin -report对比 live 节点数和总节点数。快速定位是哪些节点没起来去对应 DataNode 日志里查底层原因。如果是测试环境、确认副本数足够可临时手动退出hdfs dfsadmin -safemode leave。但在生产环境永远不要用这个命令硬退安全模式因为很可能导致元数据不完整后续数据丢失风险极高。补充经验什么情况下安全模式是“异常”的最常见的就是磁盘空间不足导致 DataNode 无法正常写数据、节点频繁失联。你df -h一看/data分区 100% 满了那安全模式只是个结果不是病因清空间才是正道。2.2 DataNode 进程反复挂掉磁盘和副本管理的双重考验DataNode 经常会出现这样一种情况进程启动了过一会儿又自动退出了日志里还打着一堆java.io.IOException: 设备上没有剩余空间或Disk Out of Space。很多人的第一反应是加磁盘但真正的坑往往在于 DataNode 的dfs.datanode.data.dir配置了多块盘其中一块挂掉之后DataNode 会默认把整块磁盘标记为failed volume。如果你用的 Hadoop 版本较老默认配置dfs.datanode.failed.volumes.tolerated是 0也就是一块盘坏了整个 DataNode 就自杀式退出这是非常有迷惑性的行为——明明有 11 块盘是好的就因为这 1 块盘 IO 异常整个节点就不服务了。排查路径先看 DataNode 日志里是不是有 volume 相关的异常用df -h和dmesg | grep -i error确认底层盘是否真实故障在hdfs-site.xml中将dfs.datanode.failed.volumes.tolerated调大比如 1 或 2但这种只适合盘多、有副本兜底的场景。核心是坏了盘要及时更换而不是靠容忍配置硬扛。另一个高频坑DataNode 启动失败报Incompatible clusterIDs或者Storage directory ... is not formatted。这个多半是节点重新初始化了或者复制了 namenode 元数据但没有清空旧的 datanode 存储目录导致的。解决办法也比较简单把对应目录下的current/VERSION文件里的 clusterID 改成和 NameNode 一致或者直接删掉current目录让 DataNode 重新注册、重新格式化存储。注意如果是生产环境不建议随意删除数据目录内容极端情况下会触发全量块重汇报集群要疯一会儿。2.3 块缺失与副本不足别把所有锅都甩给 NameNodeHadoop 有一个非常经典的“薛定谔的报错”某个作业读文件失败日志里显示File could not be found或者Block ... does not exist但你去hdfs dfs -ls一看文件明明还在。这种情况通常是 block 文件出现了内部缺失或者文件正处于写入过程中客户端还在写commit 还没完成。先用hdfs fsck /path/to/file -files -blocks -locations查一下具体块状态。如果输出里出现MISSING那说明确实有块数据丢失了。块丢失的原因千奇百怪最常见的是这几种DataNode 节点宕机且副本数设置成 1磁盘静默损坏但文件系统没有报错或者开启磁盘配额后写入被静默丢弃。想要恢复唯一可靠的手段是从副本或者备份中恢复。如果你开了dfs.replication为 3fsck 就能看到其他正常的 replica 会自动补齐副本数。如果副本数本身就是 1那就只能认命——这也就是为什么我一直建议生产环境至少dfs.replication3有些重要数据会单独设更高副本数。实操建议定期跑一下hdfs fsck / -files -blocks把结果重定向到日志文件里设置告警去追踪缺失块数量。你在凌晨三点被叫起来处理数据丢失和白天就发现缺失块提前修复是完全不同的体验。2.4 数据不均衡HDFS 的“冷热不均”问题节点磁盘使用率差异太大是一个容易被忽视但非常影响整体集群寿命的问题。有的节点磁盘用了 80%有的才 30%数据写入时会优先往空闲节点上写但离线数据、压缩包、删除后再写入的数据分布往往不会自动趋于均衡。Hadoop 自带了均衡工具但很多人的姿势是错的。直接执行hdfs balancer跑个大半天磁盘使用率还是那么难看。原因在于默认带宽dfs.datanode.balance.bandwidthPerSec太小了很多发行版默认只有 10MB/s 或者 20MB/s挪几个 TB 数据要跑一个礼拜。正确打开方式# 临时调高带宽比如 200MB/s hdfs dfsadmin -setBalancerBandwidth 209715200 # 按实际负载执行均衡只调整使用率差异超过 10% 的节点 hdfs balancer -threshold 10我自己的习惯是把这个操作放在凌晨低峰期执行同时配合-policy参数做机架感知范围内的内部均衡。千万别在白天业务高峰期跑全量均衡那会让集群 IO 直接打满新的作业全部排队。2.5 小文件问题HDFS 上最被人低估的“慢性病”这个东西排查起来不如安全模式那么惊心动魄但危害极大。大量小文件意味着每个文件都要占用 NameNode 内存里的一条元数据记录大概 150 字节的 heap 开销同时 MapReduce 或 Spark 在处理它们时会产生海量的小任务调度开销大到无法想象。我自己接过一个集群NameNode 堆内存 32G 都经常用到 90% 以上GC 频繁导致 RPC 超时。后来一统计整个集群文件数超过 2 亿平均文件大小只有 200KB 左右。这是妥妥的小文件灾难。排查命令很简单hdfs fsck / -files -blocks | grep Total blocks hdfs fsck / -files | awk {print $1} | awk -F/ {print NF} | sort | uniq -c | sort -rn但根治之道只有一个控制上游写入。Hive 表要设置合理的partitions粒度Spark 写 HDFS 时要考虑coalesce()合并分区日志采集要用 Flume/FileChannel 做攒批。对已经存在的小文件用hadoop archiveHAR 文件或者跑一个单纯的 MapReduce/Spark 作业重写数据、合并输出文件。这两招用好了NameNode 的内存压力立竿见影地下降。3. YARN 与计算作业任务失败、资源异常和数据倾斜HDFS 平稳运行只代表“存储层健壮”真正让集群发挥价值的是跑在上面的计算任务。YARN 负责资源调度这里的问题往往更加直观但也更容易被表面现象迷惑。3.1 作业一直处于 ACCEPTED 状态调度器配置的玄机提交一个 MapReduce 作业后过了五分钟还在 ACCEPTED不少用户的第一反应是“集群是不是卡了”。这个问题大概率是排队等资源导致的。去看看 YARN 的资源调度情况yarn application -list yarn node -list -all如果yarn node -list -all显示节点状态是 RUNNING但资源使用率已经很高那就是没资源了。这时候要回到调度器配置上看Capacity Scheduler 下队列资源比例是怎么配的是不是某个用户的作业把队列资源占满了Fair Scheduler 的话是否配了preemption抢占排障提醒最容易被忽视的是 AMApplication Master资源不足。YARN 会优先启动 AM 容器但如果yarn.scheduler.minimum-allocation-mb设得太大或者集群总内存太小AM 本身就可能起不来。你会看到一个作业反复“尝试提交、失败、重试”日志里全是ApplicationMaster启动超时。3.2 MapReduce 作业卡在 MAP 阶段永远 99%数据倾斜的现场这是大数据领域最“出圈”的问题——数据倾斜。现象非常典型MapReduce 进度条 99%reduce 阶段只剩一个任务在跑其他 reduce 都完成了就它卡了一个小时。网上讲倾斜原理的很多什么 join 键分布不均、热点 key 集中、group by 字段倾斜之类。但落到实操层面我更愿意分享排查的“三部曲”看 Counter从 JobHistory 页面或者mapred job -counter里看每个 reduce 处理的数据量。如果第 5 个 reduce 处理了 100GB其他 reduce 处理了 1GB泄漏点已经锁定了。看日志yarn logs -applicationId appId把 reduce 日志拉下来重点看那些卡住任务的 log 里在做什么。有可能卡的根本不是计算而是某个 reduce 在做超大 shuffle 拉取。看输入路径查一下源表是否有明显的热点 key比如某个商品 ID 的订单占了 80%。给几个立竿见影的优化手段对 group by 类倾斜加一个随机前缀打散两阶段聚合对 join 类倾斜把热点 key 拆分出来走 map 端 join 或者广播对 reduce 数不合理的情况手动调整mapreduce.job.reduces。这些都是老掉牙的方案但架不住好用。测试下来大部分倾斜作业在做了随机打散之后能从原来跑四十分钟优化到五六分钟。3.3 Container 反复被杀内存超卖还是配置失误YARN 日志里经常出现这样一行Container [pidpid] is running beyond physical memory limits. Current usage: 8GB of 8GB physical memory used; 9GB of 10GB virtual memory used. Killing container.这个问题太经典了属于配置和真实负载不匹配。默认情况下YARN 会按物理内存和虚拟内存两个维度去监控容器。如果你的作业实际需要 10G 内存但容器规格只申请了 8GNodeManager 会直接 kill 掉这个容器。问题往往出在两个地方一是 JVM 堆大小设置和容器内存不匹配。比如mapreduce.map.memory.mb设置了 4096但mapreduce.map.java.opts里的-Xmx也设了 4096会导致容器内除了 JVM 堆还有 Native 内存、Metaspace 等分分钟超限。通常-Xmx要留出 15%~20% 的余量即容器 4G 时-Xmx设 3.2G 左右比较稳。二是 Python/Golang 等非 Java 任务会实际占满/proc里报告的内存完全没法按 JVM 参数控制只能老老实实提高mapreduce.reduce.memory.mb或者适当增加虚拟内存比例yarn.nodemanager.vmem-pmem-ratio。我的建议在定位是哪个作业被杀之后先打开yarn logs看堆栈里的内存占用看清楚到底是“Java heap 不够”还是“Native 内存超了”再针对性调参。不要看到 Container 被杀就盲目加内存那很容易把整个集群的资源池打爆。3.4 Shuffle 阶段极其缓慢IO 和压缩的博弈很多作业瓶颈不在计算而在 MapReduce 的 Shuffle 过程。Reduce 要拉取所有 Map 输出网络传输量一上来集群内网带宽就会成为瓶颈。之前有个集群跑一个 T1 报表作业单次 shuffle 的数据量差不多 5TB每次都在 shuffle 上耗掉两个多小时。后来做了一次调整把mapreduce.map.output.compress打开mapreduce.map.output.compress.codec设为org.apache.hadoop.io.compress.SnappyCodec再调整了mapreduce.reduce.shuffle.parallelcopies从默认 5 调到 10 到 15 之间。效果非常明显shuffle 时长大幅缩短。代价是压缩会消耗一点 CPU但这个成本对大多数计算密集型企业来说完全可接受。再补充一个容易被忽略的点如果集群启用了机架感知topology.script.file.name或网络拓扑脚本尽量让计算任务跑在数据本地Data Locality。Reduce 拉取数据时跨机架传输会显著增加延迟。这个可以通过hdfs dfsadmin -printTopology检查机架配置是否生效。3.5 OOM 不是只有 Java Heap 才叫 OOM很多做数据开发的同学一看到“OutOfMemoryError”就以为是堆不够。但我处理过好几次玄学级别的 OOM最后定位到根因千奇百怪Direct buffer memory不够导致 Netty 在 shuffle 时直接崩Metaspace 泄漏加载了过多动态生成的类还有一次是磁盘临时目录满了Map 输出写不进去报错却是 OOM。这里有个排查习惯特别关键yarn logs里不仅要看最后的异常栈还要看异常出现前几行的输出。有一次我盯着一句java.lang.OutOfMemoryError: GC overhead limit exceeded想破头最后往前翻了三百行日志才发现是某个 UDF 写了个死循环不断创建对象把堆给塞爆了。代码层面的问题换再大的机器也扛不住。4. HA 高可用与生态工具那些最容易“打架”的配置单节点 Hadoop 集群已经越来越少见生产环境基本都是 HA 架构。HA 模式下的故障复杂度比单机高了一个档次因为你不仅要和“机器故障”做斗争还得和“分布式一致性”做斗争。4.1 NameNode HA 脑裂与 fencing 机制HA 架构下Active NameNode 和 Standby NameNode 之间靠 JournalNode 来同步 EditLog。正常情况下Active 节点挂了之后Standby 通过 ZooKeeper 感知到并切换。但如果网络抖动、ZK 会话超时可能出现两个节点同时以为自己是 Active 的情况这就是“脑裂”。面对脑裂HDFS 里负责兜底的是 fencing 机制。比如dfs.ha.fencing.methods配了sshfence切换脚本会尝试 SSH 到旧 Active 节点上执行fuser把进程 kill 掉或者调用shell命令让其退位。如果你的 fencing 配置不当甚至没配脑裂后两个 NameNode 同时写元数据你的 HDFS 就真的“裂开”了。实操排查遇到 NameNode 自动切换失败第一步去看 ZK 上 Active 锁的持有者是谁zkCli.sh -server zk_host:2181 ls /hadoop-ha/mycluster get /hadoop-ha/mycluster/ActiveBreadCrumb再去对比两个 NameNode 日志中的ha.HAState状态变化确认到底是谁抢到了 Active、谁还在 Standby。很多时候问题反而是“切换成功了但 ZK 客户端会话没断干净导致新 Active 一直在报Already active错误”这时候重启一次老的 NameNode 进程或者清理 ZK 里残留的 session 就能解决。特别提醒JournalNode 在 HA 里是最容易被忽视的“单点”。很多人以为 HA 就万事大吉了但 JournalNode 是奇数个部署的通常是 3 个或 5 个如果超过半数宕机NameNode 就无法写入 EditLog两个节点都会退化为 Standby 状态。你的集群“看起来”没有任何进程挂掉但整个 HDFS 已经不可写了。这种故障是最坑的看起来哪儿都没坏就是业务全停了。4.2 ZooKeeper 会话超时一个诱发大量故障的“隐形元凶”ZooKeeper 在 Hadoop 生态里承担了太多核心职责NameNode 选主、ResourceManager 选主、HBase Region 分配、Kafka 元数据管理……如果 ZK 本身不稳定下游所有组件都会连环出问题。ZK 相关故障的排查第一件事是看zookeeper.out或者zookeeper.log。最常见的问题是“会话超时”即客户端比如 NameNode 或 ResourceManager和 ZK 之间心跳中断导致临时节点消失、触发重新选举。造成超时的原因大多数不是 ZK 自身挂了而是GC 暂停。客户端 JVM 在做 Full GC 时无法及时发送心跳ZK 服务器这边看到会话长时间没有活跃就判定超时了。所以当你的 NameNode 日志里频繁出现ZK session 0x... has expired时要先去看 NameNode 的 GC 日志而不是急着调 ZK 的tickTime。给个配置建议ZooKeeper 参数tickTime默认 2000msinitLimit和syncLimit默认 10 和 5这种配置在小型集群跑没问题。但节点一多、GC 一长建议把syncLimit稍微调大到 10 左右同时在 ZK 启动脚本里把 JVM 的-Xmx调大并启用-XX:UseConcMarkSweepGC或升级到 ZK 3.5 使用 G1GC。别小看 ZK 的 JVM 参数很多莫名其妙的“集群抖动”根源都在这里。4.3 Hive/Spark 整合中的“失败三连”把 Hadoop 和 Hive、Spark 整合到一起之后故障面又被放大了一圈。最常见的三板斧第一元数据连接问题。Hive 的 Metastore 如果连的是 MySQL而 MySQL 的wait_timeout时间过短空闲连接会被数据库服务端断开。HiveServer2 那边的连接池没有感知继续沿用旧连接时就会出现Communications link failure。这种问题非常“随缘”白天用着好好的第二天早上来一跑就报错。解决办法是把 MySQL 的wait_timeout调大或者配置 Hive 连接池定期检测、剔除死连接比如 DBCP 里设置testWhileIdletrue。第二Hive on Spark 的资源协商问题。hive.execution.enginespark和 YARN 集成时Spark 执行器会动态申请资源。很多人跑 MR 没问题一切到 Spark 引擎就不断报ExecutorLostFailure。原因大概率是 executor 的spark.executor.memory和spark.executor.cores申请的资源超出了队列可用资源的总上限或者 executor 内存与 YARN container 内存不匹配。排查的时候直接看yarn application -status appId里的ResourceRequest一眼就能看出申请的资源被别人是否能满足。第三动态分区写入的数据倾斜。这个在 Hive 里写动态分区表时特别容易爆某个分区底下的数据量特别大导致负责写出这个分区的 task 压力剧增甚至 OOM。实际处理中我习惯对数据量特别大的时间分区比如当天单独INSERT其他小分区走动态分区顺便设置hive.exec.max.dynamic.partitions足够大、hive.exec.dynamic.partitions.modenonstrict。4.4 使用 DistCp 做数据迁移时的几个坑DistCp 是 Hadoop 生态里做跨集群数据复制最常用的工具但很多人只用最简单的命令踩了坑都不知道怎么回事。先列一个最容易被忽略的参数-update。它表示只复制源端比目标端新的文件增量同步时必不可少。但如果你不带-delete那目标端多出来的文件就不会被清理时间长了两个“同步”的目录可能差异巨大。具体怎么选看你的同步策略。如果目标是完整镜像就-update -delete如果只是增量追加-update就够了。另外还有一个老生常谈的坑跨版本迁移。源集群是 Hadoop 2.x目标集群是 Hadoop 3.x直接跑 DistCp经常会报BlockSize mismatch或者file size mismatch。这是因为新旧版本之间的默认块大小或校验策略有细微差异。稳妥的做法是在命令里显式加上-pb保留块大小、-pc保留校验和或者干脆加上-strategy dynamic来应对大量文件传输时的任务调度。实战感受20TB 以上级别的跨机房数据迁移优先用 DistCp 结合-bandwidth参数限制带宽避免打满生产集群网络。我曾经见过有人开全速传输结果把生产集群的 CPU 和网络全占满了跑在集群上的实时任务全部超时教训非常深刻。4.5 伪分布式、容器化与“环境问题”的排查如果你是初学者正在练习“伪分布式搭建”或者正在用 Docker 镜像部署 Hadoop那我要多说两句。伪分布式模式下你遇到的绝大部分故障都和“配置不一致”有关。最常见的就是localhost与hostname混用。HDFS 把元数据里的地址写死了localhost但 YARN 那边又用了hadoop01结果 NameNode 注册信息里一堆节点地址对不上DataNode 反复超时。一个特别容易出问题的细节伪分布式的/etc/hosts映射。很多教程让你把hadoop01映射到127.0.0.1但 Linux 系统默认还会把hostname解析到其他 IP。这会导致 Hadoop 服务尝试绑定到莫名其妙的地址上表现为日志里报java.net.BindException: Cannot assign requested address。排查思路很简单hostname -i看你本机 IP 对不对如果不一致改/etc/hosts强制绑定。用 Docker 部署 Hadoop 和 ZooKeeper 时又有一个极具迷惑性的问题容器重启后 IP 变了。NameNode 里记录的是旧容器的 IP等容器重新创建后DataNode 全部失联但docker ps里每个容器都显示运行中。这个排障起来真的会怀疑人生。标准解法是部署时指定固定 IP 或者容器名做 DNS 解析把fs.defaultFS里的地址配置成容器名而不是 IP。这也是为什么很多人建议直接把 Hadoop 的元数据目录挂载到宿主机卷上否则每重建一次容器整个集群就要重新格式化一次数据全没。如果你在练习“HA 高可用”或“Hadoop 与 ZooKeeper 整合实战”不妨用 Docker 起一个 ZK 集群再起两个 NameNode 做 HA 测试。但一定要记住测试完之后的stop-all.sh并不会帮你清空 ZK 上的临时节点下次再启动时如果提示选主失败先去看看 ZK 里残留的/hadoop-ha节点建议直接rmr删掉再重启。这个操作很简单但很多人在这一步浪费过两三个小时。5. 那些“非技术”但能让你崩溃的隐性问题故障排查不是只盯着技术栈就能解决的。有几个事情虽然谈不上“高深”但处理不好会让你日夜难安。5.1 文件权限问题DataNode 报权限异常HDFS 的权限模型跟 POSIX 文件系统类似但用户映射关系很容易出问题。最常见的是HDFS_PERMISSIONS_ENABLEDtrue时你用 root 或者其他非 Hadoop 用户执行hdfs dfs -put报Permission denied。很多菜鸟会选择暴力关闭权限校验property namedfs.permissions.enabled/name valuefalse/value /property这种改法本身没错——如果你只是搭建本地学习环境。但在多人共享的集群上关闭权限等于让所有人的数据“裸奔”。所以我一直建议权限问题一律通过hdfs dfs -chmod、-chown去正规解决配合 HDFS ACLhdfs dfs -setfacl去管理目录级权限。尤其是团队协作场景合理用 ACL 给不同小组配好目录访问权限远比把权限整个关掉科学多了。顺带提一句“行、列权限设计”在 HDFS 场景里其实不太存在因为 HDFS 是文件系统权限粒度是文件和目录。但像 Hive、Spark 这类上层 SQL 引擎已经可以通过 Apache Ranger 或 Sentry 做行级和列级权限控制HDFS 层只负责文件权限打底。如果你们公司对数据安全要求比较高建议走这层方案。5.2 系统和网络的“潜规则”有没有遇到过这种情况所有组件日志都正常监控指标也平稳但作业就是跑得奇慢无比这时候我会优先检查几个系统层的东西。ulimit -n文件句柄数是非常关键的一个。DataNode 在大量并发读写时文件句柄数很容易突破默认的 1024。Hadoop 官方文档明确要求把ulimit -n设置到 65536 以上但这需要配在/etc/security/limits.conf和sshd的PAM模块里。顺便看看vm.swappiness太高的话系统会不停换页导致 JVM 表现极不稳定。一般建议vm.swappiness10或直接0内核版本不同注意权衡同时vm.overcommit_memory要设为 1 或者调整-XX:MaxDirectMemorySize以避免 Netty 等堆外内存申请失败。还有一个非常隐蔽的坑ntp 时间同步。Hadoop 集群节点之间如果时间偏差超过一定阈值Kerberos 认证如果开了会直接失败而且 ZooKeeper 也会出现会话错乱。检查命令ntpq -p date -R各节点时间差超过 50ms 就要立即处理。开 Kerberos 的环境时差稍微大一点你会看到一大堆Clock skew too great的错误。这类系统级问题排查起来毫无“技术感”但往往能解决你折腾两三天都搞不定的疑难杂症。5.3 灭火之后故障复盘比修复更重要说一个心态层面的经验。每次故障恢复之后我建议你花至少半小时做一份简单的复盘记录。不用搞什么花哨的 RCA 文档就回答三个问题故障的第一触发点是什么比如磁盘满、配置错误、代码 bug、依赖服务超时这个故障如果再次发生有没有更早的感知手段比如是不是缺一个磁盘使用率告警在故障恢复过程中你执行的哪个动作最有效有没有哪个动作其实没必要甚至有害我现在处理集群问题的效率和几年前相比完全不是一个量级很大程度就靠这种“每次翻车都留下记录”的习惯。将每次排查的命令、日志关键行、解决方案整理成自己的知识库时间久了你会发现自己对大数据的理解层次完全不同了——你不是在背命令而是在理解系统。6. 一套可以直接落地的故障排查实战流程纸上谈兵到此为止我把自己日常排障的一套“肌肉记忆”流程写下来。读者可以参考着建立自己的 SOP以后遇到问题照着做能省下大量试错时间。6.1 分钟级快速定位流程假如现在集群出问题了我的第一波操作永远是这几步确认影响面登录 NameNode 或 ResourceManager 的 Web UI看节点是否存活、当前是否有作业失败。这决定了是“全集群故障”还是“局部任务异常”。看系统指标uptime、free -h、df -h、iostat -x 1、sar -n DEV 1 5。重点排查磁盘满、CPU 飙高、网络重传率。查组件日志按组件路径找到对应日志tail -n 200 | grep -i exception。先用时间范围过滤不要从头看起。查 YARN 作业明细yarn application -list -appStates RUNNING,FAILED,KILLED对失败的作业执行yarn application -status和yarn logs -applicationId。尝试小规模验证选一个小文件跑一个简单hdfs dfs -cat或者一行 SQL确认基础链路通不通。这么一套走完正常情况下 10 分钟内就能把问题缩小到一个很小的范围而不会像无头苍蝇一样乱试。6.2 日志、监控、命令的“铁三角”很多人问我排查故障最重要的是什么我的回答是建立能支撑你判断的“证据链”。日志是证据监控指标是证据命令行返回结果也是证据。如果只看一个来源就急着下手改配置大概率会被后续更诡异的现象打脸。我现在见过太多人出问题了到处找“tuning 秘籍”什么“10 个参数让你 Hadoop 性能翻倍”之类的。性能调优本身没有错但如果你连当前瓶颈在哪、日志报错在什么都还没搞清楚贸然改动dfs.replication、mapreduce.reduce.memory.mb这种全局参数很容易把原本正常的集群改成“半残废”状态。所有参数调整都应该遵循“一次只改一个变量、压测验证、不行就回滚”的原则。6.3 排障工具箱那些我每次都用的命令整理一个高频命令清单建议你收藏场景命令说明查看块上报与安全模式hdfs dfsadmin -report集群整体健康度块/节点数一目了然检查文件完整度hdfs fsck /path -files -blocks -locations定位缺失块与副本位置查看组件状态hdfs haadmin -getAllServiceStateHA 场景下确认谁是 Active查看 YARN 节点资源yarn node -list -all -showDetails各节点资源使用与容器状态拉取作业日志yarn logs -applicationId appId容器级日志排查问题最直接查看 NameNode 内存jmap -heap pid确认堆使用与 GC 配置查看 RPC 延迟hdfs dfsadmin -refreshSuperUserGroupsConfiguration等更多配合监控平台使用这些命令看上去都很基础但基础意味着被验证的次数最多也最稳定。有时候高级的“技巧”只是伪需求老老实实把基础命令用好已经能扛住八成以上的故障场景了。写在最后我对 Hadoop 排障这件事的体会我这些年下来最大的感受是Hadoop 的故障排查其实是一个“逻辑推理 经验验证”的游戏而不是一个“知识背诵”的游戏。你不可能记得每一个报错信息对应的解决方案但你必须有能力通过日志、监控、系统状态这些线索把真正的原因“推理”出来。遇到问题不要慌按照“确认影响面 → 看系统指标 → 查组件日志 → 看作业明细 → 小规模验证”的链路一步步来多数的故障都会在你面前现出原形。再冷门的问题只要你能定位到相关日志离找到解决方案就不远了。最后再分享一个个人的小习惯我会在自己电脑上维护一个“排障笔记”每次遇到一个值得记录的坑就立刻把现象、日志关键行、排查过程、最终处理方法整理进文档里。半年下来这个笔记就是一笔非常宝贵的技术资产。当你发现自己排查问题的速度越来越快、处理过的故障类型越来越多那种“心中有数”的感觉是看多少篇博客都换不来的。