大数据开发之Hive案例篇14：某个节点HDFS块比较多
一. 问题描述
今天早上到公司，突然收到CDH集群某个节点的存储量的告警，如下图所示:
image.png
从图中可以看出，每个节点的HDFS空间是相同的，大多节点HDFS使用量在40%左右，而出问题的这个节点居然直逼80%，鉴于之前问题出现过多次，且每次都是利用空余时间使用HDFS的rebalance进行解决的，此处需要找出具体问题，规避此类问题。
二. 解决方案
2.1 查看节点安装的组件
image.png
2.2 排查HDFS配置
初步排查了一下各个节点的HDFS配置，暂未发现问题，且各个节点HDFS的配置是通过 Cloudera Manager进行配置的，配置也相同，不存在某个节点的HDFS相关配置出现问题，进而出现个别节点资源使用率高的情况。
2.3 排查Yarn配置
2.3.1 首先查看下nodemanager的日志
对比出问题的节点和正常的节点，从审计日志量来看，出问题的节点审计日志明显比正常节点多。
image.png
审计日志内容均是申请AM的，现在的问题是为什么cdh10节点的AM比其他节点多那么多?
image.png
2.3.2 查看container分配情况
正在运行container:
从下面截图来看，未发现啥异常情况。
image.png
从历史分配情况来看:
对比了cdh10和cdh7，发现近7天分配的container是均匀的。
image.png
image.png
2.3.3 查看调度机制
那么此时可以这么理解，当集群处于空闲时，突然来了一个任务，那么此时因为所有container的优先级相同，优先选择的就是本节点的container，而第一个container 用于启动作业的AM进程，这也就对应了之前的，chd10节点申请AM会比其他节点多很多。
image.png
我们知道AM用于协调，并不直接参与预算，真正参与运算的是container，而HDFS一般是计算节点优先写一份数据导datanode，然后再写其他副本。但是从上一步的分配情况来看，container分布是均匀的，
2.3.4 查看集群任务情况
从 job history上来看，可以看到，集群内小任务比较多，而因为是CDH集群，调度采用的是 Fair Scheduler(公平调度器),没有给小任务预留一部分集群资源。
image.png
2.3.5 集群负载情况
从集群的负载情况来看，集群存在明显的业务高峰期和空闲期。
image.png
image.png
image.png
2.3.6 resourcemanager与nodemanager是否可以混合部署
搜索到某个大佬给得说法:
image.png
一般是建议分开进行部署。
2.4 初步判断
初步判断，由于cdh10节点，既包含resourcemanager又包含nodemanager，且对于优先级相同的 Containers，优选选择满足本地性的 Container，参与计算的Container会优先写一份到本地的HDFS，故cdh10节点写HDFS会比较多。
于是建议运维先进行 HDFS rebalance，然后将cdh10节点nodemanager进行删除。
2.5 最终结论
近期比较忙，没让运维的处理，然后又有flume消费Kafka的数据实时同步到HDFS，因为之前缺失一部分数据，然后某几个节点在补录数据，刚好补录历史数据的进程出现了问题，就把这部分数据从HDFS上删除了，打算重新补录。
删除后发现，cdh10和cdh3的HDFS使用量突然降下来了，问题最终浮出水面。
cdh10和cdh3上刚好就是补录数据，而HDFS的写流程，第一个副本客户端优先，此例中flume节点所在的节点就是客户端。
