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，因此后續還要考慮到歷史數據的刪除。