hdfs部署ftp

⑴ 4、Hadoop-HDFS部署步驟（1.X）

        · 依賴軟體ssh、jdk

        · 環境的配置

                java_Home

                免密鑰

        · 時間同步

         ·  hosts、hostname

        ·  /opt/sxt/

        ·  配置文件新修改

                Java_Home

         ·  角色在哪裡啟動

           部署參考步驟（請點擊此處）

    （1）設置ssh免密鑰

ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa

cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

此時可檢驗是否設置成功，嘗試免密登錄本機，如下

    （2）安裝jdk 

首先利用xftp將安裝包導入，再解壓安裝

解壓後，java所在目錄位置如下   /usr/java

配置環境變數，打開  vi  /etc/profile    追加下面兩行

保存退出後，是設置系統配置，linux下使用source /etc/profile保存配置後，新的環境變數只能在一個終端裡面有效。

（3）hadoop部署

利用xftp將hadoop-2.6.5.tar.gz包上傳，解壓安裝

新建目錄存放hadoop

配置hadoop環境變數，增加如下兩行

進入如下目錄修改hadoop-env.sh等配置文件，首先修改hadoop-env.sh文件，改後如下

其次、修改mapred-env.sh，/usr/java/jdk1.8.0_261-amd64

修改yarn-env.sh

其次修改etc/hadoop下的core-site.xml和hdfs-site.xml,使主節點位置可知

```

<configuration>

    <property>

        <name>fs.defaultFS</name>

        <value>hdfs://node01:9000</value>

    </property>

    <property>

        <name>hadoop.tmp.dir</name>

        <value>/var/sxt/hadoop/local</value>

    </property>

</configuration>

```

```

<configuration>

    <property>

        <name>dfs.replication</name>

        <value>1</value>

    </property>

    <property>

        <name>dfs.namenode.secondary.http-address</name>

        <value>node01:50090</value>

    </property>

</configuration>

```

配置slaves文件，使DataNode可知，修改如下，如以後還有namenode，可添加

隨後格式化 hdfs namenode -format   顯示successfully則配置成功

啟動，如報錯，在查看下方日誌文件排錯

訪問node01：50070   如下所示，成功！

計劃：node01 ： NameNode

           node02 ： SecondaryNode    DataNode

          node03 node04 ： DataNode

（1）安裝jdk，配置環境變數，設置ssh免密鑰（將node01d1ssh的id_dsa.pub寫到其他三個節點）

此時查看node02中.ssh下目錄

或者直接將node01的authorized_keys追加到node02的.ssh下，如下所示，此時node01可以免密登錄node02

之後node03和node04依次執行圖3-1和圖3-2的命令。校準四個系統時間

修改node01的core-site.xml

進入node01的sxt目錄將hadoop-2.6.5拷貝到node02（03、04都要執行相同步驟）的同目錄下（node02下的opt/sxt）

經過以上步驟配置完成，再從node01進行格式化

hdfs namenode -format

⑵ 如何hadoop distcp ftp目錄中部分文件

hadoop中有一個叫做distcp（分布式復制）的有用程序，能從hadoop的文件系統並行復制大量數據。

distcp一般用於在兩個HDFS集群中傳輸數據。如果集群在hadoop的同一版本上運行，就適合使用hdfs方案：

% hadoop distcp hdfs://namenode1/foo hdfs://namenode2/bar
這將從第一個集群中復制/foo目錄（和它的內容）到第二個集群中的/bar目錄下，所以第二個集群會有/bar/foo目錄結構。如果/bar不存在，則會新建一個。可以指定多個源路徑，並且所有的都會被復制到目標路徑。源路徑必須是絕對路徑。

默認情況下，distcp會跳過目標路徑已經有的文件，但可以通過提供的-overwrite選項進行覆蓋，也可以用-update選項來選擇只更新那些修改過的文件。第一個集群的子樹/foo下的一個文件與第二個集群的改變進行同步。

