工作中Hadoop,Spark,Phoenix,Impala 集群中遇到坑及解决方案

1.HDFS 修复

问题描述：其他部门在yarn平台上跑spark 程序错误的生成了海量的不到100K的小文件，导致namenode压力过大，其中一个namenode宕机后，没有及时发现 使得edits文件大量积累，在namenode1宕机后，namenode2 随后在凌晨1点也宕机。

原因分析：NameNode 内存设置太低，之前内存设置在1G，后调高namenode 堆内存，调高到18G。编写程序的人员不应该生成海量的小文件落地HDFS，大量的小文件不适合存储在HDFS上。

问题解决方案：提高namenode 内存，由于edits文件太多，删除了edits文件，但是journalNode 上edits txid不一致，导致namenode 无法启动，后执行命令 初始化edits文件的txid ，修复完毕！丢失了少量的文件。

2.Spark 客户端安装后Driver和Yarn无法通讯

问题描述：项目经理在10.10.26.7 机器上安装spark 客户端，但是dirver端和yarn无法通讯.一直报通讯超时

原因分析：由于客户端是centos6,服务端为centos7。底层通讯方式不相同

问题解决方案：升级客户端机器到centos7问题解决。

3.Phoenix 安装和Hive出现冲突

问题描述：把 phoenix-hbase-client.jar phoenix-hbase-core.jar phoenix-hbase-server.jar 放到了hbase的jar目录下，hbase 使用没有问题，phoenix使用没有问题，但是执行hive命令报错，hive无法使用。

原因分析：hive首先加载hive lib目录下的jar文件，然后加载hbase 下的jar文件，由于hbase下phoenix-hbase-client.jar文件中的一个java文件依赖的其他jar版本太低，hive版本太高，无法找到其中一个类，然后报ClassNotDef

问题解决方案：去掉phoenix-hbase-client.jar 即可，目前看来这个包没有什么用。

4.HDFS扩容升级

问题描述：新增加机器，扩容HDFS，已经扩容完毕，之后运维部重新挂载磁盘，HDFS出现逻辑卷错误

问题分析：日志显示挂载磁盘错误，实际是写数据的目录权限不足

问题解决方案：修改挂载的磁盘的所属用户为hadoop，重新启动dataNode即可

5.Yarn NodeManager OOM

问题描述：向集群提交大的作业 Yarn平台的NodeManager OOM ，OOM死掉后的NodeManager，存活的NodeManager 正在运行就会出现core使用出现负数。

问题分析：由于yarn进程所需的内存不足出现OOM

问题解决方案：在/opt/hadoop/libexe/hadoop_config.sh 在尾部添加

6. Impala 根据时间戳查询Hbase

问题描述：使用Impala 查询hbase中的数据，出现错误找不到列

问题分析：impala不支持根据hbase timestamp查询

问题解决方案：https://issues.apache.org/jira/browse/IMPALA-2121

7.HDFS 异构存储 磁盘容量不一致

问题描述：由于HDFS dataNode节点的磁盘大小不一致，导致小容量的HDFS先打满，yarn跑任务出现问题

问题分析：尽量让数据一致

问题解决方案：开启HDFS让数据优先写入容量大的磁盘，优先写入容量的dataNode节点，开启rebalance

8.HDFS 机架感知不可以同时存在有机架和没有机架的节点

问题描述：机架感知不可以同时存在有机架和没有机架的节点

问题分析：开始以为是HDFS的topology.sh文件中的default-rack导致的，但是修改为已有的机架依旧不可以，观察HDFS源码发现hdfs源码中也有default-rack，如果没有机架配置默认使用default-rack即没有机架

问题解决方案：由于topology.data文件最后一行需要回车即可

9.Yarn NodeManager 宕机

问题描述：新增的NodeManager 机器NodeManager 进程一直宕

问题分析：观察日志问OOM，打开文件limit受限制

问题解决方案：修改linux系统其它用户打开文件数量的限制即可解决

10. HDFS NameNode无法和JournalNode通讯，NameNode宕机

问题描述： 由于运维修改网络导致journalNode无法和nameNode 通讯,观察日志NameNode尝试与journalNode通讯10次失败后，NameNode直接宕机

问题分析:   JournalNode网络通讯高可用需要保证

问题解决方案：重新启动nameNode问题解决