大数据平台主要是在Cloudera Manager上搭建起来的，这里列出了，目前遇到过的几个问题以及解决方法
问题描述：
文件系统检查点已有 1 天，14 小时，36 分钟。占配置检查点期限 1 小时的 3,860.33%。 临界阈值：400.00%。 自上个文件系统检查点以来已发生 14,632 个事务。
解决方法：
2个可能
1、namenode的Cluster ID 与 secondnamenode的Cluster ID 不一致，对比/dfs/nn/current/VERSION 和/dfs/snn/current/VERSION中的Cluster ID 来确认，如果不一致改成一致后重启应该可以解决。
2、修改之后还出现这个状况，查看secondnamenode 日志，报
ERROR： Exception in doCheckpoint java.io.IOException: Inconsistent checkpoint field
这个错误，直接删除 /dfs/snn/current/下所有文件，重启snn节点
问题描述：
已成功启用 High Availability
完成本向导后必须手动执行下列步骤：
– 对于每个 Hive 服务 Hive，停止 Hive 服务，将 Hive Metastore 数据库备份到永久性存储中，运行服务命令”更新 Hive Metastore NameNodes”，然后重启 Hive 服务。
问题描述：
namenode standby的目录文件被我不小心删除了，无法进行格式化，也无法重启。
解决方法：
将活动的namenode数据目录下的所有文件拷贝一份过来重启即可。
问题描述：
Kettle中无法连接内网的Hadoop集群
解决方法：
这个问题还是因为我们集群的独立网段连接问题，首先需要在插件目录下，将hadoop集群的相关配置文件拷贝过来，否则后续会出现各种无法连接或者数据节点无法写入数据文件的问题：$KETTLE_HOME/plugins/pentaho-big-data-plugin/hadoop-configurations/cdh54
问题描述：
大数据平台服务器均为万兆双口网卡+千兆双口网卡，万兆网卡连接独立的光交换机以进行数据交换。千兆网卡连接外部其他的运营网段，以对外提供数据服务接口或者抽取数据。而目前大数据集群独立网段内连接可以正常进行数据交换和连接，但是在其他运营网段服务器中访问集群出现无法访问的问题。
解决方法：
修改文件：hdfs-site.xml，添加RPC配置：
<property>
<name>dfs.namenode.rpc-bind-host</name>
<value>0.0.0.0</value>
<description>
The actual address the RPC server will bind to. If this optional address is
set, it overrides only the hostname portion of dfs.namenode.rpc-address.
It can also be specified per name node or name service for HA/Federation.
This is useful for making the name node listen on all interfaces by
setting it to 0.0.0.0.
</description>
</property>
<property>
<name>dfs.namenode.servicerpc-bind-host</name>
<value>0.0.0.0</value>
<description>
The actual address the service RPC server will bind to. If this optional address is
set, it overrides only the hostname portion of dfs.namenode.servicerpc-address.
It can also be specified per name node or name service for HA/Federation.
This is useful for making the name node listen on all interfaces by
setting it to 0.0.0.0.
</description>
</property>
<property>
<name>dfs.namenode.http-bind-host</name>
<value>0.0.0.0</value>
<description>
The actual adress the HTTP server will bind to. If this optional address
is set, it overrides only the hostname portion of dfs.namenode.http-address.
It can also be specified per name node or name service for HA/Federation.
This is useful for making the name node HTTP server listen on all
interfaces by setting it to 0.0.0.0.
</description>
</property>
<property>
<name>dfs.namenode.https-bind-host</name>
<value>0.0.0.0</value>
<description>
The actual adress the HTTPS server will bind to. If this optional address
is set, it overrides only the hostname portion of dfs.namenode.https-address.
It can also be specified per name node or name service for HA/Federation.
This is useful for making the name node HTTPS server listen on all
interfaces by setting it to 0.0.0.0.
</description>
</property>
<property>
<name>dfs.client.use.datanode.hostname</name>
<value>true</value>
<description>Whether clients should use datanode hostnames when
connecting to datanodes.
</description>
</property>
<property>
<name>dfs.datanode.use.datanode.hostname</name>
<value>true</value>
<description>Whether datanodes should use datanode hostnames when
connecting to other datanodes for data transfer.
</description>
</property>
参考连接：http://hadoop.apache.org/docs/r2.6.4/hadoop-project-dist/hadoop-hdfs/HdfsMultihoming.html
添加以上配置之后已经可以正常和namenode进行交互，但是写入数据时却无法和datanode交互，按理说只要配置了dfs.client.use.datanode.hostname=true就可以实现和datanode之间通信，查看错误，内部对应的IP实际上是正确
的。在Cloudera Manager中我们发现很多地方默认配置的都是主机名+端口号，比如：dfs.datanode.address默认设置为：0.0.0.0:50010，但是CDH中修改为了 host:50010 导致数据节点之无法监听到另外一个网卡IP过来的数据。
这里只要将值修改为：0.0.0.0:50010即可。
问题描述：
重启某个角色的时候，突然无法启动了，报错:
Command aborted because of exception: Command timed-out after 150 seconds.
解决方法：
1.再重启一次居然好了
2.另外一次是datanode无法启动，将yarn的nodemanager重启后，再重启hdfs datanode，发现可以了。
3.终极大法，重启agent
service cloudera-scm-agent next_stop_hard
service cloudera-scm-agent restart
Cloudera Manager Agent uses a python library called supervisord to manage
the processes it launches on each host. When you do hard_restart, it
restarts CM agent, supervisord and all processes that supervisord launched.
Likely you had something in bad state and hard_restart fixed it.
问题描述：
HBase RegionServer已经启动，但是CM上却显示的是未启动，导致报端口占用：
Caused by: java.net.BindException: Address already in use
解决方法：
直接在操作系统kill掉进程。
问题描述：
服务与主机长时间无法进行通信
表现如下（心跳时间特别长，大于15秒）：
解决方法：
一般是因为agent的进程问题，最早之前网络不稳定经常会导致出现这样的问题，交换机更换以后没再出现这样的问题。
一般重启agent服务即可：
重启方式：
systemctl restart cloudera-scm-agent
systemctl status cloudera-scm-agent
问题描述：
系统文件描述符超过阈值
解决方法：
如果是CM中某个角色报这个错误，只要修改角色中的配置即可，将数值调整到合理的大小就行，默认的是1024肯定不够：
修改：Maximum Process File Descriptors
问题描述：
16/10/12 08:48:26 WARN cluster.YarnSchedulerBackend$YarnSchedulerEndpoint: Container marked as failed: container_e15_1474518018065_4376_02_000017 on host: bigdata3. Exit status: -1000. Diagnostics: java.net.UnknownHostException: nameservice1
java.lang.IllegalArgumentException: java.net.UnknownHostException: nameservice1
…
Caused by: java.net.UnknownHostException: nameservice1
... 27 more
Caused by: nameservice1
java.net.UnknownHostException: nameservice1
说明是节点bigdata3的yarn通信有问题，一般是配置文件不对，或者其他原因
解决方法：
重启了下bigdata3的NodeManager后就好了。
现在的外国人都这么精通中文吗？
只能说，在谷歌很容易搜索到我的文章，但是在百度却搜索不到