% hadoop distcp -update hdfs://namenode1/foo hdfs://namenode2/bar/foo
distcp是作為一個MapRece作業執行的，復制工作由集群中並行運行的map來完成。這里沒有recer。每個文件都由一個單一的map進行復制，並且distcp通過將文件分成大致相等的文件來為每個map數量大致相同的數據。

map的數量確定：

通過讓每一個map復制數量合理的數據以最小化任務建立所涉及的開銷，是一個很好的想法，所以每個map的副本至少為256MB。例如，1GB的文件被分成4個map任務。如果數據很大，為限制帶寬和集群的使用而限制映射的數據就變得很有必要。map默認的最大數量是每個集群節點（tasktracker）有20個。例如，復制1000GB的文件到一個100個節點的集群，會分配2000個map（每個節點20個map），所以平均每個會復制512MB。通過對distcp指定-m參數，會減少映射的分配數量。例如，-m 1000會分配1000個map，平均每個復制1GB。

如果想在兩個運行著不同版本HDFS的集群上利用distcp，使用hdfs協議是會失敗的，因為RPC系統是不兼容的。想要彌補這種情況，可以使用基於HTTP的HFTP文件系統從源中進行讀取。這個作業必須運行在目標集群上，使得HDFS RPC版本是兼容的。使用HFTP重復前面的例子：% hadoop distcp hftp://namenode1:50070/foo hdfs://namenode2/bar

注意，需要在URI源中指定名稱節點的Web埠。這是由dfs.http.address的屬性決定的，默認值為50070。

保持HDFS集群的平衡

向HDFS復制數據時，考慮集群的平衡相當重要。文件塊在集群中均勻地分布時，HDFS能達到最佳工作狀態。回顧前面1000 GB數據的例子，通過指定-m選項為1，即由一個單一的map執行復制工作，它的意思是，不考慮速度變慢和未充分利用集群資源，每個塊的第一個副本會存儲在運行map的節點上(直到磁碟被填滿)。第二和第三個副本分散在集群中，但這一個節點並不會平衡。通過讓map的數量多於集群中節點的數量，我們便可避免這個問題。鑒於此，最好首先就用默認的每個節點20個map這個默認設置來運行distcp。

然而，這也並不總能阻止一個集群變得不平衡。也許想限制map的數量以便一些節點可以被其他作業使用。若是這樣，可以使用balancer工具繼續改善集群中塊的分布。

⑶ Hadoop文檔（2.9.2） - HDFS架構

Hadoop分布式文件系統（HDFS）是一種運行在通用硬體上的分布式文件系統。它與傳統的分布式文件系統有很多相似之處，但是也有顯著的不同。HDFS是高容錯的，可以部署在低成本硬體上。HDFS提供了對應用數據的高吞吐量訪問，適用於具有大數據集的應用。HDFS為了流數據訪問放鬆了一些POSIX的限制。

HDFS是主從結構。一個HDFS集群由一個NameNode和一組DataNode組成。NameNode是主伺服器，負責管理文件系統命名空間以及客戶端對文件的訪問。DataNode通常每個節點一個，負責管理存儲。HDFS對外暴露了一個文件系統命名空間並允許用戶數據作為文件存儲。在內部實現上，一個文件會被分割成一個或多個block，這些block存儲在一組DataNode上。NameNode負責執行文件系統命名空間操作，例如打開，關閉，重命名文件和目錄等。此外NameNode還維護著block和DataNode之間的映射關系。DataNode負責處理來自客戶端的讀寫請求，並根據NameNode的指令創建，刪除，備份block。

NameNode和DataNode都是運行在通用機器上的軟體。這些機器通常使用Linux系統。HDFS使用Java構建，任何支持Java的機器都可以運行NameNode和DataNode。一種典型的集群部署方式是使用一台機器運行NameNode，其它機器每台運行一個DataNode實例。

HDFS使用傳統的分層文件結構。用戶可以創建目錄並在目錄下存儲文件。文件系統命名空間結構與傳統文件系統類似，用戶可以創建，刪除文件，將文件從一個目錄移動到另一個目錄，重命名文件。HDFS支持用戶限額和訪問許可權。

