第9章-構建Hadoop集羣-筆記

控制腳本

Hadoop內置一些腳原本運行指令，在集羣內啓動和終止守護進程。

這些腳本存放在bin目錄中，經過masters和slaves文件指定集羣內的全部機器。

一、masters文件，主要記錄運行輔助namenode的全部機器

masters文件有點誤導人。

它主要記錄擬運行輔助namenode（secondarynamenode）的全部機器。

二、slaves文件，主要記錄運行datanode和tasktracker的全部機器

slaves文件記錄了運行datanode和tasktracker的全部機器。

masters和slaves文件存放在配置目錄中。

用戶也能夠改變hadoop-env.sh的HADOOP_SLAVES項的值，將slaves文件放在其餘地方（也能夠改變文件名稱）。

三、start-dfs.sh腳本運行時詳細步驟

例如：start-dfs.sh腳本用於啓動集羣中全部的HDFS守護進程，可是該腳本運行時會在同一機器上運行namenode。

1）、在本地機器上啓動一個namenode（腳本所運行的機器）

2）、在slaves文件中記錄的各機器上啓動一個datanode。

3）、在masters文件中記錄的各機器上啓動一個輔助namenode。

四、start-mapred.sh腳本運行時詳細步驟

腳本start-mapred和start-dfs.sh相似，它啓動集羣中的全部MapReduce守護進程。

1）、在本地機器上啓動一個jobtracker。

2）、在slaves文件列舉的每臺機器上啓動一個tasktracker。

注意：

MapReduce控制腳本不使用masters文件。

此外，stop-dfs.sh和stop-mapred.sh腳本能終止由相關啓動腳本啓動的守護進程。

上述三、4腳本調用hadoop-daemon.sh腳原本啓動和終止hadoop守護進程。

若是已經使用前述三、4腳本，則不宜直接調用hadoop-daemon.sh。

可是若是用戶須要從其餘系統(或利用本身編寫的腳本)控制hadoop守護進程。則能夠調用hadoop-daemon.sh。

相似的，hadoop-daemons.sh（多了一個「s」）用於在多個主機上啓動同一個守護進程。

控制腳本相關知識點

一、集羣內的全部機器經過什麼文件指定？

經過masters和slaves文件。

二、hadoop-env.sh的HADOOP_SLAVES項的值用於指定salves文件的存放地址。

三、slaves和masters文件無需分發到各個工做節點

由於只有運行在namenode和jobtracker上的控制腳本能使用這些文件。

MapReduce控制腳本不使用masters文件。

四、哪一個文件指定運行namenode和jobtracker的機器？

運行namenode和jobtracker的機器由運行腳本的機器決定。它不禁masters文件指定。

五、由masters文件指定的機器會做爲何節點？

實際上，在masters文件指定機器，會致使這些機器上運行一個輔助namenode。

主節點場景

因爲集羣規模差別大，對於主節點守護進程的配置也差別很大。

主節點守護進程：namenode、輔助namenode、jobtracker

一、jobtracker最好運行在一個專用節點上

在一個運行大量MapReduce做業的高負載集羣上，jobtracker會使用大量內存和CPU資源，所以最好運行在一個專用節點上。

二、無論主守護進程運行在一個仍是多個節點上，如下規則均適用

1）、在namenode機器上運行HDFS控制腳本。

2）、masters文件包含輔助namenode的地址。

3）、在jobtracker機器上運行MapReduce控制腳本。

當namenode和jobtracker運行在不一樣節點之上時，集羣中的各節點將運行一個datanode和一個tasktracker，以使slaves文件同步。

主節點場景相關知識點

一、namanode節點主要保存什麼信息？

namenode在內存中保存整個命令空間的全部文件和塊元數據，它的內存需求很大。

namenode會在內存中存儲全部文件的每一個數據塊的引用，所以namnode極可能會「吃光」分配給它的全部內存。對於這種狀況，咱們能夠不改變其餘hadoop守護進程的內存分配量而只增長namenode的內存分配量。即：設置hadoop-env.sh文件的HADOOP_NAMENODE_OPTS，包含一個JVM選項以設定內存大小。HADOOP_NAMENODE_OPTS容許向namenode的JVM傳遞額外選項。

二、輔助節點secondarynamenode主要保存什麼信息？

輔助namenode保存一份最新的檢查點，記錄文件系統的元數據。

將這些歷史信息備份到其它節點上，有助於在數據丟失（或系統崩潰）狀況下恢復namenode的元數據文件。

輔助namenode在大多數時間是空閒，可是它在建立檢查時的內存需求與主namenode差很少。

一旦文件系統包含大量文件，單臺機器的物理內存便沒法同時運行主namenode和輔助namenode。

