FreeBSD下安裝配置Hadoop叢集(效能調優)

weixin_34219944發表於2012-04-01
Hadoop
hadoop的效能調優是個比較艱難的事情，由於這個系統的整個環境比較複雜，對於接觸時間不長的人來說，配置都很難，更別說找出效能優化的點了。

效能優化涉及的方面很廣，作業系統，網路配置，配置檔案，排程器等等，抓出幾點來說，但不敢說這幾點就是別人所遇到的效能瓶頸，拋磚引玉而已。應用場景不同，優化配置肯定是各不相同的。

對於作業系統和網路環境的調優，這個需要講的東西就太多了，無法在一篇文章裡贅述。集中於幾個關鍵詞：sysctl，ulimit，hosts檔案，內網配置。

儘量把hadoop叢集配置在內網地址上，這就不用多說了吧。

下面主要探討hadoop的配置檔案和排程器的選擇和開發。

以我公司的hadoop叢集舉例來說，主要是用了資料壓縮和索引和對排程器策略的優化。

使用壓縮是一個不錯的選擇，比如我們自己的叢集用的是LZO的壓縮方式，壓縮比大概是原始資料的1/3，也就是說，1G的原始日誌大概能壓縮成300Mb左右，一方面壓縮比不錯，另一方面，讀取速度也很不錯，配合的是Native的lzo庫。一個叫hadoop-gpl的東西。前一陣子泰國水災，硬碟難買，以壓縮的方式也可以多撐一陣子。

如果給lzo建立索引，效果就更好了

當然你需要先安裝hadoopgpl。
core-site.xml
<property>
                <name>io.compression.codecs</name>
                <value>org.apache.hadoop.io.compress.DefaultCodec,com.hadoop.compression.lzo.LzoCodec,com.hadoop.compression.lzo.LzopCodec,org.apache.hadoop.io.compress.GzipCodec,org.apache
.hadoop.io.compress.BZip2Codec</value>
        </property>
        <property>
                <name>io.compression.codec.lzo.class</name>
                <value>com.hadoop.compression.lzo.LzoCodec</value>
        </property>

mapred-site.xml
<property>
                <name>mapred.compress.map.output</name>
                <value>true</value>
        </property>
        <property>
                <name>mapred.map.output.compression.codec</name>
                <value>com.hadoop.compression.lzo.LzoCodec</value>
        </property>
        <property>
                <name>mapred.child.java.opts</name>
                <value>-Djava.library.path=/opt/hadoopgpl/native/Linux-amd64-64</value>
        </property>

當然每臺伺服器都需要定義這個才可以。

還有一個很重要的優化是槽位的設定和排程器的選擇，這個直接關係到hadoop的計算能力。相同硬體情況下，配置好的叢集的在計算相同任務的情況下，要比配置糟糕的叢集快幾倍乃至幾十倍。

對於map/reduce槽位的配置還有job對java虛擬機器的配置，我目前總結的規律大概是這樣，namenode的槽位總數相加和等於CPU數量，同時map槽位數大概是reduce槽位的3倍，也就是這樣，如果你有一個8核的伺服器，map數量就應該是6，reduce數量是2。對於datanode，我們需要他的計算能力強一些，就把map和reduce槽位總和設定成cpu數量的2倍，同時map數是reduce數量的3倍，同樣是8核的datanode，map數就是12，reduce數就是4。對於記憶體的使用，還是拿配置檔案舉例說明吧。

mapred-site on namenode：
<property>
        <name>mapred.tasktracker.map.tasks.maximum</name>
        <value>6</value>
        <final>true</final>
    </property>
    <property>
        <name>mapred.tasktracker.reduce.tasks.maximum</name>
        <value>2</value>
        <final>true</final>
    </property>
    <property>
        <name>mapred.child.java.opts</name>
        <value>-Xmx1536M</value>
    </property>

mapred-site on datanode:
<property>
        <name>mapred.tasktracker.map.tasks.maximum</name>
        <value>12</value>
        <final>true</final>
    </property>
    <property>
        <name>mapred.tasktracker.reduce.tasks.maximum</name>
        <value>4</value>
        <final>true</final>
    </property>
    <property>
        <name>mapred.map.child.java.opts</name>
        <value>-Xmx1224M</value>
    </property>
    <property>
        <name>mapred.reduce.child.java.opts</name>
        <value>-Xmx2048M</value>
    </property>

對於map槽位的記憶體佔用，我的理解是這樣，記憶體總數/CPU核數/4，上下可以浮動幾百兆。
對於reduce槽位是記憶體總數/cpu核數/2。

然後簡單說下排程器的問題，hadoop預設的排程器是FIFO，就是先入先出，通常來說，這就比較夠用了。但是如果叢集規模較小，計算任務又比較多，還需要細分不同任務的槽位分配，就還是配置其他的排程器比較好。

常用的有兩種第三方排程器，yahoo開發的Capacity Scheduler和Facebook貢獻的Fair Scheduler。翻譯過來叫計算能力排程器和公平排程器，可能大家聽公平排程器聽的比較多，不過目前我們公司主要是用計算能力排程器。

因為配置的XML太長，我就不貼了，需要了解計算能力排程器的配置方法，可以訪問我的同事老趙的技術部落格。


在我們的應用場景裡，計算能力被分為了3類，每個分類的map/reudce槽位數是不同的，根據統計平時的計算量來固定分配的槽位數。default，rush，和hive，其中普通的streaming的計算方式放入default的分類中執行，日誌清洗和入庫單獨使用rush分類，hive，顧名思義，就是給hive資料庫單獨使用的。這個分配的map/reduce是最多的。平時定時任務的70%左右都是用hive跑的，臨時資料查詢95%依賴hive。

這樣做的好處是計算任務的計算能力被隔離，互不干擾。可根據業務需求進行分類。避免任務搶佔造成的資源大量消耗。

相關文章