NameNode維護整個文件系統命名空間，它會記錄任何對命名空間的修改。應用程序可以指定HDFS中文件的備份數量。文件的拷貝數稱為該文件的備份因子。這個信息也存儲在NameNode中。

HDFS可以跨機器存儲海量文件。每個文件分成一個block的序列存儲。為了容錯，文件的block會被備份。每個文件的block大小和備份因子都是可配置的。

文件中所有block的大小是相等的（除了最後一個），而對append和hsync提供可變長block支持後，用戶可以直接創建一個新block，不必繼續填充最後一個block。

應用程序可以指定文件的備份數。備份因子可在文件創建時指定，也可以稍後修改。HDFS的文件都是一次寫入的（除了append和truncate），並且任何時候都只有一個寫入器。

NameNode決定如何備份block。它周期性的接收來自DataNode的心跳檢測和block報表。收到心跳檢測說明DataNode工作正常，block報表包含該DataNode上的所有block。

備份文件的位置對HDFS的可用性和性能至關重要。對備份的優化讓HDFS從眾多分布式系統中脫穎而出。這個工作需要大量的優化和經驗。機架感知備份放置策略的目的是提高數據的可靠性，可用性和網路帶寬利用率。目前的備份放置策略實現是這個方向上的第一步。短期目標是在生產環境上對其進行驗證，更多的了解它的行為，為測試和研究更復雜的策略奠定基礎。

大型HDFS集群的機器通常隸屬於多個機架。兩個不同機架上的節點進行通信必須通過交換機。一般來說，同一機架機器之間的網路帶寬要優於不同機架機器間的網路帶寬。

NameNode通過Hadoop Rack Awareness進程確定每個DataNode所屬的機架ID。一個簡單但是並非最優的策略是將備份放置在獨立的機架上。這種策略可以避免機架故障時丟失數據，讀數據時也可以利用多個機架的網路帶寬。這種策略在集群中平均分配備份文件，這樣組件發生故障時可以平衡負載。但是這種策略會增加寫入成本，因為數據需要跨機架傳輸。

最常見的情況，備份因子是3。HDFS的放置策略是：如果寫入器位於DataNode上，則將副本放置在本地計算機，否則隨機選擇一個DataNode，另一個副本放置在另一個遠程機架的節點上，最後一個副本放在同一個遠程機架的另一個節點上。這種策略減少了機架間的寫入流量，從而提高寫性能。機架發生故障的幾率遠小於節點故障幾率。這種策略並不影響數據可靠性和可用性，但是它確實減少了讀操作時的聚合網路帶寬，因為一個block被放置到兩個機架上而不是三個。這種策略的文件副本並不是均勻的分布在所有機架上，副本的三分之一位於一個節點，剩下的三分之二位於另一個機架上。這種策略可以提高寫性能，而不會影響數據可靠性和讀性能。

如果備份因子大於3，那麼第四個和之後的副本隨機放置，同時要保證副本數量不能超過機架的上限（公式： (replicas - 1) / racks + 2 ）。

由於DataNode不能放置同一個block的多個副本，所以最大備份因子就是最大DataNode數。

在提供了存儲類型和存儲策略的支持之後，除了機架感知，NameNode放置副本時也會考慮放置策略。NameNode首先根據機架感知選擇節點，然後根據備份文件的放置策略檢查該節點的存儲類型，如果該候選節點沒有要求的存儲類型，NameNode會查找下一個節點。如果第一輪沒有找到足夠的節點放置備份，NameNode會使用後備存儲類型開始第二輪查找。

目前，副本放置策略依然在開發中。

為了減少帶寬消耗和讀延遲，HDFS會嘗試找尋一個離讀請求最近的副本。如果讀請求節點所在機架有這樣一個副本，HDFS就優先使用這個副本。如果HDFS集群跨越多個數據中心，則本地數據中心的副本優先於遠程副本。