三、hadoop中哪些是主節點守護進程

namenode、輔助namenode、jobtracker

系統日誌文件

一、建議修改Hadoop系統日誌文件默認設置，使之獨立於Hadoop的安裝目錄

默認狀況下，Hadoop生成的系統日誌文件存放在$HADOOP_INSTALL/logs目錄之中，也能夠經過hadoop-env.sh文件中的HADOOP_LOG_DIR來進行修改。

二、爲何建議修改Hadoop系統日誌文件存放目錄獨立於Hadoop的安裝目錄

修改默認配置，使之獨立於Hadoop的安裝目錄。這樣，即便Hadoop升級以後安裝路徑發生改變，也不會影響日誌文件的位置。

一般能夠將日誌文件存放在/var/log/hadoop目錄中。

實現方法：在hadoop-env.sh中加入如下一行，export HADOOP_LOG_DIR=/var/log/hadoop

三、各個hadoop守護進程均會產生兩類日誌文件

1）、經過log4j記錄的——以.log做爲後綴名

由於大部分應用程序的日誌消息都寫到該日誌文件中，因此在對問題進行故障診斷時須要先查看這個文件。

標準的hadoop log4j配置採用平常滾動文件後綴策略(Daily Rolling File Appender)來命名日誌文件。

系統不會自動刪除過時的日誌文件，而是留待用戶按期刪除或存檔，以節約本地磁盤空間。

2）、記錄標準輸出和標準錯誤日誌——日誌文件後綴名爲.out

因爲hadoop使用log4j記錄日誌，因此這個文件一般只包含少許記錄，甚至爲空。

重啓守護進程時，系統會建立一個新文件來記錄此類日誌。系統僅保留最新的5個日誌文件。舊的日誌文件會附加一個數字後綴，值在1和5之間，5表示最舊的文件。

日誌文件名稱中的「用戶名稱」部分實際對應hadoop-env.sh文件中的HADOOP_IDENT_STRING項。

SSH設置

一、利用rsync工具，Hadoop控制腳本可以將配置文件分發到集羣中的全部節點。

默認狀況下，該功能並未啓用。

爲了啓用該功能，須要在hadoop-env.sh文件中定義HADOOP_MESTER項。

工做節點的守護進程啓動以後，會把以HADOOP_MASTER爲根的目錄樹與本地的HADOOP_ISNTALL目錄同步（？？？未理解如何運用？！）

二、如何確保每一個工做節點的hadoop-env.sh文件已經設置好HADOOP_MASTER?

對於小型集羣來講很容易解決：

編寫一個腳本文件，將主節點的hadoop-env.sh文件拷貝到全部工做節點便可。

對於大型集羣來講：

能夠採用相似dsh的工具，並行拷貝文件。

此外，還能夠編寫hadoop-env.sh文件，添加以上內容，並將這個文件做爲自動安裝腳本的一部分

三、在一個大型集羣中，集羣全部節點同時向主節點發出rsync請求，會致使主節點癱瘓，這種狀況如何避免？

爲了不發生這種狀況，須要將HADOOP_SLAVE_SLEEP項設爲一小段時間，例如0.1（表示0.1秒鐘）。

這樣的話，主節點會在相繼調用兩個工做節點的指令的間隙主動休眠一段時間間隔。

HDFS

HDFS配置文件，各配置選項的做用（HDFS守護進程的關鍵屬性）

一、dfs.name.dir

dfs.name.dir：描述一系列目錄，來供namenode存儲永久性的文件系統元數據

namenode存儲永久性的元數據的目錄列表。namenode在列表上的各個目錄中均存放相同的元數據文件。

文件系統元數據：包括編輯日誌（edits）和文件系統映像(image)

這些元數據會同時備份在全部指定的目錄中。

dfs.name.dir描述一系列目錄，其目的是支持冗餘備份。

二、dfs.data.dir

dfs.data.dir：雖然dfs.data.dir也描述了一系列目錄，可是其目的是循環地在各個目錄中寫數據。

datanode存放數據塊的目錄列表。各個數據塊分別存放於某一個目錄中。

所以，爲了提升性能，最好分別爲各個本地磁盤指定一個存儲目錄。

這樣一來，數據塊跨磁盤分佈，針對不一樣數據塊的讀操做能夠併發執行，從而提高性能。

三、fs.checkpoint.dir

指定一系列目錄來保存檢查點。

與namenode相似，檢查點映像文件會分別存儲在各個目錄中，以支持輔助namenode的冗餘備份。

輔助namenode存放檢查點的目錄列表。在所列的各個目錄中分別存放一份檢查點文件的副本。

