如何优化Hadoop核心配置文件core-site.xml中的XML参数以提升大数据平台性能？

本文共计930个文字，预计阅读时间需要4分钟。

这个参数是Hadoop的入口地址，所有客户端端（包括hdfs命令、Spark、Hive等）都依赖它定位NameNode。配置为localhost:9000看似本地通信，但一旦集群或跨节点提交任务，就会报Connection refused或UnknownHostException。

• 必须填真实 NameNode 主机名或 VIP，且该主机名要能被所有节点 DNS 解析（或各节点 /etc/hosts 里有对应条目）
• 端口别硬写 9000 —— 检查 hdfs-site.xml 中 dfs.namenode.rpc-address 实际值，保持一致
• 如果启用了 HA，fs.defaultFS 应指向 nameservice 名（如 hdfs://mycluster），而不是单个 NN 地址

加了 hadoop.tmp.dir 却还是报磁盘空间不足

这个路径控制 Hadoop 运行时的临时文件位置（比如 MapReduce shuffle、YARN container 临时目录），但它默认指向 /tmp/hadoop-${user.name} —— 很多系统把 /tmp 挂在小容量内存盘或单独小分区上，压根撑不住大数据作业。

• 务必改成独立大容量磁盘路径，例如 /data/hadoop/tmp，且确保所有节点该路径存在、权限为 drwxr-xr-x、属主是 hadoop 用户
• 不要用符号链接路径（尤其跨文件系统），某些版本的 Hadoop 会因 getCanonicalPath() 失败而静默降级回默认路径
• YARN 和 HDFS 各自还有自己的临时目录配置（如 yarn.nodemanager.local-dirs），hadoop.tmp.dir 不影响它们，别指望一配全解决

io.file.buffer.size 调大后读写反而变慢

这个参数控制底层 IO 缓冲区大小（单位字节），默认 4KB。调到 64KB 甚至 128KB 在高吞吐场景下确实能减少系统调用次数，但不是越大越好。

• 超过 OS 页面大小（通常 4KB）太多，可能触发非对齐读写，反致内核拷贝开销上升
• MapReduce 中 map 输出若启用压缩（mapreduce.map.output.compress=true），过大的 buffer 会让压缩器缓存更多未压缩数据，延迟 flush，拖慢 shuffle
• 建议先观察实际 IO wait 和网络吞吐：如果磁盘 IOPS 饱和但带宽没跑满，可尝试调大；如果 CPU sys 时间飙升，就该调小

配置了 hadoop.security.authentication 却登录不了 Kerberos

设成 kerberos 只是打开开关，离真正可用差得远。最常踩的坑是：只改了服务端配置，忘了同步客户端环境。

• 所有客户端机器（包括提交作业的跳板机）必须安装 krb5.conf，并能访问 KDC；kinit -kt 能成功获取 ticket 才算过关
• core-site.xml 必须同时配 hadoop.security.authorization=true，否则即使认证通过，也会因鉴权未启用被拒绝访问
• HDFS 客户端连接时若报 GSS initiate failed，大概率是 keytab 文件权限太松（不能有 group/other 写权限）或 principal 名拼错（注意 host component 是否匹配服务器 hostname）

复杂点在于：Kerberos 配置生效依赖整个链路——JVM 的 java.security.krb5.conf 系统属性、Hadoop 自己的 krb5.conf 路径、keytab 文件路径、principal 名、hostname 解析，漏一个环节就卡住，而且错误信息往往不直接指明哪一环断了。