啟動HDFS時，NameNode會進入一種稱為安全模式的特殊狀態。安全模式下數據block無法備份。NameNode會從DataNode接收心跳檢測和block報表。block報表包含該DataNode下所有數據block的列表信息。每個block都有一個指定的最小備份數。只有block的最小備份數登記到NameNode中後，block才可以備份。備份登記結束後，NameNode退出安全模式。這是如果還有block不滿足最小備份數的條件，NameNode才開始備份這些block。

HDFS命名空間由NameNode保存，NameNode使用一個稱為EditLog的事務日誌記錄對文件系統元數據的所有更改。例如，創建一個新文件會在EditLog中插入一條對應記錄，同樣的，修改文件備份因子也會插入一條記錄。NameNode使用本地文件存儲EditLog。整個文件系統命名空間，包括文件與block之間的映射關系，文件系統數據等，都保存在FsImage文件中。

NameNode在內存中維護文件系統命名空間和文件block映射關系的鏡像。當NameNode啟動，或者某個閾值觸發了檢查點時，NameNode從磁碟上讀取FsImage和EditLog的內容，將所有EditLog中的事務操作應用到FsImage的內存鏡像中，然後在磁碟上生成一個全新的FsImage。之後可以截斷EditLog，因為所有事務都已持久化到FsImage。這個過程稱為檢查點。檢查點的目的是通過獲取文件系統元數據的快照並保存到FsImage來保證HDFS文件系統元數據的一致性。讀取FsImage可能很快，但是持續編輯FsImage就不同了。因此我們將操作記錄到EditLog中，而不是直接修改FsImage。在檢查點期間，所有EditLog操作應用到FsImage。檢查點可以按周期觸發（ dfs.namenode.checkpoint.period ），也可以按事務數觸發（ dfs.namenode.checkpoint.txns ）。如果兩個屬性都設置了，第一個滿足的閾值會觸發檢查點。

DataNode在本地文件系統中存儲HDFS數據。DataNode對HDFS文件一無所知，它以block為單位存儲HDFS數據。DataNode不會在同一個目錄下保存所有文件。相反，它使用啟發式方法來確定每個目錄的最佳文件數，並適時創建子目錄。在同一個目錄下創建所有文件並不是最佳選擇，因為本地文件系統可能無法支持一個目錄下的大量文件。DataNode啟動時，它會掃描整個本地文件系統，生成一個本地文件與數據block之間的關系列表，將其發送給NameNode，這個列表稱為block報告。

所有HDFS通信協議都構建在TCP/IP協議之上。客戶端通過TCP埠與NameNode建立連接，它使用ClientProtocol與NameNode交互。DataNode使用DataProtocol與NameNode交互。一個RPC抽象封裝了客戶端協議和DataNode協議。NameNode從不初始化任何RPC，它只是響應來自的客戶端和DataNode的請求。

HDFS的主要目標是即使出現故障也可以可靠的存儲數據。三種常見的故障分別是：NameNode故障，DataNode故障和網路分區。

DataNode周期性的發送心跳檢測給NameNode。網路分區可能導致某些DataNode無法連接NameNode。NameNode無法收到DataNode的心跳檢測後，它會把這樣的DataNode標記為dead，並不在發送新的I/O請求。注冊到死亡DataNode上的數據對HDFS來說不再可用，也會導致某些block的備份數少於文件指定的最小備份數。NameNode持續追蹤block的備份情況並在必要時初始化備份操作。重備份的原因是多種多樣的：DataNode不可用，某個備份文件損壞，DataNode磁碟故障，或者文件的備份因子增大。

為了避免DataNode狀態抖動引起的備份風暴，標記DataNode死亡的超時時間設置的很長（默認超過10分鍾）。用戶可以設置一個更短的時間將DataNode標記為陳舊（stale），這樣可以避免對性能敏感的工作負載的陳舊DataNode的讀寫操作。

HDFS架構與數據重平衡scheme兼容。scheme可以在DataNode的磁碟空間低於某個閾值時將數據移動到另一個DataNode上。如果對某個文件的需求特別高，scheme還可以動態創建額外的副本並平衡到整個集群中。這些數據平衡scheme還未實現。

