前言
昨天還是周末，公司群里就有人@，說集群有問題了，敲完Hive一直卡在那里進不去，於是我很快登上WebUi，看到了這么一幕：
這台節點的磁盤滿了，其他的數據分布都比較平均
為什么會這樣
這里就不得不說一下HDFS復本存放策略了：
namenode如何選擇在哪個datanode存儲復本（replica）？這里需要針對可靠性、寫入帶寬和讀取帶寬進行權衡。例如，把所有復本都存儲在一個節點損失的寫入帶寬最小（因為復制管線都是在同一節點上運行），但這並不提供真實的冗余（如果節點發生故障，那么該塊中的數據會丟失）。同時，同一機架上服務器間的讀取帶寬是很高的。另一個極端，把復本放在不同的數據中心可以最大限度地提高冗余，但帶寬的損耗非常大。及時在同一數據中心（到目前為止，所有Hadoop集群均運行在同一數據中心內），也有多重可能的數據布局策略。
Hadoop的默認布局策略是在運行客戶端的節點上放第1個復本（如果客戶端運行在集群之外，就隨機選擇一個節點，不過系統會避免挑選那些存儲太滿或太忙的節點）。第2個復本放在與第一個不同且隨機另外選擇的機架中節點上（離架）。第3個復本與第2個復本放在同一個機架上，且隨機選擇另外一個節點。其他復本放在集群中隨機選擇的節點上，不過系統會盡量避免在同一個的機架上放太多復本。
一旦選定復本的放置位置，就根據網絡拓撲創建一個管線。如果復本數為3，則有下圖所示的管線：
總結：
- 第一個副本：放置在上傳文件的 DN；如果是集群外提交，則隨機挑選一台磁盤不太
滿，CPU 不太忙的節點。 - 第二個副本：放置在於第一個副本不同的機架的節點上。
- 第三個副本：與第二個副本相同機架的節點。
- 更多副本：隨機節點。
總的來說，這一方法不僅提供很好的穩定性（數據塊存儲在兩個機架中）並實現很好的負載均衡，包括寫入帶寬（寫入操作只需要遍歷一個交換機）、讀取性能（可以從兩個機架中選擇讀取）和集群中塊的均勻分布（客戶端只在本地機架上寫入一個塊）
看到HDFS復本存放策略，問題就很明了了：該節點既是HDFS的客戶端又是一個DataNode節點，因此每次往HDFS寫入數據它都會存放一份
這樣的好處，是寫入的效率高，但是壞處就是會出現上面的問題
怎么解決
這個時候就不得不說HDFS的均衡器：
隨着時間推移，各個datanode上的塊分布會越來越不均衡。不均衡的集群會降低MapReduce的本地性，導致部分datanode相對更加繁忙。應避免出現這種情況。
均衡器（balancer）程序是一個Hadoop守護進程，它將塊從忙綠的datanode移到相對空閑的datanode，從而重新分配塊。同時堅持塊復本放置策略，將復本分散到不同機架，以降低數據損壞率。它不斷移動塊，直到集群達到均衡，即每個datanode的使用率（該節點上已使用的空間與空間容量之間的比率）和集群的使用率（集群中已使用的空間與集群的空間容量之間的比率）非常接近，差距不超過給定的閾值。可調用下面指令啟動均衡器：% start-balancer.sh
- 1
- threshold 參數指定閾值（百分比格式），以判定集群是否均衡。該標記是可選的；若省略，默認閾值是10%。任何時刻，集群中都只運行一個均衡器。
均衡器會一直運行，直到集群變得均衡為止，此時，均衡器不能移動任何塊，或失去與namenode的聯絡。均衡器在標准日志目錄中創建一個日志文件，記錄它所執行的每輪重新分配的過程（每輪次輸出一行）。
為了降低集群負荷、避免干擾其他用戶，均衡器被設計為后台運行。在不同節點之間復制數據的寬帶也是受限的。默認值是很小的1MB/s，可以通過hdfs-site.xml文件中的dfs.datanode.balance.bandwidthPerSec屬性重新設定（單位是字節）
於是我在CDH WebUi上面進行如下操作：
平衡器啟動6h后：（我這個效率太低了，可以繼續增加dfs.datanode.balance.bandwidthPerSec屬性）
這個時候集群就可以使用了。現在這個節點和其他節點在HDFS上面的存儲的數據已經平衡了，我們可以到當時配置的dfs.datanode.data.dir的路徑下查看每個節點在HDFS存儲的量，比如我的這個路徑是/data/dfs切換到該目錄，然后：
du -h --max-depth=1
- 1
進行統計，我這里簡單的進行了匯總：
可以看得出來我的threshold值現在也僅僅為0.02，這個值也是我設置的值。
不過，這樣真的不如單獨拿一台服務器作為客戶端
如何給HDFS增加客戶端
原生搭建的集群：
1、找一台新的虛擬機、服務器、。這台服務器必須能夠與集群通信（與其余節點ping通）
2、將配置好的安裝包原封不動的拷貝到新的服務器
3、配置環境變量 方便操作HDFS集群
4、在客戶端正常操作HDFS集群就可以了
CDH搭建的集群：