Hadoop配置文件详解：把core-site.xml、hdfs-site.xml、mapred-site.xml和yarn-site.xml这四大文件吃透，集群才能跑得稳，绝大多数启动失败和性能问题都出在配置项写错或漏配。
很多朋友在搭建Hadoop集群时，启动报错第一反应是去看日志，查来查去最后发现是配置文件里的参数值写错了，Hadoop本身不复杂，复杂的是配置文件里几百个参数你不可能全记住，但核心那几个文件、几组关键项，必须心里有数,这篇内容咱们就掰开揉碎了讲清楚。
hadoop配置文件详解：从core-site.xml到yarn-site.xml
Hadoop的配置体系是纯文本XML格式，分布在$HADOOP_HOME/etc/hadoop目录下，集群里每台机器都有一份相同的配置副本，改完必须同步分发到所有节点，否则会出现各种莫名其妙的问题，行业共识认为,配置管理混乱是Hadoop集群运维事故的主要诱因之一。
核心配置文件清单
| 文件名称 | 主要作用 | |
|---|---|---|
| core-site.xml | 全局核心配置 | 默认文件系统、临时目录、HDFS访问地址 |
| hdfs-site.xml | HDFS组件配置 | 副本数、NameNode/DataNode存储路径、权限开关 |
| mapred-site.xml | MapReduce组件配置 | 计算框架选择、JobHistory服务 |
| yarn-site.xml | YARN资源调度配置 | ResourceManager地址、NodeManager内存上限 |
| workers | 节点列表文件 | 声明哪些主机是DataNode和NodeManager |
| hadoop-env.sh | 环境变量脚本 | JAVA_HOME、JVM堆大小、PID目录 |
四大核心文件逐个拆解：参数含义和常见坑
core-site.xml：一切配置的起点
这个文件负责Hadoop的全局默认值，几乎所有组件启动时都会先读它,最常见也最关键的两个参数：
fs.defaultFS：默认文件系统路径，格式是hdfs://namenode主机名:8020，如果你是单机测试模式，也可以写成file:///直接操作本地文件系统，这个值写错,HDFS根本起不来。hadoop.tmp.dir：Hadoop运行时临时目录，NameNode的元数据、DataNode的数据块文件默认都放在这个目录的子目录下。务必把它指向一个磁盘空间充足的独立分区（比如/data/hadoop/tmp），默认的/tmp目录在系统重启后会被自动清理，到时你的元数据丢失，整个集群就废了,这是个非常经典的事故场景。
hdfs-site.xml：决定你的数据怎么存
这个文件直接决定了数据的可靠性、读写性能和存储位置,重点看这几个：
dfs.replication：数据块副本数，默认是3，测试环境只有一台机器时建议改成1，否则会一直报副本不足的警告，生产环境如果服务器磁盘紧张，冷数据业务可以降到2,数据可靠性稍有下降但能省出大量磁盘空间。dfs.namenode.name.dir：NameNode元数据存储路径，官方强烈建议配成多个磁盘目录，用逗号分隔，相当于给元数据做双保险，一个磁盘坏了,另一个还有副本可用。dfs.datanode.data.dir：DataNode实际存数据块的目录，同样支持多目录，如果服务器挂载了多块数据盘，把这些盘符全列在这里,Hadoop会自动做均衡写入。dfs.permissions.enabled：HDFS权限开关，默认是true，如果你的业务需要客户端直接以root操作、不想折腾Kerberos和用户组映射，就先把它设为false，不关的话，很常见的就是Permission denied报错。
mapred-site.xml：控制计算框架行为
这个文件的历史包袱比较重，因为MapReduce老版本和新版本（YARN模式）的写法完全不同,现在主流版本只要确认两个地方：
mapreduce.framework.name：必须设为yarn，让MR任务跑在YARN资源调度器上，如果是local，代码里提交的任务会在本地跑,不占用集群资源。mapreduce.jobhistory.address：JobHistory Server的地址，格式是主机名:10020，不配的话，跑完的任务日志查不到,排查问题只能干瞪眼。
yarn-site.xml：资源调度的命脉
YARN负责给计算任务分配CPU和内存,配置不当会导致任务反复OOM或资源利用率极低。
yarn.resourcemanager.hostname：ResourceManager所在主机名，不配这个,NodeManager启动后注册不知道找谁。yarn.nodemanager.resource.memory-mb：每个节点可供YARN使用的物理内存上限，这个超级关键，比如机器有64G内存，系统自身和DataNode等进程要留一部分，那么这里建议设置在48G到56G之间，设得过大，系统会直接OOM；设得过小,跑大任务时内存不够全挤在队列里等。yarn.scheduler.maximum-allocation-mb：单个Container能申请的最大内存，如果设成8G，即使你的代码里调了spark.executor.memory=20g，也还是会被强行按8G来分配,任务直接卡住。
hadoop配置文件修改后不生效？先检查这四处
这是群里被问到次数最多的一类问题，改完了配置，执行hdfs dfsadmin -refreshNodes或者重启进程，发现新参数完全没起作用，按照这个顺序排查,基本能解决九成问题。
- 配置文件改错位置，比较常见的是改了
/etc/hadoop/下面的，但实际环境变量HADOOP_CONF_DIR指向的是另一个目录，用echo $HADOOP_CONF_DIR确认当前生效的配置路径。 - XML格式错误，少于标签没闭合、多了个中文字符、注释嵌套错误，执行
python -c "import xml.etree.ElementTree as ET; ET.parse('core-site.xml'); print('OK')"快速验证语法,比肉眼一遍一遍看强多了。 - 参数名拼写错误，Hadoop对参数名大小写敏感，
dfs.replication和Dfs.replication完全是两个东西，改完参数务必用grep在文件里确认一遍。 - 没有同步到所有节点，只改了master上的配置直接重启，NodeManager节点上的
yarn-site.xml还是旧值，ResourceManager调度时获取的仍然是旧的资源数据，用scp或者配置管理工具把完整配置目录同步到所有worker节点,然后逐台重启相关进程。
hadoop配置文件参数调优：三个最容易踩的坑
内存分配不能只看物理内存大小
业内人士提醒，集群中每台机器上同时还跑着DataNode、NodeManager、操作系统本身，以及可能的HBase RegionServer，它们都要抢内存，你给YARN分得越多，系统留的越少，最终结果就是进程频繁被系统OOM Killer杀掉，到时候看日志全是Container killed on request. Exit code is 137。合理做法是先由运维梳理清楚节点上全部常驻进程的内存占用，再倒推YARN可分配的内存上限。
副本数不是越多越好
默认3个副本是针对常规生产环境的平衡值，有些运维拍脑袋改成5，理由是想“数据更安全”，但磁盘成本直接上涨六成以上，写入性能也明显下降，纯离线数仓场景，数据上游都有原始备份,2个副本完全够用。
临时目录和数据目录必须分开
有相当一部分用户图省事，把hadoop.tmp.dir和dfs.data.dir指到同一个挂载点，这是有隐患的，NameNode的元数据文件（fsimage）和DataNode的块文件如果同时在一个磁盘上，磁盘IO繁忙时互相干扰，还会因为磁盘满导致NameNode直接进入安全模式，把元数据、数据、日志分到不同磁盘,这是一个比较稳妥的通用做法。
高可用集群配置：把NameNode从单点故障中解救出来
小规模开发环境单NameNode无所谓，但生产环境必须上HA，核心思路是两台NameNode一主一备，通过JournalNodes共享 edits 日志，配置上涉及core-site.xml和hdfs-site.xml两处配合。
在core-site.xml里把fs.defaultFS从单机地址改成逻辑名称，比如hdfs://mycluster，然后在hdfs-site.xml里声明这个逻辑名称对应哪两台机器：
dfs.ha.namenodes.mycluster：配置两个NameNode的唯一标识名，比如nn1,nn2。dfs.namenode.rpc-address.mycluster.nn1：对应第一台NameNode的RPC地址，格式是主机名:8020。dfs.namenode.rpc-address.mycluster.nn2：对应第二台。dfs.namenode.shared.edits.dir：JournalNode的共享编辑日志地址，通常是qjournal://node1:8485;node2:8485;node3:8485/mycluster。- 别忘了配
dfs.client.failover.proxy.provider,客户端才能自动感知主备切换。
配完之后强制的几轮操作步骤：先启动ZooKeeper和JournalNode，再格式化其中一台NameNode并同步元数据给另一台，最后执行hdfs haadmin -transitionToActive nn1让主节点接管。
Hadoop常见问题速查
hadoop配置文件哪个最重要？
如果说只能选一个，core-site.xml里的fs.defaultFS是命脉，它定义了整个集群的入口地址，所有客户端和节点靠它识别认知的“根”，但它对存储和计算资源的影响不如hdfs-site.xml和yarn-site.xml深，通俗理解就是，core-site.xml决定“你是谁”，hdfs-site.xml决定“你的数据怎么放”，yarn-site.xml决定“你的算力怎么分”。
为什么改了hdfs-site.xml里的副本数，put文件上去还是3个副本？
HDFS的副本数读取原则是“以客户端请求时的配置为准”，如果你在代码里通过Configuration.set("dfs.replication", "1")指定了副本数，它会覆盖服务器配置，HDFS通过Shell命令hdfs dfs -Ddfs.replication=2 -put /data /tmp上传，那么当前文件副本数就是2，之后上传的文件才会按照新的服务器配置值，改副本数不会自动影响已经存在的数据块，要调整存量文件，得用hdfs fsck /路径 -files -blocks -locations找出副本数不足的文件，再执行hdfs dfs -setrep -R 2 /路径进行修正，这样处理完,集群状态才会完全符合预期配置。