image.png

每次 面试，其实都有套路，面试官一定会问一个问题，就是你 在做什么时候碰到过什么困难，怎么解决的。其实这里面 话中有话，其实就是检验一下 你有没有真实的做过，还是只是刷面经 应付过来的，只有你真的做过，你 才知道其中的一些坑在哪里。

下面用我的苦难为大家贡献一个面试能用的上的，不知道面试官是否领情，最主要的是 这个不是大家都知道的，我们老大瞪着我，你要搞清楚 hadoop 原理，你要 敢于修改hadoop 源码，你要。。。

我们 为了对接 几家大厂的数据链，集群吧马上就要大量扩容了。
为了给大扩容 演练一下，我们先尝试 小扩容，只是扩了一台机器，其实也是救急，本来当时扩容 构建运行环境时也碰到了很多问题，但是吧 都比较容易定位到问题的根源，最害怕的问题是 知道错了，还不知道错在哪里，由什么根源造成的，错误 是一个错误连，经常是一错再错，整个链路上都像多米诺骨牌一样倒下。你如何定位 错误是根源，还是 被牵连的吃瓜群众，都是需要经历磨练的。

我们这次 扩容，我本来认为自己 差不多已经足够小心 谨慎，动态扩容 负载均衡 尽量对数据的伤害到最低。但是 做程序 最大的痛苦和快乐，bug 时刻所见，就像幽灵一样

我们这次 扩容 由于 rebalance 耗时太长，被我们强制给停掉了，而且集群还重启了，说实话还是有点 胆怯，毕竟 丢数据 事儿大，坐牢 事儿小 🙂， 结果在跑 mapReduce job 的时候吧，可以成功，我们很开心，但是吧 map Reduce 中间竟然有报错的内容

image.png

仔细看吧 确实是个异常，失败信息，但是吧，写的也不是很具体，意思是 本地没有足够的硬盘可以使用了，这个发生在job 尝试中，我当时就有点懵逼，是不是 ，老集群 看新节点不顺眼，故意找茬儿呢，这群戏精，老是折腾老纸，这么说吧，�我都看不到 到底是哪个类 哪一行 报的错，我咋定位，这个还特别急，老大 风风火火，眼里容不得错误，另外一个愁人的事情就是，加了新节点 ，集群竟然更慢了，原来四十分钟的job，现在要跑6个小时，老大恨得牙痒痒，这个确实无法忍受，集群等于存在重大异常，必须解决掉。咋整，我也很迷茫。

后来我说 调试吧，服务器内网，我也连不上，只能想其他法子。老夫手捧键盘 就一个字 干。
想了想 ，还是可以整整的，既然就是job 在尝试中报错，我就去看hadoop jar 中job 相关的类，然后我把最重要的报错信息 先谷歌了一下，没有可用的结果，然后又百度，也没有，看来这个错误要么 太低级 要么太高深了。然后我 尝试在hadoop 源码中找到这个 Exception的 输出信息 代码的位置，通过使用 IDEA --edit ---find ---find path

image.png

在hadoop jar中找到了 这段代码

image.png

可以看出来 ，这个类 就是在mapReduce时 使用的
，叫做本地目录资源分配器，就是因为本地目录没有办法分配，导致报错了
如果 是hadoop 内部的异常 ，我们通常优先怀疑的是 磁盘权限或者 端口防火墙，询问了 运维 端口都是裸奔着，基本上判断 端口没有问题，接着就是磁盘，我记得磁盘权限都 赋予了，难道是系统盘 真的写满了，我又在集群查看了所有节点的磁盘使用，基本都是正常的，没有超过警戒线。那可能真的是磁盘问题，但是也不能太确定，还有 到底是整个集群有毛病，还是 只是其中的某一个节点 给集群拖后腿了，想想不得而知，然后就想 能不能通过 job 运行的详细日志来判断 呢，我 就在 jobHistory 中找

image.png

image.png

从 简要日志信息没有发现异常

image.png

image.png

通过关键字 fail 我们进行搜索 发现了一些错误日志信息的位置

image.png

image.png

通过对多个 job 的日志分析，发现 这个异常 基本都是 hadoop-data04 这个节点的问题，刚好就是新节点，看来 新节点 有点 水土不服哦

既然就是 新节点，我们 就看几个问题，新节点的 jdk host PATH 环境变量都和集群一样，hadoop直接从Manager copy过来的，配置文件也都一样，不过有一个问题就是，新机器的硬件信息和其他节点有区别，老节点是 8 cpu 16 G memory，而新节点是 4cpu 8G,接着我去修改了 新节点 hadoop配置文件 hdfs-site.xml 中cpu 和memory的相关配置，使之正确，然后重启集群，发现还是原来的报错，并没有解决，然后接着苦恼，怎么办 ，看看硬盘吧，然后就看其他老节点 数据 存储 硬盘的权限，发现了 大问题，

image.png

image.png

image.png

三台老节点 的数据节点 权限信息 和目录信息
新的节点 一查看 果然有大问题

image.png

数据节点 竟然没有生成 NodeManager 目录 ！！！，而且 通过 lost+found 目录，你发现 这些磁盘的权限是属于root 的，我当时偷懒 ，只是手工一个个创建了 DataNode 目录并 赋权给hadoop操作用户，看来是 权限不足导致的 NodeManager创建不了，最后一直报错，我马上 给这些 数据磁盘 整体上把所有者修改为 hadoop 操作用户

`
chown -R linkedme_hadoop:linkedme_hadoop /data*

`

image.png

然后我重启集群，再来 新节点查看 NodeManager 目录总算是自动生成了，

image.png

而且 再看 job 的执行，发现已经不报错了

image.png

image.png

总结：

1. 大部分 bug 都是人祸
   2.如果方法够先进， 解决bug 不是难题
   3.大部分 自己埋在配置和代码中的地雷最后 还是要自己 踩爆
   4.数据就是绳命，请善待 数据
   5.要学会从日志中 分析出错误 的原因
   6.文件 目录权限和端口防火墙 衍生的bug 是你此生碰到最多的
   7.每一个折磨人长久的bug ，可能都只是一个很小很小的问题根源，被不断的放大