挺喜歡這句話：“堅持，是基於 你對某件事的熱愛，纔能有動力堅持下去。
在學習的過程中，需要戰勝自己的惰性和驕傲！”好了，下面說下如何提升
集羣的性能：
在硬件方面，第一，商業硬件並不等同於低端硬件。低端機器常常使用
便宜的零部件，其故障率遠高於更昂貴的機器。當用戶管理幾十臺、上百臺
甚至幾千臺機器時，便宜的零部件故障率更高，導致維護成本更高；第二，
不推薦使用大型數據庫級別的機器，因爲性價比太低了。
在相同硬件的情況下，一個配置好的的集羣要比配置糟糕的集羣在性能上
快數倍乃至數十倍。
首先說下對於map/reduce槽位的配置還有job對java虛擬機的配置，一般
情況下，如果NN爲8核的服務器，map的數量應該配置爲6，reduce的數量爲2，
也就是說，NN的槽位總數相加和等於CPU的數量，同時map槽位數大概是reduce
槽位數的三倍；因爲我們需要DN的計算能力強一些，因此，在服務器相同配置
的條件下，可以把map/reduce的槽位總和設置爲CPU數量的2倍，同時map數是
reduce數量的3倍。
Hadoop性能優化：Hadoop機架感知實現及配置：分佈式的集羣通常包含非常多的機器，由於受到機架槽位和交換機網口的限制，通常大型的分佈式集羣都會跨好幾個機架，由多個機架上的機器共同組成一個分佈式集羣。機架內的機器之間的網絡速度通常都會高於跨機架機器之間的網絡速度，並且機架之間機器的網絡通信通常受到上層交換機間網絡帶寬的限制。
具體到Hadoop集羣，由於Hadoop的HDFS對數據文件的分佈式存放是按照分塊block存儲，每個block會有多個副本(默認爲3)，並且爲了數據的安全和高效，所以Hadoop默認對3個副本的存放策略爲：
1.在本地機器的hdfs目錄下存儲一個block ；
2.在另外一個rack的某個datanode上存儲一個block ；
3.在該機器的同一個rack下的某臺機器上存儲最後一個block ；
這樣的策略可以保證對該block所屬文件的訪問能夠優先在本rack下找到，如果整個rack發生了異常，也可以在另外的rack上找到該block的副本。這樣足夠的高效，並且同時做到了數據的容錯。但是，Hadoop對機架的感知並非是自適應的，亦即，Hadoop集羣分辨某臺slave機器是屬於哪個rack並非是只能的感知的，而是需要Hadoop的管理者人爲的告知Hadoop哪臺機器屬於哪個rack，這樣在Hadoop的namenode啓動初始化時，會將這些機器與rack的對應信息保存在內存中，用來作爲對接下來所有的HDFS的寫塊操作分配datanode列表時（比如3個block對應三臺datanode）的選擇datanode策略，做到Hadoop allocate block的策略：儘量將三個副本分佈到不同的rack。接下來的問題就是：通過什麼方式能夠告知Hadoop namenode哪些slaves機器屬於哪個rack？以下是配置步驟。
默認情況下，Hadoop的機架感知是沒有被啓用的。所以，在通常情況下，Hadoop集羣的HDFS在選機器的時候，是隨機選擇的，也就是說，很有可能在寫數據時，Hadoop將第一塊數據block1寫到了rack1上，然後隨機的選擇下將block2寫入到了rack2下，此時兩個rack之間產生了數據傳輸的流量，再接下來，在隨機的情況下，又將block3重新又寫回了rack1，此時，兩個rack之間又產生了一次數據流量。在job處理的數據量非常的大，或者往Hadoop推送的數據量非常大的時候，這種情況會造成rack之間的網絡流量成倍的上升，成爲性能的瓶頸，進而影響作業的性能以至於整個集羣的服務。要將Hadoop機架感知的功能啓用，配置非常簡單，在namenode所在機器的Hadoop-site.xml配置文件中配置一個選項：topology.script.file.name。這個配置選項的value指定爲一個可執行程序，通常爲一個腳本，該腳本接受一個參數，輸出一個值。接受的參數通常爲某臺datanode機器的ip地址，而輸出的值通常爲該ip地址對應的datanode所在的rack，例如”/rack1”。Namenode啓動時，會判斷該配置選項是否爲空，如果非空，則表示已經用機架感知的配置，此時namenode會根據配置尋找該腳本，並在接收到每一個datanode的heartbeat時，將該datanode的ip地址作爲參數傳給該腳本運行，並將得到的輸出作爲該datanode所屬的機架，保存到內存的一個map中。至於腳本的編寫，就需要將真實的網絡拓樸和機架信息瞭解清楚後，通過該腳本能夠將機器的ip地址正確的映射到相應的機架上去。一個簡單的實現如下：
#!/usr/bin/perl -w
use strict;
my $ip = $ARGV[0];
my $rack_num = 3;
my @ip_items = split /\./, $ip;
my $ip_count = 0;
foreach my $i (@ip_items) {
$ip_count += $i;
}
my $rack = "/rack".($ip_count % $rack_num);
print "$rack";
寫入數據
當沒有配置機架信息時，所有的機器Hadoop都默認在同一個默認的機架下，名爲 “/default-rack”，這種情況下，任何一臺datanode機器，不管物理上是否屬於同一個機架，都會被認爲是在同一個機架下，此時，就很容易出現之前提到的增添機架間網絡負載的情況。例如，對沒有機架信息的Hadoop HDFS啓動instance上傳一個文件，其block信息如下：
在沒有機架信息的情況下，namenode默認將所有的slaves機器全部默認爲在/default-rack下，根據Hadoop代碼的分析也能知道哦啊，此時在寫block時，三個datanode機器的選擇完全是隨機的。而當配置了機架感知信息以後，Hadoop在選擇三個datanode時，就會進行相應的判斷：
1.如果上傳本機不是一個datanode，而是一個客戶端，那麼就從所有slave機器中隨機選擇一臺datanode作爲第一個塊的寫入機器(datanode1)。而此時如果上傳機器本身就是一個datanode（例如mapreduce作業中task通過DFSClient向hdfs寫入數據的時候），那麼就將該datanode本身作爲第一個塊寫入機器(datanode1)。
2.隨後在datanode1所屬的機架以外的另外的機架上，隨機的選擇一臺，作爲第二個block的寫入datanode機器(datanode2)。
3.在寫第三個block前，先判斷是否前兩個datanode是否是在同一個機架上，如果是在同一個機架，那麼就嘗試在另外一個機架上選擇第三個datanode作爲寫入機器(datanode3)。而如果datanode1和datanode2沒有在同一個機架上，則在datanode2所在的機架上選擇一臺datanode作爲datanode3。
4.得到3個datanode的列表以後，從namenode返回該列表到DFSClient之前，會在namenode端首先根據該寫入客戶端跟datanode列表中每個datanode之間的“距離”由近到遠進行一個排序。如果此時DFS寫入端不是datanode，則選擇datanode列表中的第一個排在第一位。客戶端根據這個順序有近到遠的進行數據塊的寫入。在此，判斷兩個datanode之間“距離”的算法就比較關鍵，Hadoop目前實現如下，以兩個表示datanode的對象DatanodeInfo(node1,node2)爲例:
a)首先根據node1和node2對象分別得出兩個datanode在整個hdfs集羣中所處的層次。這裏的層次概念需要解釋一下：每個datanode在hdfs集羣中所處的層次結構字符串是這樣描述的，假設hdfs的拓撲結構如下：每個datanode都會對應自己在集羣中的位置和層次，如node1的位置信息爲“/rack1/datanode1”,那麼它所處的層次就爲2，其餘類推。
b)得到兩個node的層次後，會沿着每個node所處的拓樸樹中的位置向上查找，如“/rack1/datanode1”的上一級就是“/rack1”，此時兩個節點之間的距離加1，兩個node分別同上向上查找，直到找到共同的祖先節點位置，此時所得的距離數就用來代表兩個節點之間的距離。所以，如上圖所示，node1和node2之間的距離就爲4.
5.當根據“距離”排好序的datanode節點列表返回給DFSClient以後，DFSClient便會創建Block OutputStream，並想這次block寫入pipeline中的第一個節點（最近的節點）開始寫入block數據。
6.寫完第一個block以後，依次按照datanode列表中的次遠的node進行寫入，直到最後一個block寫入成功，DFSClient返回成功，該block寫入操作結束。
通過以上策略，namenode在選擇數據塊的寫入datanode列表時，就充分考慮到了將block副本分散在不同機架下，並同時儘量的避免了之前描述的網絡多於開銷。對配置了機架信息的Hadoop HDFS啓動instance上傳一個文件，其block信息如下：在配置了機架信息的情況下，爲了減少機架間的網絡流量，namenode會將其中兩個副本寫在同一個機架上，並且爲了儘量做到容錯，會將第三個block寫道另一個機架上的datanode上