HDFS相關知識點

一、默認狀況下HDFS的存儲目錄放在哪兒？

默認狀況下，HDFS的存儲目錄放在Hadoop的臨時目錄之中（即hadoop.tmp.dir屬性，默認值是/tmp/hadoop-${user.name}）

二、元數據文件保存在哪兒？

dfs.name.dir是用於配置元數據文件的。它描述一系列目錄，其目的是支持冗餘備份。

元數據文件會同時備份在全部由dfs.name.dir指定的一系列目錄中。

一般狀況下，配置dfs.name.dir將namenode的元數據寫到一個（或兩個）本地磁盤和一個遠程磁盤（例如NFS掛載的目錄）之中。

這樣的話，即便本地磁盤發生故障，甚至整個namenode發生故障，均可以恢復元數據文件，而且重構新的namenode。

三、輔助namenode只是按期保存datanode的檢查點，不提供namenode的最新備份。

四、dfs.name.dir和dfs.data.dir描述的一系列目錄，他們的目的同樣嗎？

dfs.name.dir和dfs.data.dir都描述了一系列目錄，可是他們的目的是不同的。

dfs.name.dir描述的一系列目錄，其目的是支持冗餘備份。

dfs.data.dir描述的一系列目錄，其目的是循環地在各個目錄中寫數據。

MapReduce

MapReduce配置文件，各配置選項的做用（MapReduce守護進程的關鍵屬性）

mapred.job.tracker

指定jobtracker的主機名或IP地址，以及它在監聽的端口。並不是URI格式，而是「主機：端口」格式。一般狀況下，端口號被設爲8021。

此屬性表示，jobtracker的RPC服務器所在的主機名稱和端口號。

mapred.local.dir

存儲做業中間數據的一個目錄列表。做業終止時，數據被清除。

默認值爲：${hadoop.tmp.dir}/mapred/local

此屬性使用一個逗號分隔的目錄名稱列表，最好將這些目錄分散到全部本地磁盤，以提高磁盤I/O效率。

一般狀況下，會使用與datanode相同的磁盤和分區（可是不一樣的目錄）存儲MapReduce的臨時數據。

datanode的數據塊存儲目錄由dfs.data.dir屬性項指定。

mapred.system.dir

MapReduce使用分佈式文件系統來和運行MapReduce任務的各個tasktracker共享文件。

在做業運行期間存儲共享文件的目錄，可使針對默認文件系統的相對路徑。（默認系統由fs.default.name屬性設定，通常爲HDFS）

mapred.system.dir指定這些文件的存儲目錄，能夠是針對默認文件系統的相對路徑。

默認文件系統由fs.default.name屬性設定，通常爲HDFS。

mapred.tasktracker.map.tasks.maximum和mapred.tasktracker.reduce.tasks.maximum

此屬性表示tasktracker機器上有多少核是可用的。

在任一時刻，運行在tasktracker之上的map/reduce任務的最大數。默認值爲2。

mapred.child.java.opts

此屬性表示tasktracker子JVM的有效內存大小

JVM選項，用於啓動運行map和reduce任務的tasktracker子進程。

該屬性能夠針對每一個做業進行設置。例如，能夠設置JVM的屬性，以支持調試。

MapReduce相關知識點

一、在執行MapReduce做業的過程當中所產生的中間數據和工做文件保存在哪兒？

被寫到臨時本地文件中。

二、爲何要保證本地臨時存儲空間的容量足夠大？

由於執行MapReduce做業的過程當中所產生的中間數據和工做文件，包括map任務的輸出數據，數據量可能很是大。所以必須保證本地臨時存儲空間（有mapred.local.dir屬性設置）的容量足夠大。

Hadoop的其餘屬性

集羣成員

dfs.hosts

該屬性記錄即將做爲datanode加入集羣機器列表。

mapred.hosts

該屬性記錄即將做爲tasktracker加入集羣的機器列表。

dfs.hosts.exclude和mapred.hosts.exclude

該屬性記錄待移除的機器列表。

更多關於移除委任機器的介紹詳見筆記中的「解除委任節點」：《第十章-管理Hadoop-筆記》

緩衝區大小

io.file.buffer.size

配置緩衝區大小（core-site.xml）

增大緩衝區容量會顯著提升性能。經常使用大小配置爲64KB或128KB。默認大小爲4KB。

HDFS塊大小

dfs.block.size

設置HDFS塊大小（hdfs-site.xml）

經過增大集羣塊大小，下降namenode的內存壓力，並向mapper傳輸更多數據。

默認大小爲64MB，許多集羣把塊大小設爲128MB或256MB。

一、默認狀況下，HDFS塊大小是64MB

