1、巡检
HDFS 为集群提供高可用性弹性存储服务，是集群的存储主体。
每日早晚巡检HDFS 服务，包括HDFS 服务可用性、存储使用率、datanode 是否有故障盘等。
1.1、HDFS 总体状态
①HDFS 状态，如下的红色提示需要关注
②HDFS 容量是否过阈值
1.2、HDFS UI 巡检
1.2.1、summary巡检
对应上图所示标号，逐一进行解释：
（1）HDFS 总文件数：此数值代表着 HDFS 存储内有多少文件，该数值的警告阈值为 5000W
（2）HDFS 总存储容量：此数值代表 HDFS 总存储容量
（3）占用存储容量：此数值代表为占用的 HDFS 存储容量
（4）HDFS 占用比：此数值应时刻关注，警戒阈值为 75%，如有超过，应立即告知业务侧清理数据
（5）平均占用比例：此数值代表着 HDFS 各个节点的存储使用均衡情况，若最后一个数字高于 5%，说明此刻系统的存储均衡是不正常的，需要判断是否有故障节点和执行 balance 操作
（6）集群内断开节点：此数值代表集群内与 hdfs 断开连接的节点，通常故障节点，可尝试登陆该主机判断故障问题（服务挂掉，系统宕机，硬件故障等）
1.2.2、NameNode Journal Status
1.2.3、datanode Volume Failures
发现坏卷要反馈给负责的同事进行报修
1.3、NameNode 巡检
1.3.1、NameNode 高可用是否存活
1.3.2、NameNode 状态是否正常
1.3.3、编辑日志同步平均时间是否过高
1.3.4、RPC 队列长度是否过高、处理时间是否过高
1.3.5、JVM 堆栈内存使用情况
1.3.6、主机内存使用情况
NameNode 节点主机内存，一般使用 56G 左右，总内存 128G。内存相对充裕。
NameNode 进程本身的内存，平均使用在 30G，总共分配了 60G。进程内存相对充裕。
NameNode 主机 CPU 使用率平均在 40%，CPU 资源相对充裕。
NameNode GC，平均低于 1ms，最大 4.5ms，GC 相对正常。
NameNodeRPC 连接数，平均在 2.5K，最高 5.5K，集群打开 RPC 连接数比较多，由于集群比较大，并且对 HDFS 访问较多，确实 RPC 会比较高。
1.3.7、磁盘延迟
1.4、DataNode巡检
在 HDFS 界面顶端点击 datanodes，会出现该集群内所有 datanode 主机清单
注意：该清单只包括 datanode，不包括 NameNode 等其他节点
（1）上图所示圆圈部分，是代表该节点存在坏卷，有可能是文件系统损坏也有可能是硬盘损坏，需要登录该主机进行故障判断，从而解决故障
（2）粉色部分代表该主机已经于 HDFS 断开，有可能是服务挂了，也有可能是主机硬件故障，同样需要登录主机判断（这里与首页 Dead Node 是一致的）
1.5、集群存储超过阈值案例
当 Hdfs 页面两个参数接近阈值时，需要清理集群上数据。
（1）HDFS 总文件数：此数值代表着 HDFS 存储内有多少文件，该数值的警告阈值为 5000W；
（2）HDFS 占用比：此数值应时刻关注，警戒阈值为 75%，如有超过，应立即告知业务侧清理数据。
1.5.1、清理集群数据方法
（1）集群存储使用率接近 75%时通知业务侧清理数据，务必将存储降到 75%以下。
通知方式：电话通知项目经理，并在大数据平台运维大群里通报各项目经理， 安排人员清理并且反馈清理进展，必要时通过集团接口人 XXX 推进。
（2）无法完成降到 75%以下目标时，通过降副本方式降存储。跟业务侧确认哪些表可以降幅本，并做好降幅本的记录。
（3）HDFS:/opt/hive/hivescratchdir 为 M/R 加工临时目录，7 天以上的数据可以清理，维护人员需要跟踪进度。
（4）HDFS:/files，该目录下小文件超多，文件数阈值 300 万，省分每天上传文件到这个目录，文件入 HBase 库后有定时清理计划，但发现接近阈值通知相关同事手动清理。
1.5.2、清理回收站文件
每天早上 8 点，hadoop@xxx.xxx.18.101 上的定时任务会执行/home/hadoop/trash.sh，这个脚本将清理 HDFS 上其他用户的.Trash 目录， hadoop 用户的.Trash 目录下，可以手动再删除之。
hadoop fs -du -s -h /user/hadoop/.Trash/
hadoop fs -rm -r /user/hadoop/.Trash/*此步操作务必小心！
1.6、平均负载和磁盘存储
目前集群节点的磁盘使用普遍达到了 70%以上。存储已经较满。建议进行扩容。平均负载如果超过 CPU 核数两倍以上说明有点高，如果在 5~10 倍以上就很高了。
1.7、参数巡检（第一次巡检需检查）
|
配置项 |
目前配置 |
建议配置 |
备注 |
|
HDFS 块大小 dfs.block.size，dfs.block.size |
512M |
|
128M 是常用的值，如果集群中存在 较多大文件，可以考虑增大该值 |
|
复制因子 dfs.replication |
3 |
|
存储充足的情况下，建议设置为 3 |
|
NameNode 数据目录 |
/data/dfs/name |
建议配置两个目录 |
通过两块硬盘，提高数据的可用性。 目前该节点就一块盘 |
|
NameNode dfs.namenode.handler.count |
200 |
|
根据集群规模可以适当调大 |
|
NameNode 服务处理程序计数 dfs.namenode.service.handler.count |
200 |
|
|
|
NameNode Java 堆栈大小 |
60G |
|
|
|
dfs.namenode.replication.work.multiplier.per.it eration |
10 |
|
|
|
datanode 数据目录 dfs.data.dir， dfs.datanode.data.dir |
/data/hdfsdsj[01-2 2]/data |
|
|
|
datanode 数据目录权限 dfs.datanode.data.dir.perm |
755 |
|
|
|
dfs.datanode.handler.count |
3 |
10 |
datanode 处理线程数可以适当调 大 |
|
最大传输线程dfs.datanode.max.xcieveRegionServer |
65536 |
8192 |
最大传输线程设置的比较大， 对 datanode 的压力较大，可以设置的相对小一点 |
|
datanode 平衡带宽 |
20M |
|
可以适当调高 |
|
datanode 的 Java 堆栈大小 |
4G |
8G |
|
|
JorunalNode 的 Java 堆栈大小 |
1G |
8G |
适当提升 Jorunal Node 堆栈大小。 |
2、参数调优
2.1、NameNode 数据目录
dfs.name.dir， dfs.namenode.name.dir
指定一个本地文件系统路径，决定 NN 在何处存放 fsimage 和 editlog 文件。可以通过逗号分隔指定多个路径. 目前我们的产线环境只配置了一个目录， 并存放在了做了 RAID1 或 RAID5 的磁盘上。
2.2、datanode 数据目录
dfs.data.dir， dfs.datanode.data.dir
指定 DN 存放块数据的本地盘路径，可以通过逗号分隔指定多个路径。在生产环境可能会在一个 DN 上挂多块盘。
2.3、数据块的副本数
dfs.replication
数据块的副本数，默认值为 3
2.4、数据块大小
dfs.block.size
HDFS 数据块的大小，默认为 128M，目前我们产线环境配置的是 1G
2.5、HDFS 做均衡时使用的最大带宽
dfs.datanode.balance.bandwidthPeRegionServerec
HDFS 做均衡时使用的最大带宽，默认为 1048576，即 1MB/s，对大多数千兆甚至万兆带宽的集群来说过小。不过该值可以在启动 balancer 脚本时再设置，可以不修改集群层面默认值。 目前目前我们产线环境设置的是50M/s~100M/s
2.6、磁盘可损坏数
dfs.datanode.failed.volumes.tolerated
DN 多少块盘损坏后停止服务，默认为 0，即一旦任何磁盘故障 DN 即关闭。 对盘较多的集群（例如每 DN12 块盘），磁盘故障是常态，通常可以将该值设置为 1 或 2，避免频繁有 DN 下线。
2.7、数据传输连接数
dfs.datanode.max.xcieveRegionServer
datanode 可以同时处理的数据传输连接数，即指定在 datanode 内外传输数据使用的最大线程数。 官方将该参数的命名改为dfs.datanode.max.transfer.threads，默认值为 4096，推荐值为 8192，我们产线环境也是 8192
2.8、NameNode 处理RPC 调用的线程数
dfs.namenode.handler.count
NameNode 中用于处理 RPC 调用的线程数，默认为 10。对于较大的集群和配置较好的服务器，可适当增加这个数值来提升 NameNode RPC 服务的并发度，该参数的建议值：集群的自然对数 * 20
python -c 'import math ; print int(math.log(N) * 20)' 我们 800+节点产线环境配置的是 200~500 之间。
2.9、NameNode 处理 datanode 上报数据块和心跳的线程数
dfs.namenode.service.handler.count
用于处理 datanode 上报数据块和心跳的线程数量，与dfs.namenode.handler.count 算法一致
2.10、datanode 处理 RPC 调用的线程数
dfs.datanode.handler.count
datanode 中用于处理 RPC 调用的线程数，默认为 3。可适当增加这个数值来提升 datanode RPC 服务的并发度，线程数的提高将增加 datanode 的内存需求，因此，不宜过度调整这个数值。我们产线环境设置的是 10
2.11、datanode最大传输线程数
dfs.datanode.max.xcieveRegionServer
最大传输线程数 指定在 datanode 内外传输数据使用的最大线程数。这个值是指定 datanode 可同時处理的最大文件数量，推荐将这个值调大，默认是 256，最大值可以配置为 65535，我们产线环境配置的是 8192。
2.12、读写数据时的缓存大小
io.file.buffer.size
设定在读写数据时的缓存大小，应该为硬件分页大小的 2 倍，我们产线环境设置的为 65536 （ 64K）
2.13、冗余数据块删除
在日常维护 hadoop 集群的过程中发现这样一种情况：
某个节点由于网络故障或者datanode 进程死亡，被NameNode 判定为死亡，
HDFS 马上自动开始数据块的容错拷贝；当该节点重新添加到集群中时，由于该节点上的数据其实并没有损坏，所以造成了 HDFS 上某些 block 的备份数超过了设定的备份数。通过观察发现，这些多余的数据块经过很长的一段时间才会被完全删除掉，那么这个时间取决于什么呢？
该时间的长短跟数据块报告的间隔时间有关。datanode 会定期将当前该结点上所有的 BLOCK 信息报告给 NameNode，参数
dfs.blockreport.intervalMsec 就是控制这个报告间隔的参数。hdfs-site.xml 文件中有一个参数：
<property>
<name>dfs.blockreport.intervalMsec</name>
<value>3600000</value>
<description>Determines block reporting interval in milliseconds.</description>
</property>
其中 3600000 为默认设置，3600000 毫秒，即 1 个小时，也就是说，块报告的时间间隔为 1 个小时，所以经过了很长时间这些多余的块才被删除掉。通过实际测试发现，当把该参数调整的稍小一点的时候（60 秒），多余的数据块确实很快就被删除了。
2.14、新增块延迟汇报
当 datanode 上新写完一个块，默认会立即汇报给 namenode。在一个大规模 Hadoop 集群上，每时每刻都在写数据，datanode 上随时都会有写完数据块然后汇报给 namenode 的情况。因此 namenode 会频繁处理 datanode 这种快汇报请求，会频繁地持有锁，其实非常影响其他 rpc 的处理和响应时间。通过延迟快汇报配置可以减少 datanode 写完块后的块汇报次数，提高
namenode 处理 rpc 的响应时间和处理速度。
<property>
<name>dfs.blockreport.incremental.intervalMsec</name>
<value>300</value>
</property>
我们产线环境 HDFS 集群上此参数配置为 500 毫秒，就是当 datanode 新写一个块，不是立即汇报给 namenode，而是要等待 500 毫秒，在此时间段内新写的块一次性汇报给 namenode。
2.15、增大同时打开的文件描述符和网络连接上限
使用 ulimit 命令将允许同时打开的文件描述符数目上限增大至一个合适的值。同时调整内核参数 net.core.somaxconn 网络连接数目至一个足够大的值。
补充：net.core.somaxconn 的作用
net.core.somaxconn 是 Linux 中的一个 kernel 参数，表示 socket 监听（listen）的 backlog 上限。什么是 backlog 呢？backlog 就是 socket 的监听队列，当一个请求（request）尚未被处理或建立时，它会进入 backlog。而 socket server 可以一次性处理 backlog 中的所有请求，处理后的请求不再位于监听队列中。当 server 处理请求较慢，以至于监听队列被填满后，新来的请求会被拒绝。在 Hadoop 1.0 中，参数 ipc.server.listen.queue.size 控制了服务端 socket 的监听队列长度，即 backlog 长度，默认值是 128。而 Linux 的参数 net.core.somaxconn 默认值同样为 128。当服务端繁忙时，如NameNode 或 JobTracker，128 是远远不够的。这样就需要增大 backlog， 例如我们的集群就将 ipc.server.listen.queue.size 设成了 32768，为了使得整个参数达到预期效果，同样需要将 kernel 参数 net.core.somaxconn 设成一个大于等于 32768 的值。
3、运维
3.1、运维命令
1.查看目录下的文件列表hdfs dfs -ls /ops 2.上传文件 hdfs dfs -put 1.txt /ops 3.文件被复制到本地系统中 hdfs dfs -get /ops/1.txt /data/work 4.删除文件或目录 hdfs dfs -rm /ops/1.txt hdfs dfs -rmr /ops 5.查看文件内容 hdfs dfs -cat /ops/1.txt 6.建立目录 hdfs dfs -mkdir -p /ops/20161201 7.fsck 1）查看目录的健康状态 hdfs fsck / 2）check 目录下的文件 hdfs fsck /ops -files 3）查看某个目录 block 以及监控情况 hdfs fsck /ops -files -blocks -locations 4）查看目录损坏的块 hdfs fsck / -list-corruptfileblocks
3.2、查看HDFS 基本统计
查看 HDFS 的基本统计信息
hdfs dfsadmin -report
3.3、主从切换
1.命令行操作
1）查看 namenode 主从状态
hdfs haadmin -getServiceState nn1
此处的 nn1 为在 hdfs-site.xml 中配置的 namenode 服务的名称
2) active 从 nn1 切 换 到 nn2
hdfs haadmin -failover nn1 nn2
2.CM 操作
3.4、安全模式
1.命令行操作
1）进入安全模式
在必要情况下，可以通过以下命令把 HDFS 置于安全模式
两个 NameNode 进入安全模式
hdfs dfsadmin -safemode enter
单个 NameNode 进入安全模式
hdfs dfsadmin -fs hdfs://hadoop3:8020 -safemode enter
2）退出安全模式
两个 NameNode 退出安全模式
hdfs dfsadmin -safemode leave
单个 NameNode 退出安全模式
hdfs dfsadmin -fs hdfs://hadoop3:8020 -safemode leave
3）查看状态
hdfs dfsadmin -safemode get
2.CM 操作
3.5、保存命名空间
3.5.1、首先进去安全模式不然报错
CM 上操作也报错：
3.5.2、保存命名空间
hdfs dfsadmin -saveNamespace
3.6、扩缩容
3.6.1、扩容
①选择 add hosts，添加主机到 CM
②添加 hadoop3
③添加 hadoop3 到 MyCluster 集群
④添加角色实例
⑤启动新增的 datanode
3.6.2、缩容
4、排障
4.1、meta 文件损坏导致datanode 进程无法启动
【现象】
xx集群的hadoop033节点主机重启后，datanode进程无法启动。
【查看日志】
在 datanode 的"角色日志详细信息"中发现数条关于无法读取.meta文件的报错：
【登录主机核实】
以第一条报错为例，我们进入到/data/hdfsdsk09/data/current/BP-1981380748-192.168.116.201-1398150807170/current/finalized/subdir48/subdir46/目录下，发现该条报错中提到的 meta 文件的属主、属组和权限等信息显示异常。
【原因】
hdfsdsk09 磁盘下的某几个 meta 文件损坏，导致 datanode 进程无法启动。
【解决方法】
修复 hdfsdsk09 磁盘
①以 sudo 权限取消 hdfsdsk09 的挂载命令：sudo umount /data/hdfsdsk09
②fsck 修复磁盘
命令：sudo fsck /data/hdfsdsk09
③启动 datanode
在 CM 页面启动 datanode。
如果磁盘无法通过 fsck 命令修复，就找主机侧，让他们用 root 用户格式化磁盘，然后我们按照坏盘故障来处理。
4.2、多个datanode 节点存储不足
【现象】
xx集群的多个 datanode 可用空间不足，并引发 CM 页面告警。
HDFS 页面显示所有 datanode 存储的标准差已达 11%（正常情况下是 5%）
【解决方案】
运行 Hadoop 自带的 balancer 程序，平衡 HDFS 中的各节点间的差距。在任意节点都可以启动 balancer，但是建议选择空闲（内存占用低）的节点。
【执行 balancer】
①在内存占用较低的 zchadoop002-1 上启动 balancer 脚本，将 HDFS 中所有节点的存储值中的最低值和平均值的差值设置为 5。
命令：start-balancer.sh -threshold 5
启动 balancer 后，在屏幕输出了 balancer 的日志路径。
②设置 balancer 所能占用的带宽
带宽的大小与负载均衡的速度成正比，但是速度过大可能会导致
map/reduce 运行缓慢，所以务必选择业务空闲时间段启动 balancer。默认的带宽为 1048576（1M/S）。由于 balancer 可以在中断后重新执行（类似于迅雷的断点续传），所以可以先设置一个较低的带宽，慢了的话，再一次次加速。此处设置为 2M/S。需要强调的是，balancer 每次设置的带宽是临时性的，第二次启动 balancer 时，要重新设置带宽。
命令：hdfs dfsadmin -setBalancerBandwidth 2000000
③查看进程
balancer 是一个 java 程序，可 jps 查看。
④查看 Balancer 的进展
除了通过 HDFS 页面中的存储变化来间接反映 balancer 的进展外，还可以通过日志来量化其进展。
命令：more /opt/boh-2.0.0/logs/hadoop/hadoop-hadoop-balancer-zchadoop002- 1.out
可以看到每次迁移中的待迁移数据 Bytes Left To Move 都在减少，说明balancer 在起作用。但为什么已完成的迁移量 Bytes Already Moved 一直是0 字节，还没搞清楚。
4.定时执行 balancer
因为 balancer 的速度由多方因素影响，我们不能保证当天的 balancer 在当天就能完成。又考虑到 balancer 有类似迅雷的“断点续传”特点，而且带宽在 balancer 中断后会失效，所以在每天的定时计划中的顺序是“停止昨天的 balancer→设置带宽（非必须）→启动今天的 balancer”。balancer 的运行时间段应当避开主机繁忙期。下图以xx集群的定时计划为例。
4.3、datanode 数据盘坏盘故障
以xx机房 hadoop056 出现坏盘为例
1.发现故障
目前发现数据坏盘的方式有两种，通过监控系统自动报警和在 CM 页面里肉眼观察。
自动报警：待定。
肉眼观察：在 HDFS 页面的 datanodes 目录 (http://132.35.xx.xx:5007 0/dfshealth.html#tab-datanode)里，观察 Failed Volumes 列的数值，若有非 0 值，则该值对应的 datanode 有坏盘。
2.停止 hadoop056 上的进程
以 Admin 身份登录 CM，进入 hadoop1-56 的进程页面，在右上方的“操作”里选择“停止主机上的角色”
3.通知硬件侧更换硬盘
4.换盘后的操作
①以 root 身份登录到 hadoop056 节点
②停止 cloudera-scm-agent
命令：/opt/cm-5.1.3/etc/init.d/cloudera-scm-agent stop
③返回 hadoop 用户，查看 datanode 进程是否已经停止
④切回 root，查看/data 目录，找到新换的盘。
属主和属组是 root 的磁盘就是被更换的新盘。
⑤在新换的磁盘目录 hdfsdsk01 下新建目录
在正常情况下，以 hdfsdsk02 为例，磁盘目录里应该有如下 5 个目录。
但是新加的磁盘是没有红框里的 4 个目录，需要我们手工创建。只创建第一级即可，它们下面的目录和文件会在 datanode 进程启动之后自动生成。
⑥修改新磁盘目录的属主和属组为 hadoop
命 令 ：chown -R hadoop:hadoop /data/hdfsdsk01
改变属组和属主之后的效果
⑦启动 cloudera-scm-agent
命令：/opt/cm-5.1.3/etc/init.d/cloudera-scm-agent start
⑧返回 hadoop 用户，检查 datanode 进程是否已经启动
⑨二次确认
检查新换的盘是否还有坏卷
命令：fsck -y /data/hdfsdsk01
若还存在坏盘，则通知二线 xx 处理
4.4、datanode 数据盘存储超过阈值
【现象】
收到告警短信，hadoop057 的第8块盘的存储率超过了 90%。
【确认】
在/data 目录下执行 df -h，报警属实
【检查HDFS存储】
由于 datanode 单块磁盘的存储过高，导致整个集群的 HDFS 存储超过了75%。
【处理】
反馈对应负责人进行数据清理
4.5、坏块处理
【现象】
查看 HDFS 页面出现如下图报错即为有坏块
【处理方法】
首先登陆 DN 节点，执行 hadoop fsck /命令，查看集群坏块的状况，以及坏块的路径
执行 hadoop fsck / -delete 命令删除坏块
删完后再次执行 hadoop fsck /命令，查看集群坏块的状况
执行hadoop fs -setrep -R 2 /user/hive/warehouse/zbg_dwa.db 修 改 表 的副本数，这里副本数为 2（注：升副本的时候只升删除坏块的那个小表即可，目录越小越好）
执行Hadoop fsck /user/hive/warehouse/zbg_dwa.db 查看副本数是否正确
4.6、datanode 宕机
【现象】
hadoop056 节点与cloudera manager失去联系时间过长。
【处理】
通知硬件侧该节点宕机，经硬件侧同事确认是由于此节点电源故障导致宕机，随后他将节点重启
【重启后配置】
①以 root 身份登录到 hadoop056 节点
②停止 ntp 服务
③与 hadoop211 上的 NTP Server 同步
命令：ntpdate hadoop211
④将时间写到主板
命令：hwclock -w
⑤启动 ntp 服务
⑥启动 cloudera-scm-agent
命令：/opt/cm-5.1.3/etc/init.d/cloudera-scm-agent start
⑦检查 datanode 进程是否已经启动
返回到 hadoop 用户，执行 jps 命令。
⑧登录CM，启动 hadoop056 节点上的角色。
如未解决，联系二线处理
4.7、hdfs 目录被删除排查
【问题】
XXX 告知 XXX 集群目录被删除，并提供了被删除目录，请求定位被谁删除
【问题排查】
HDFS 审计日志查看
2019-06-29 00:32:44，275 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/013 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/013perm=hdfs:ss_deploy:rwxrwxrwx proto=rpc
2019-06-29 00:40:55，525 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/011 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/011perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 00:41:20，228 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/017 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/017perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 00:54:54，697 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/031 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/031perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 01:03:05，264 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/018 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/018perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 01:08:24，077 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/034 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/034perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 01:10:29，977 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/038 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/038perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 01:13:28，904 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/036 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/036perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 01:31:42，517 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/051 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/051perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 01:34:22，650 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/075 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/075perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 01:36:09，417 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/071 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/071perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 01:40:21，424 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/076 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/076perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 01:51:24，962 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/079 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/079perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 01:51:58，956 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/083 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/083perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 02:00:20，934 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/081 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/081perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 02:09:09，425 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/086 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/086perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
2019-06-29 02:10:34，062 INFO FSNamesystem.audit: allowed=true ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2 src=/serv/smartsteps/raw/events/locationevent/2019/06/28/087 dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev ent/2019/06/28/087perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
4.8、MaxDirectoryItemsExceededException
【问题】
hdfs 目录存储最大文件数异常 MaxDirectoryItemsExceededException
1.org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.prot ocol.FSLimitException$MaxDirectoryItemsExceededException): The directory item limit of /XXX/XXX/FF is exceeded: limit=1048576 items=1048576
at org.apache.hadoop.hdfs.server.namenode.FSDirectory.verifyMaxDirIte ms(FSDirectory.java:2060)
at org.apache.hadoop.hdfs.server.namenode.FSDirectory.addChild(FSDire ctory.java:2112)
at org.apache.hadoop.hdfs.server.namenode.FSDirectory.addLastINode(F SDirectory.java:2081)
at org.apache.hadoop.hdfs.server.namenode.FSDirectory.addINode(FSDir ectory.java:1900)
at org.apache.hadoop.hdfs.server.namenode.FSDirectory.addFile(FSDirect ory.java:327)
at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startFileInter nal(FSNamesystem.java:2794)
【问题处理】
更改 hdfs-site.xml 添加如下
<property> <name>dfs.namenode.fs-limits.max-directory-items</name> <value>1048576</value> <description>Defines the maximum number of items that a directory may than contain. Cannot set the property to a value less than 1 or more 6400000.</description> </property>
把这个配置添加到 hdfs-site.xml 中，把值设置为大一些，问题搞定。不过在此也存在一个问题，这个 HDFS 的限制有个范围，最多不能超过6400000，因此后续还要考虑到历史数据的删除。