從DataNode中讀取的block可能是損壞的。損壞的原因有多種：磁碟故障，網路故障，或者軟體問題。HDFS客戶端會對文件內容進行校驗和檢查。當客戶端創建一個HDFS文件時，它會計算出文件所有block的校驗和並保存在同一個命名空間的一個獨立的隱藏文件中。當客戶單檢索文件時還要檢查對應校驗和文件中的值。如果校驗和不匹配，客戶端會嘗試該block其它節點上的副本。

FsImage和EditLog是HDFS的核心數據結構。如果它們發生損壞，HDFS就無法使用了。因此，可以通過配置讓NameNode維護多個FsImage和EditLog的拷貝。對兩個文件的修改會同步到所有拷貝中。這種同步操作會降低NameNode的TPS，但是這種犧牲是可接受的，因為HDFS是數據密集，不是元數據密集。NameNode重啟時，它會選擇最一致的FsImage和EditLog使用。

另一種減低故障的辦法是使用HA。

（略）

HDFS的目的是支持大型文件。HDFS支持一次寫入多次讀取。一個典型的block大小是128MB。因此，HDFS文件按照128MB的大小分割，每個block可能分布在不同的節點上。

客戶端向HDFS文件寫入數據時，如果備份因子是三，NameNode使用備份目標選擇演算法檢索出一組DataNode。這個列表是可以存儲副本的DataNode。客戶端先向第一個DataNode寫入數據，DataNode接收數據並將數據傳輸到列表中的第二個DataNode。第二個DataNode開始接收數據並繼續傳輸數據到第三個DataNode。這樣，數據通過管道從一個DataNode傳輸到下一個。

（略）

如果開啟了trash配置，從FS shell中刪除的文件並不會立刻從HDFS中刪除，HDFS將它移動到一個trash目錄（每個用戶都有自己的trash目錄， /user/<username>/.Trash ）。只要文件還在trash目錄中就可以快速恢復。

最近刪除的文件移動到 /user/<username>/.Trash/Current 目錄中，每隔一段時間，HDFS會為這些文件創建檢查點文件（ /user/<username>/.Trash/<date> ）並刪除舊檢查點文件。

如果trash中的文件過期了，NameNode將這些文件從命名空間中刪除。與文件關聯的block被釋放。刪除文件和空間釋放之間可能會有延遲。

下面是一個例子，首先創建兩個文件：

然後刪除test1，該文件會被移到Trash目錄：

接著跳過Trash刪除test2：

現在可以查看Trash目錄：

文件的備份因子降低後，NameNode選擇可以刪除的副本，在下次心跳檢測時把信息發送給DataNode，之後DataNode刪除block並釋放空間。

⑷ ftp提取文件到hdfs

實際場景中，我們經常需要通過ftp協議把不同數據源的文件統一匯入到hdfs數據中心，經過實踐，有以下的三種方法，分別列出其優缺點及適用場景。

1、 先把文件ftp到本地，然後用命令hdfsdfs –put [local_path] [hdfs_path]

優點：文件在本地可以進行本地化的一系列操作後，再放回hdfs中

缺點：文件傳輸經過兩層，並且從源伺服器到本地提取是單機串列，比較消耗時間。

適用於文件放入hfds前需要預處理的情景，如：.zip壓縮文件不被hadoop支持的，所以我們可以先在本地轉壓縮方式然後再放入hdfs中。

2、 hdfs dfs –cp [ftp://username:password@hostname/ftp_path] [hdfs:///hdfs_path]

優點：簡單，提取速度快

缺點：CLI執行不會顯示進度

適用場景：適用於小文件的ftp拷貝。

3、 hadoop distcp [ftp://username:password@hostname/ftp_path] [hdfs:///hdfs_path]

優點：簡單，能顯示拷貝進度，並且是分布式提取的，數據比較快。

缺點： 如果拷貝的文件是不斷有其他程序寫入，會報錯，因為該命令最後要對數據進行checksum導致兩邊不一致，當然，該命令是主要用於集群間拷貝的。

適用場景：大量文件或大文件的拷貝。