默認狀況下，HDFS塊大小是64MB。可是，許多集羣把塊大小設爲128MB（134 217 728字節）或256MB（268 435 456字節）以下降namenode的內存壓力，並向mapper傳輸更多數據。

二、HDFS塊大小可經過hdfs-site.xml中的dfs.block.size屬性項設置塊大小。

保留的存儲空間

默認狀況下，datanode可以使用存儲目錄上的全部閒置空間，這可能致使沒有空間可供其餘應用程序使用。

若是計劃將部分空間留給其餘應用程序（非HDFS），則須要設置dfs.datanode.du.reserved屬性項來指定待保留的空間大小（以字節爲單位）。

dfs.datanode.du.reserved

指定待保留的空間大小（以字節爲單位）

回收站

一、Hadoop文件系統有回收站設施。

被刪除的文件並未被真正刪除，僅只轉移到回收站（一個特定文件夾）中。

回收站中的文件在被永久刪除以前仍會至少保留一段時間。

該信息由core-site.xml文件中的fs.trash.interval屬性項（以分鐘爲單位）設置。默認狀況下，該屬性項的值是0，表示回收站特性無效。

二、回收站特性被啓用時，每一個用戶都有獨立的回收站目錄

回收站特性被啓用時，每一個用戶都有獨立的回收站目錄，即：home目錄下的.Trash目錄。

fs.trash.interval

core-site.xml文件中配置，配置回收站文件保留時間（以分鐘爲單位）。默認狀況下，該屬性項的值是0，表示回收站特性無效。

三、HDFS會自動刪除回收站中的文件，可是其餘文件系統並不具有這項功能

對於這些不自動刪除回收站中文件的文件系統，用戶必須按期執行指令來刪除已在回收站中超過最小時間的全部文件：

% hadoop fs -expunge

Trash類的expunge（）方法也具備相同效果。

任務的內存限制

例如，假設一臺運行tasktracker的機器的可用內存耗盡，則會影響其餘正在運行的進程。爲了防止因爲map或reduce任務出現內存泄露，而影響集羣中各個節點的正常工做，須要設置mapred.child.ulimit，限制由tasktracker發起的子進程的最大虛擬內存（單位是千字節）。該值要明顯高於JVM內存（由mapred.child.java.opts設置），不然子JVM可能沒法啓動。

mapred.child.ulimit

限制由tasktracker發起的子進程的最大虛擬內存（單位是千字節）。

做業調度

在多用戶的MapReduce設置中，若考慮將默認的FIFO（先進先出）做業調度方案改變爲功能更強的調度方案，可參考《第6章-MapReduce的工做機制-做業的調度》一節。

Hadoop其餘屬性相關知識點

一、Hadoop緩衝區容量經過什麼屬性項來配置？

經過core-site.xml文件中的io.file.buffer.size屬性項來配置緩衝區大小。

二、Hadoop塊大小經過什麼屬性項來配置？

hdfs-site.xml文件中的dfs.block.size。

三、怎樣的文件刪除後可放到hadoop回收站中？

與其餘操做系統相似，hadoop回收站是用戶級特性。

只有由文件系統shell直接刪除的文件纔會放到回收站中，用程序刪除的文件會被直接刪除。

固然，也有例外狀況——使用Trash類。

構造一個Trash實例，調用moveToTrash()方法會把指定路徑的文件移到垃圾箱中。若是操做成功，該方法返回一個值；不然，若是回收站特性未被啓動，或該文件已經在回收站中，該方法返回false。

四、怎樣恢復hadoop回收站的文件

恢復也很簡易：在.Trash的子目錄中找到文件，並將其移出.Trash目錄。

能夠怎樣提高性能？

一、爲各個本地磁盤指定一個存儲目錄

針對dfs.data.dir配置的一系列目錄。爲了提升性能，最好分別爲各個本地磁盤指定一個存儲目錄。

這樣一來，數據塊跨磁盤分佈，針對不一樣數據塊的讀操做能夠併發執行，從而提高讀性能。

二、使用noatime選項掛載磁盤

爲了充分發揮性能，須要使用noatime選項掛載磁盤。

該選項意味着執行讀操做時，所讀文件的最新訪問時間信息並不刷新，從而顯著提高性能。

三、增大緩衝區容量

Hadoop使用使用一個4KB大小的緩衝區輔助I/O操做。

但對於現代硬件和操做系統來講，這個容量太過於保守了。增大緩衝區容量會顯著提升性能。

例如，64KB（65535字節）或256MB（131072字節）更爲經常使用。

能夠經過core-site.xml文件中的io.file.buffer.size屬性項來設置緩衝區大小。