fs.defaultfs必须配置真实namenode主机名或vip并确保dns可解析，hadoop.tmp.dir须设为大容量独立磁盘路径且权限正确，io.file.buffer.size不宜过大以防内核拷贝开销上升，启用kerberos需同步客户端krb5.conf、keytab及principal并开启鉴权。
core-site.xml 里 fs.defaultFS 配错了，整个集群连不进 HDFS
这个参数是 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 解析，漏一个环节就卡住，而且错误信息往往不直接指明哪一环断了。
