① HDFS的運行模式
在本機上使用HDFS，使用的就是本機的文件系統。
在core-default.xml中設置參數fs.defaultFS=file:///。
使用的文件系統是一個分布式的文件系統。一個分布式的文件系統，必須由NameNode、DataNode等若干進程共同運行完成文件系統的讀寫操作。
1、在$HADOOP_HOME/etc/hadoop/core-site.xml文件中加入以下配置。
2、格式化NameNode（只需要格式化一次）。
執行命令：hadoop namenode -format，該命令會生成/opt/mole/hadoop-2.7.2/data/tmp目錄，並在目錄中生成fsimage_0000000000000000000文件。
3、啟動NameNode和DataNode。
執行命令：hadoop-daemon.sh start namenode。同時可以通過執行命令：hadoop-daemon.sh start datanode來啟動DataNode。
4、查看。
通過jps命令查看NameNode進程是否已經開啟，通過瀏覽器訪問http://NameNode所在的主機名或者ip:50070可以查看HDFS。如果NameNode和DataNode都在一台機器，且只有一個DN節點，稱為偽分布式！
可以自定義配置文件的目錄： hadoop --config 配置文件的目錄 fs 命令 文件路徑。例如hadoop --config myconf/ fs -put /home/xzq/hello /（將文件hello拷貝到HDFS根目錄）。
如果沒有配置，會默認讀取$HADOOP_HOME/etc/hadoop中對應的配置文件，此時使用命令：hadoop fs 命令 文件路徑。例如hadoop fs -put hello /（將文件hello拷貝到HDFS根目錄）。
② HDFS 許可權管理
HDFS Permissions Guide
HDFS 實現了文件和目錄的許可權模型，很多跟POSIX模型共享。 每個文件、目錄都關聯到用戶、組。文件、目錄對於擁有者、組中的其他用戶、其他用戶有著不同的許可權設置。對於文件，讀取需要 r 許可權，寫入/追加需要 w 許可權。對於目錄，列出目錄內容需要 r 許可權，創建、刪除文件或目錄需要 w 許可權，訪問目錄子項需要 x 許可權。
與POSIX模型不同，因為沒有可執行文件，所以文件沒有 setuid or setgid bits。對於目錄，也沒有 setuid or setgid bits作為簡化。粘滯位 sticky bit 可以被作用於目錄，放置除superuser、目錄所有者、文件所有者之外的任何用戶刪除、移動目錄內的文件。粘滯位 sticky bit 對於文件不生效。 文件或目錄的許可權我們稱為 mod 。一般來說，mdoe的展示使用Unix風格，比如描述的8進制數使用。當創建一個文件/目錄後，它的所有者即為客戶端進程的用戶，它的組是父目錄的組（BSD規則）。
HDFS 還支持POSIX ACLs (Access Control Lists)，給指定用戶、組配置更新顆粒度的規則來加強許可權管理。ACLs稍後會詳細介紹。
每個訪問HDFS的客戶端進程身份都有兩部分組成：用戶名，組列表。無論什麼時候，HDFS都必須會客戶端進程訪問的文件或目錄foo做許可權檢查，
如果許可權校驗失敗，客戶端操作失敗。
自 Hadoop 0.22 起，Hadoop 支持兩種不同的操作模式來判斷用戶的身份，通過 hadoop.security.authentication 屬性指定：
不管是哪種模式，用戶身份機制都是HDFS的外部機制。HDFS中沒有用於創建用戶、建立組、處理用戶憑據的規定。
一旦username被判定，如上，groups list將由group mapping service 判斷，配置在 hadoop.security.group.mapping 屬性。參見 Hadoop Groups Mapping 獲取更多內容。
每次HDFS操作都需要用戶擁有指定許可權（讀，寫，執行的組合），通過文件的 ownership，group membership or 其他許可權進行授權。 一個操作會進行路徑多個組件的許可權檢查，而不僅是最後一個組件。另外，一些操作依賴於路徑owner的檢查。
所有的操作都需要遍歷訪問（traversal access）。遍歷訪問需要對路徑上的所有存在的組件擁有執行許可權，最終路徑組件除外。比如，任一訪問 /foo/bar/baz 的操作，調用者需要擁有 /, /foo and /foo/bar 的可執行許可權。
[1] 如果調用使用overwrite配置，並且該路徑已經存在文件，那麼 create 操作只需要對最終路徑組件擁有寫許可權即可。
[2] 如果設置了 sticky bit ，對父目錄寫許可權的檢查操作，同樣也會檢查ownership。
[3] 調用 setOwner 來改變文件的擁有著需要 HDFS super-user 訪問許可權。變更組不需要HDFS super-user 訪問許可權，但是調用者必須是文件的擁有者並且是指定組的成員。
每個文件、目錄操作都會將完全路徑發送給NameNode，對每個操作都會沿著path進行許可權檢查。客戶端框架隱式的將用戶身份與到NameNode的連接關聯，減少對現有客戶端API的改動的需求。常見一種情況，當某文件的一個操作已經成功完成了，再操作的時候會失敗，因為該路徑上的文件、目錄已經不存在了。舉個例子，當客戶端第一次開始讀取一個文件，它向NameNode發出第一個請求，以發現文件的第一個塊的位置。第二個請求查找其他的塊可能會失敗。另一方面，刪除一個文件並不會撤回客戶端對該文件的訪問，該客戶端已經知道該文件的塊。通過添加許可權，客戶端對文件的訪問可以在請求之間被撤回。同樣，變更許可權不會撤回客戶端的訪問，該客戶端已經知道文件的塊。
如果許可權檢查失敗，所有使用路徑參數的方法都會拋出 AccessControlException 。
新方法：
新文件、目錄的mode受umask設置限制，umask設置是配置項。
當使用現有方法 create(path, …) (不帶許可權參數)，新文件的 mode 是 0666 & ^umask 。
當使用新方法 create(path, permission, …) (帶許可權參數 P) ，新文件的 mode 是 P & ^umask & 0666 。
當使用現有方法 mkdirs(path) (不帶許可權參數)創建一個新目錄， 新目錄的 mode 是 0777 & ^umask 。
當使用新方法 mkdirs(path, permission) (帶許可權參數 P)， 新目錄的 mode 是 P & ^umask & 0777 。
新操作：
誰啟動NameNode，誰就是super-user。 super-user可以執行任意操作，許可權校驗從不失敗。HDFS super-user 不必是NameNode 主機上的super-user，也不是說集群內的說有主機都需要有這個super-user。
如果在個人電腦上實驗運行HDFS，為方便起見無須任何配置該用戶即成為安裝的super-user。
另外，管理員還可以通過配置參數標識一個特定組。該組內的成員也是super-users。
默認，web server的身份是一個可配置項。即，NameNode不知道真實用戶的身份，但是web server以管理員選定的用戶的身份（用戶/組）行動。 除非選擇的身份匹配super-user，部分命名空間是不可以被web server訪問的。
除了傳統的POSIX許可權模型，HDFS還支持POSIX ACLs (Access Control Lists)。ACLs 對於實現區分用戶、組的自然組織層次結構的許可權需求非常有用。ACL提供了一個方法，可以給指定用戶、組設置不同的許可權，而不僅僅是文件的擁有著和所屬組。
默認，ACLs的支持是關閉的，並且NameNode不允許創建ACLs。要開啟ACLs的支持，在NameNode配置內設置 dfs.namenode.acls.enabled 為 true。
一個ACL由一系列ACL entries組成。每條ACL entry 命名了特定用戶/組，並授於/拒絕 讀、寫、執行 許可權。比如：
ACL entries 由 type ，可選的 name 和 permission 組成。為了便於展示，『:』 用作分隔符。 在這個範例內，文件的owner有read-write許可權，文件的group有read-execute許可權，others有讀取許可權。因此，等同於設置文件的許可權為654。
另外，有2個擴展ACL entries給用戶 bruce 和組 sales，並全部賦予所有許可權。 mask 是一個特殊的ACL entry，過濾給所有命名的user entries 和命名的group entries 以及非命名的group entry的許可權。 在範例內， mask 僅有寫許可權，並且我們可以看到幾個ACL entries的有效許可權被相應的過濾了。
每個ACL都必要要有一個 mask 。如果在設置ACL的時候用戶沒有提供 mask ，那麼會通過計算來自動插入，計算將被過濾的所有entries的許可權的並集。
在擁有ACL的文件上運行 chmod 實際上改變了 mask 的許可權。既然 mask 作為過濾器，這有效的約束了所有擴展ACLs的許可權，而不僅是變更group entry並且可能會丟失其他擴展ACL entries。
模型還有效區分了 「access ACL」 和 「default ACL」 。
「access ACL」 ，定義許可權檢查期間強制執行的規則； 「default ACL」 ，定義新子文件或子目錄創建期間自動接受的規則。
比如：
只有目錄可以擁有默認 ACL。當一個新文件或者子目錄創建，它會自動的拷貝父級的默認ACL作為自己的ACL。新子目錄還將其作為默認 ACL。這樣，當新目錄創建時，默認 ACL 會被復制到該文件系統數的任意深度層。
新子級的ACL的確切許可權值將由mode參數進行過濾。考慮到默認umask 是 022，則新目錄是755，新文件是644。mode參數給unnamed user (file owner), the mask and other過濾過濾拷貝過來的許可權值。 使用這個特定範例ACL，並創建一個mod 755的子目錄，該mode過濾器對最終結果沒有影響。但是，如果我們考慮創建一個mode 644 的文件，mode過濾器會導致新文件的ACL接受unnamed user(file owner)的讀寫許可權，mask的讀許可權，以及其他的讀許可權。 該mask意味著named user bruce 和 named group sales 的有效許可權是只讀。
注意，拷貝發生在創建新文件或子目錄的時候。對父級默認ACL的後續修改不會影響存在的子級。
默認 ACL 必須擁有所有必要的ACL entries，包括unnamed user (file owner)， unnamed group (file group) and other entries。當設置默認ACL的時候，如果用戶沒有指定其中某個entry，那麼entries會自動插入，通過拷貝訪問ACL相應的許可權、如果沒有訪問ACL則拷貝permission bits來實現。默認ACL必須擁有mask。如上所屬，如果沒有指定會自動插入一個計算的值。
對擁有ACL的文件，許可權的檢查演算法變更為：
最佳實踐依賴傳統的許可權位來實現大多數許可權需求，並定義較少數量的ACL來加強，用一些異常規則來擴充許可權位。與只有許可權位的文件相比，具有ACL的文件在NameNode中會增加內存開銷。
新方法：
public void modifyAclEntries(Path path, List<AclEntry> aclSpec) throws IOException;
public void removeAclEntries(Path path, List<AclEntry> aclSpec) throws IOException;
public void public void removeDefaultAcl(Path path) throws IOException;
public void removeAcl(Path path) throws IOException;
public void setAcl(Path path, List<AclEntry> aclSpec) throws IOException;
public AclStatus getAclStatus(Path path) throws IOException;
參考 File System Shell 文檔獲取命令的全部內容。
如果是，則使用這里描述的許可權系統。如果否，關閉許可權檢查，但是其他行為不變。從一個參數值切換到其他值不會改變mode、文件或目錄的owner or group。無論許可權是開還是關， chmod 、 chgrp 、 chown and setfacl 總是會檢查許可權。 這些功能僅在許可權上下文有用，因此不存在向後兼容問題。此外，這允許管理員可靠的設置所有者和許可權，在打開常規許可權檢查前。
web server使用的用戶名。設置為super-user允許所有客戶端看到任何內容。改為其他未使用的身份允許web客戶端僅可以查看"other"許可權可見的內容。其他將其他組添加到逗號分隔列表內。
super-users 的組。
當創建文件和目錄時使用的 umask 。對於配置文件，可以使用十進制值 18。
集群的管理員被配置為ACL。這控制誰可以訪問HDFS默認的servlets 等。
設置為true，開啟HDFS ACLs (Access Control Lists)的支持。默認，ACLs是關閉的。當ACLs關閉的時候，NameNode拒絕所有設置ACL的企圖。 .
設置為true，開啟 POSIX風格的ACL繼承。默認開啟。當它被啟動時，並且create請求來自於兼容客戶端，NameNode會從父目錄應用默認ACL來創建mode並忽視客戶端umask。如果沒有默認ACL，它將應用客戶端umask。
③ NoSQL-HDFS-基本概念
Hadoop
文件系統：文件系統是用來存儲和管理文件，並且提供文件的查詢、增加、刪除等操作。
直觀上的體驗：在shell窗口輸入 ls 命令，就可以看到當前目錄下的文件夾、文件。
文件存儲在哪裡？硬碟
一台只有250G硬碟的電腦，如果需要存儲500G的文件可以怎麼辦？先將電腦硬碟擴容至少250G，再將文件分割成多塊，放到多塊硬碟上儲存。
通過 hdfs dfs -ls 命令可以查看分布式文件系統中的文件，就像本地的ls命令一樣。
HDFS在客戶端上提供了查詢、新增和刪除的指令，可以實現將分布在多台機器上的文件系統進行統一的管理。
在分布式文件系統中，一個大文件會被切分成塊，分別存儲到幾台機器上。結合上文中提到的那個存儲500G大文件的那個例子，這500G的文件會按照一定的大小被切分成若干塊，然後分別存儲在若乾颱機器上，然後提供統一的操作介面。
看到這里，不少人可能會覺得，分布式文件系統不過如此，很簡單嘛。事實真的是這樣的么？
潛在問題
假如我有一個1000台機器組成的分布式系統，一台機器每天出現故障的概率是0.1%，那麼整個系統每天出現故障的概率是多大呢？答案是(1-0.1%)^1000=63%，因此需要提供一個容錯機制來保證發生差錯時文件依然可以讀出，這里暫時先不展開介紹。
如果要存儲PB級或者EB級的數據，成千上萬台機器組成的集群是很常見的，所以說分布式系統比單機系統要復雜得多呀。
這是一張HDFS的架構簡圖：
client通過nameNode了解數據在哪些DataNode上，從而發起查詢。此外，不僅是查詢文件，寫入文件的時候也是先去請教NameNode，看看應該往哪個DateNode中去寫。
為了某一份數據只寫入到一個Datanode中，而這個Datanode因為某些原因出錯無法讀取的問題，需要通過冗餘備份的方式來進行容錯處理。因此，HDFS在寫入一個數據塊的時候，不會僅僅寫入一個DataNode，而是會寫入到多個DataNode中，這樣，如果其中一個DataNode壞了，還可以從其餘的DataNode中拿到數據，保證了數據不丟失。
實際上，每個數據塊在HDFS上都會保存多份，保存在不同的DataNode上。這種是犧牲一定存儲空間換取可靠性的做法。
接下來我們來看一下完整的文件寫入的流程：
大文件要寫入HDFS，client端根據配置將大文件分成固定大小的塊，然後再上傳到HDFS。
讀取文件的流程：
1、client詢問NameNode，我要讀取某個路徑下的文件，麻煩告訴我這個文件都在哪些DataNode上？
2、NameNode回復client，這個路徑下的文件被切成了3塊，分別在DataNode1、DataNode3和DataNode4上
3、client去找DataNode1、DataNode3和DataNode4，拿到3個文件塊，通過stream讀取並且整合起來
文件寫入的流程：
1、client先將文件分塊，然後詢問NameNode，我要寫入一個文件到某個路徑下，文件有3塊，應該怎麼寫？
2、NameNode回復client，可以分別寫到DataNode1、DataNode2、DataNode3、DataNode4上，記住，每個塊重復寫3份，總共是9份
3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把數據寫到他們上面
出於容錯的考慮，每個數據塊有3個備份，但是3個備份快都直接由client端直接寫入勢必會帶來client端過重的寫入壓力，這個點是否有更好的解決方案呢？回憶一下mysql主備之間是通過binlog文件進行同步的，HDFS當然也可以借鑒這個思想，數據其實只需要寫入到一個datanode上，然後由datanode之間相互進行備份同步，減少了client端的寫入壓力，那麼至於是一個datanode寫入成功即成功，還是需要所有的參與備份的datanode返回寫入成功才算成功，是可靠性配置的策略，當然這個設置會影響到數據寫入的吞吐率，我們可以看到可靠性和效率永遠是「魚和熊掌不可兼得」的。
潛在問題
NameNode確實會回放editlog，但是不是每次都從頭回放，它會先載入一個fsimage，這個文件是之前某一個時刻整個NameNode的文件元數據的內存快照，然後再在這個基礎上回放editlog，完成後，會清空editlog，再把當前文件元數據的內存狀態寫入fsimage，方便下一次載入。
這樣，全量回放就變成了增量回放，但是如果NameNode長時間未重啟過，editlog依然會比較大，恢復的時間依然比較長，這個問題怎麼解呢？
SecondNameNode是一個NameNode內的定時任務線程，它會定期地將editlog寫入fsimage，然後情況原來的editlog，從而保證editlog的文件大小維持在一定大小。
NameNode掛了， SecondNameNode並不能替代NameNode，所以如果集群中只有一個NameNode，它掛了，整個系統就掛了。hadoop2.x之前，整個集群只能有一個NameNode，是有可能發生單點故障的，所以hadoop1.x有本身的不穩定性。但是hadoop2.x之後，我們可以在集群中配置多個NameNode，就不會有這個問題了，但是配置多個NameNode，需要注意的地方就更多了，系統就更加復雜了。
俗話說「一山不容二虎」，兩個NameNode只能有一個是活躍狀態active，另一個是備份狀態standby，我們看一下兩個NameNode的架構圖。
兩個NameNode通過JournalNode實現同步editlog，保持狀態一致可以相互替換。
因為active的NameNode掛了之後，standby的NameNode要馬上接替它，所以它們的數據要時刻保持一致，在寫入數據的時候，兩個NameNode內存中都要記錄數據的元信息，並保持一致。這個JournalNode就是用來在兩個NameNode中同步數據的，並且standby NameNode實現了SecondNameNode的功能。
進行數據同步操作的過程如下：
active NameNode有操作之後，它的editlog會被記錄到JournalNode中，standby NameNode會從JournalNode中讀取到變化並進行同步，同時standby NameNode會監聽記錄的變化。這樣做的話就是實時同步了，並且standby NameNode就實現了SecondNameNode的功能。
優點：
缺點：
④ 大數據之HDFS
在現代的企業環境中，單機容量往往無法存儲大量數據，需要跨機器存儲。統一管理分布在集群上的文件系統稱為 分布式文件系統 。
HDFS （Hadoop Distributed File System）是 Hadoop 的核心組件之一， 非常適於存儲大型數據 (比如 TB 和 PB)， HDFS 使用多台計算機存儲文件，並且提供統一的訪問介面，像是訪問一個普通文件系統一樣使用分布式文件系統。
HDFS是分布式計算中數據存儲管理的基礎，是基於流數據模式訪問和處理超大文件的需求而開發的，可以運行於廉價的商用伺服器上。它所具有的 高容錯、高可靠性、高可擴展性、高獲得性、高吞吐率 等特徵為海量數據提供了不怕故障的存儲，為超大數據集的應用處理帶來了很多便利。
HDFS 具有以下 優點 ：
當然 HDFS 也有它的 劣勢 ，並不適合以下場合：
HDFS 採用Master/Slave的架構來存儲數據，這種架構主要由四個部分組成，分別為HDFS Client、NameNode、DataNode和Secondary NameNode。
Namenode是整個文件系統的管理節點，負責接收用戶的操作請求。它維護著整個文件系統的目錄樹，文件的元數據信息以及文件到塊的對應關系和塊到節點的對應關系。
Namenode保存了兩個核心的數據結構：
在NameNode啟動的時候，先將fsimage中的文件系統元數據信息載入到內存，然後根據edits中的記錄將內存中的元數據同步到最新狀態；所以，這兩個文件一旦損壞或丟失，將導致整個HDFS文件系統不可用。
為了避免edits文件過大， SecondaryNameNode會按照時間閾值或者大小閾值，周期性的將fsimage和edits合並 ，然後將最新的fsimage推送給NameNode。
並非 NameNode 的熱備。當NameNode 掛掉的時候，它並不能馬上替換 NameNode 並提供服務。其主要任務是輔助 NameNode，定期合並 fsimage和fsedits。
Datanode是實際存儲數據塊的地方，負責執行數據塊的讀/寫操作。
一個數據塊在DataNode以文件存儲在磁碟上，包括兩個文件，一個是數據本身，一個是元數據，包括數據塊的長度，塊數據的校驗和，以及時間戳。
文件劃分成塊，默認大小128M，以快為單位，每個塊有多個副本（默認3個）存儲不同的機器上。
Hadoop2.X默認128M， 小於一個塊的文件，並不會占據整個塊的空間 。Block數據塊大小設置較大的原因：
文件上傳 HDFS 的時候，Client 將文件切分成 一個一個的Block，然後進行存儲。
Client 還提供一些命令來管理 HDFS，比如啟動或者關閉HDFS。
Namenode始終在內存中保存metedata，用於處理「讀請求」，到有「寫請求」到來時，namenode會首 先寫editlog到磁碟，即向edits文件中寫日誌，成功返回後，才會修改內存 ，並且向客戶端返回，Hadoop會維護一個fsimage文件，也就是namenode中metedata的鏡像，但是fsimage不會隨時與namenode內存中的metedata保持一致，而是每隔一段時間通過合並edits文件來更新內容。
HDFS HA（High Availability）是為了解決單點故障問題。
HA集群設置兩個名稱節點，「活躍（ Active ）」和「待命（ Standby ）」，兩種名稱節點的狀態同步，可以藉助於一個共享存儲系統來實現，一旦活躍名稱節點出現故障，就可以立即切換到待命名稱節點。
為了保證讀寫數據一致性，HDFS集群設計為只能有一個狀態為Active的NameNode，但這種設計存在單點故障問題，官方提供了兩種解決方案：
通過增加一個Secondary NameNode節點，處於Standby的狀態，與Active的NameNode同時運行。當Active的節點出現故障時，切換到Secondary節點。
為了保證Secondary節點能夠隨時頂替上去，Standby節點需要定時同步Active節點的事務日誌來更新本地的文件系統目錄樹信息，同時DataNode需要配置所有NameNode的位置，並向所有狀態的NameNode發送塊列表信息和心跳。
同步事務日誌來更新目錄樹由JournalNode的守護進程來完成，簡稱為QJM，一個NameNode對應一個QJM進程，當Active節點執行任何命名空間文件目錄樹修改時，它會將修改記錄持久化到大多數QJM中，Standby節點從QJM中監聽並讀取編輯事務日誌內容，並將編輯日誌應用到自己的命名空間。發生故障轉移時，Standby節點將確保在將自身提升為Active狀態之前，從QJM讀取所有編輯內容。
注意，QJM只是實現了數據的備份，當Active節點發送故障時，需要手工提升Standby節點為Active節點。如果要實現NameNode故障自動轉移，則需要配套ZKFC組件來實現，ZKFC也是獨立運行的一個守護進程，基於zookeeper來實現選舉和自動故障轉移。
雖然HDFS HA解決了「單點故障」問題，但是在系統擴展性、整體性能和隔離性方面仍然存在問題：
HDFS HA本質上還是單名稱節點。HDFS聯邦可以解決以上三個方面問題。
在HDFS聯邦中，設計了多個相互獨立的NN，使得HDFS的命名服務能夠水平擴展，這些NN分別進行各自命名空間和塊的管理，不需要彼此協調。每個DN要向集群中所有的NN注冊，並周期性的發送心跳信息和塊信息，報告自己的狀態。
HDFS聯邦擁有多個獨立的命名空間，其中，每一個命名空間管理屬於自己的一組塊，這些屬於同一個命名空間的塊組成一個「塊池」。每個DN會為多個塊池提供塊的存儲，塊池中的各個塊實際上是存儲在不同DN中的。
⑤ 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導致兩邊不一致，當然，該命令是主要用於集群間拷貝的。
適用場景：大量文件或大文件的拷貝。
⑥ HDFS文件
Hadoop支持的文件系統由很多（見下圖），HDFS只是其中一種實現。java抽象類 org.apache.hadoop.fs.FileSystem 定義了Hadoop中一個文件系統的客戶端介面，並且該抽象類有幾個具體實現。Hadoop一般使用URI（下圖）方案來選取合適的文件系統實例進行交互。
特別的，HDFS文件系統的操作可以使用 FsSystem shell 、客戶端（http rest api、Java api、C api等）。
FsSystem shell 的用法基本同本地shell類似，命令可參考 FsSystem shell
Hadoop是用Java寫的，通過Java Api（ FileSystem 類）可以調用大部分Hadoop文件系統的交互操作。更詳細的介紹可參考 hadoop Filesystem 。
非Java開發的應用可以使用由WebHDFS協議提供的HTTP REST API，但是HTTP比原生的Java客戶端要慢，所以不到萬不得已盡量不要使用HTTP傳輸特大數據。通過HTTP來訪問HDFS有兩種方法：
兩種如圖
在第一種情況中，namenode和datanode內嵌的web服務作為WebHDFS的端節點運行（是否啟用WebHDFS可通過dfs.webhdfs.enabled設置，默認為true）。文件元數據在namenode上，文件讀寫操作首先被發往namenode，有namenode發送一個HTTP重定向至某個客戶端，指示以流的方式傳輸文件數據的目的或源datanode。
第二種方法依靠一個或多個獨立代理伺服器通過HTTP訪問HDFS。所有集群的網路通信都需要通過代理，因此客戶端從來不直接訪問namenode或datanode。使用代理後可以使用更嚴格的防火牆策略和帶寬策略。
HttpFs代理提供和WebHDFS相同的HTTP介面，這樣客戶端能夠通過webhdfs URI訪問介面。HttpFS代理啟動獨立於namenode和datanode的守護進程，使用httpfs.sh 腳本，默認在一個不同的埠上監聽（14000）。
下圖描述了
讀文件時客戶端與 HDFS 中的 namenode， datanode 之間的數據流動。
對上圖的解釋如下：
在讀取過程中， 如果 FSDataInputStream 在和一個 datanode 進行交流時出現了一個錯誤，他就去試一試下一個最接近的塊，他當然也會記住剛才發生錯誤的 datanode 以至於之後不會再在這個 datanode 上進行沒必要的嘗試。 DFSInputStream 也會在 datanode 上傳輸出的數據上核查檢查數(checknums).如果損壞的塊被發現了， DFSInputStream 就試圖從另一個擁有備份的 datanode 中去讀取備份塊中的數據。
在這個設計中一個重要的方面就是客戶端直接從 datanode 上檢索數據，並通過 namenode 指導來得到每一個塊的最佳 datanode。這種設計允許 HDFS 擴展大量的並發客戶端，因為數據傳輸只是集群上的所有 datanode 展開的。期間，namenode 僅僅只需要服務於獲取塊位置的請求（塊位置信息是存放在內存中，所以效率很高）。如果不這樣設計，隨著客戶端數據量的增長，數據服務就會很快成為一個瓶頸。
我們知道，相對於客戶端(之後就是 maprece task 了)，塊的位置有以下可能性：
我們認為他們對於客戶端的帶寬遞減，距離遞增（括弧中表示距離）。示意圖如下：
如果集群中的機器都在同一個機架上，我們無需其他配置，若集群比較復雜，由於hadoop無法自動發現網路拓撲，所以需要額外配置網路拓撲。
基本讀取程序，將文件內容輸出到console
FileSystemCat
隨機讀取
展開原碼
下圖描述了寫文件時客戶端與 HDFS 中的 namenode， datanode 之間的數據流動。
對上圖的解釋如下：
如果在任何一個 datanode 在寫入數據的時候失敗了，接下來所做的一切對客戶端都是透明的：首先， pipeline 被關閉，在確認隊列中的剩下的包會被添加進數據隊列的起始位置上，以至於在失敗的節點下游的任 何節點都不會丟失任何的包。然後與 namenode 聯系後，當前在一個好的 datanode 會聯系 namenode， 給失敗節點上還未寫完的塊生成一個新的標識ID， 以至於如果這個失敗的 datanode 不久後恢復了，這個不完整的塊將會被刪除。失敗節點會從 pipeline 中移除，然後剩下兩個好的 datanode 會組成一個的新的 pipeline ，剩下的 這些塊的包(也就是剛才放在數據隊列隊首的包)會繼續寫進 pipeline 中好的 datanode 中。最後，namenode 注意到塊備份數小於規定的備份數，他就安排在另一個節點上創建完成備份，直接從已有的塊中復制就可以。然後一直到滿足了備份數( dfs.replication )。如果有多個節點的寫入失敗了，如果滿足了最小備份數的設置( dfs.namenode.repliction.min ),寫入也將會成功，然後剩下的備份會被集群非同步的執行備份，直到滿足了備份數( dfs.replication )。
創建目錄
文件壓縮有兩大好處：
Hadoop 對於壓縮格式的是自動識別。如果我們壓縮的文件有相應壓縮格式的擴展名（比如 lzo，gz，bzip2 等）。Hadoop 會根據壓縮格式的擴展名自動選擇相對應的解碼器來解壓數據，此過程完全是 Hadoop 自動處理，我們只需要確保輸入的壓縮文件有擴展名。
Hadoop中有多種壓縮格式、演算法和工具，下圖列出了常用的壓縮方法。
表中的「是否可切分」表示對應的壓縮演算法是否支持切分，也就是說是否可以搜索數據流的任意位置並進一步往下讀取數據，可切分的壓縮格式尤其適合MapRece。
所有的壓縮演算法都需要權衡空間/時間：壓縮和解壓縮速度更快，其代價通常是只能節省少量的空間。不同的壓縮工具有不同的特性：
更詳細的比較如下
1.壓縮性能比較
2.優缺點
另外使用hadoop原生（native）類庫比其他java實現有更快的壓縮和解壓縮速度。特徵比較如下：
使用容器文件格式結合壓縮演算法也能更好的提高效率。順序文件、Arvo文件、ORCFiles、Parqurt文件同時支持壓縮和切分。
壓縮舉例（Java）
壓縮
解壓縮
六、文件序列化
序列化是指將結構化數據轉換為位元組流以便在網路上傳輸或寫到磁碟進行永久存儲。反序列化獅子將位元組流轉換回結構化對象的逆過程。
序列化用於分布式數據處理的兩大領域：進程間通信和永久存儲。
對序列化的要求時是格式緊湊（高效使用存儲空間）、快速（讀寫效率高）、可擴展（可以透明地讀取老格式數據）且可以互操作（可以使用不同的語言讀寫數據）。
Hadoop使用的是自己的序列化格式 Writable ，它絕對緊湊、速度快，但不太容易用java以外的語言進行擴展或使用。
當然，用戶也可以使用其他序列化框架或者自定義序列化方式，如 Avro 框架。
Hadoop內部還使用了 Apache Thrift 和 Protocal Buffers 來實現RPC和數據交換。
⑦ HDFS(五)：NN和2NN
內存一份數據，fsImage存儲數據（合並後的數據，即沒有追加前數據），edits文件只追加，不參與計算
內存數據 == fsImage+edits
伺服器啟動：將（fsImage+edits）數據載入到內存
伺服器關閉：將 fsImage+edits合並
2nn將fsimage和edits文件定期合並
NameNode 被格式化後，將在/opt/mole/hadoop-3.1.3/data/tmp/dfs/name/current目錄中產生如下文件
2NN 在/opt/mole/hadoop-3.1.3/data/tmp/dfs/namesecondary/current
NameNode相比較2nn多了edits_inprogress
NameNode被格式化之後，將在/opt/mole/hadoop-3.1.3/data/tmp/dfs/name/current目錄產生如下文件
1）fsimage文件：HDFS文件系統元數據的一個永久性檢查點，其中包含HDFS文件系統的所有目錄和inode的序列化信息
2）Edits文件：存放HDFS文件系統的所有更新操作的路徑，文件系統客戶端執行的所有寫操作首先會被記錄到edits文件中
3）seen_txid：文件保存的是一個數字，就是最後一個edits_數字
4）VERSION，當前nameNode的命名空間，和集群id
（1）基本語法
hdfs oiv -p 文件類型 -i鏡像文件 -o 轉換後文件輸出路徑
（2）實操
NameNode沒有記錄塊所對應DataNode，DataNode啟動後向NameNode匯報自己有哪些文件塊
（1）基本語法
hdfs oev -p 文件類型 -i 編輯日誌 -o 轉換後文件輸出路徑
（2）實操
只進行追加，不進行合並操作。
在伺服器啟動進入內存，只載入edits後綴大於fsimage後綴。
hdfs-default.xml
1）通常情況下，SecondaryNameNode每隔一個小時執行一次。[hdfs-default.xml]
2）一分鍾檢查一次操作次數，當操作次數達到1百萬次，SecondaryNameNode執行一次。
2nn每隔1分鍾，主動查詢一次。
通過本節可以知道兩個文件fsimage和edits文件作用，通過這兩個文件就是NameNode存儲的元數據。
⑧ hadoop面試題之HDFS
1、簡單介紹下hadoop吧？
廣義上hadoop是指與hadoop相關的大數據生態圈。包含hive、spark、hbase等。
狹義上hadoop指的是apache的開源框架。有三個核心組件：
----hdfs：分布式文件存儲系統
----yarn：分布式資源管理調度平台
----mr：分布式計算引擎
2、介紹下hdfs?
全稱為Hadoop Distributed File System。有三個核心組件：
namenode：有三個作用，第一是負責保存集群的元數據信息，第二是負責維護整個集群節點的正常運行。
第三是負責處理客戶端的請求。
datanode：負責實際保存數據。實際執行數據塊的讀寫操作。
secondarynamenode：輔助namenode進行元數據的管理。不是namenode的備份。
3、namenode的工作機制？
namenode在內存中保存著整個內存系統的名稱空間和文件數據塊的地址映射。整個hdfs可存儲的文件數受限於namenode的內存大小。所以hdfs不適合大量小文件的存儲。
---namenode有三種元數據存儲方式來管理元數據：
》內存元數據：內存中保存了完整的元數據
》保存在磁碟上的元數據鏡像文件（fsimage）：該文件時hdfs存在磁碟中的元數據檢查點，裡面保存的是最後一次檢查點之前的hdfs文件系統中所有目錄和文件的序列化信息。
》數據操作日誌文件（edits）：用於銜接內存meta data和持久化元數據鏡像fsimage之間的操作日誌文件。保存了自最後一次檢查點之後所有針對hdfs文件系統的操作。如對文件的增刪改查。
4、如何查看元數據信息？
因為edits和fsimage文件是經過序列化的，所以不能直接查看。hadoop2.0以上提供了查看兩種文件的工具。
----命令：hdfs oiv 可以將fsimage文件轉換成其他格式，如xml和文本文件。-i 表示輸入fsimage文件。-o 輸出文件路徑，-p 指定輸出文件
hdfs oev可以查看edits文件。同理需要指定相關參數。
詳情查看： https://www.imooc.com/article/79705
4、datanode的工作機制？
1）以數據塊的形式存儲hdfs文件
2）datanode響應客戶端的讀寫請求
3）周期性的向namenode匯報心跳信息、數據塊信息、緩存數據塊信息
5、secondary namenode工作機制？
當發生checkpoint機制時會觸發second namenode進行工作。checkpoint：
新的edists文件不會立即和fsimage文件合並，是在edits文件大小超過（默認）64m，或者時間超過（默認）1小時，會觸發checkpoint操作。當checkpoint時，namenode會新建一個edits.new的文件,此時second namenode將文件fsimage文件和edits文件（http get）到本地，然後載入到內存中進行合並，完成的文件名稱為fsimage.ckpt。最後 second namenode將該文件（http post）到namenode，然後edits.new和fsimage.ckpt文件轉換為fsimage和edits。
6、hdfs的文件副本機制？
所有的文件都是以塊的形式保存到hdfs中。塊的大小默認為128m。在hdfs-site文件中進行指定。
動態副本創建策略：默認副本數是3，可以在上傳文件時，顯式設定replication。也可以通過指令修改文件的副本數 hadoop fs -setrep -R 1
7、為實現高可用，hdfs採用了哪些策略？
副本機制、機架感知、心跳機制、安全模式、校驗和、回收站、元數據保護、快照機制（具體介紹導航- https://www.jianshu.com/writer#/notebooks/44567747/notes/66453316 ）
8、hdfs的存儲過程？
①client向hdfs發起寫請求，通過RPC與namenode建立通訊。namenode檢查文件是否存在等信息，返回是否可以存儲。
②client將文件切割為一個個block塊，client申請存儲第一塊block。namenode返回可以存儲這個block塊的datanode的地址，假設為ABC。
③A到B到C逐級構建pipeline。client向A上傳第一個packet，默認為64k。A收到一個packet後會將packet傳給B，再傳給C。pipeline反方向返回ack信息。最終由第一個節點A將pipelineack發送給client
④一個block完成之後，再進行下一個block的存儲過程。
9、hdfs的讀過程？
10、hdfs的垃圾桶機制？
hdfs的垃圾桶機制默認是關閉的，需要手動開啟。hdfs刪除的文件不會立刻就刪除，而是在設定的時間後進行刪除。
11、hdfs的擴容和縮容
【
12、
⑨ HDFS筆記
1.Hadoop 分布式 文件系統。特點：性能高、效率高、速度快
2.可以在廉價的機器上運行的 可容錯 文件系統。
當集群中有機器掛掉時，HDFS會自動將掛掉的機器上的任務分配給正常的機器，使任務繼續保持正常工作。
2.HDFS處理更加容易。當對一個大型文件進行寫操作時，如果將該文件整個寫入一個節點，那麼該節點的負載便會急劇增加，這樣就喪失了分布式文件系統的意義。所以，應該利用HDFS將文件拆分成不同的塊，然後將不同的塊分配到不同的節點上去，此時，DFS就需要管理者確定文件如何進行拆分，以及每一個塊應該分配到哪一個節點。對文件進行操作時，在單機情況下，首先需要知道文件被拆分成多少塊，每一個塊被放在了哪一個節點上，以及塊之間的順序(文件的粘連)。而HDFS的出現，使得分布式文件集群不再需要人進行管理，利用HDFS讀取文件時，我們不需要關心文件如何拆分，分配，粘連。只用告訴HDFS文件的路徑即可。
HDFS的指令類似於linux下的指令。
查看文件：hdfs dfs -ls /查詢的文件目錄
刪除文件：hdfs dfs -rm r /刪除的文件
創建文件夾：hdfs dfs -mkdir /文件夾名稱
上傳文件至HDFS：hdfs dfs -put 需要上傳的文件 /上傳的文件路徑
為什麼需要學習HDFS結構？
1.面試中，能夠運用於所有分布式文件系統設計。
既然分布式系統下是多節點運行，那麼節點之間是否通信？slave節點只接受來自master節點的命令，向master節點發送心跳指令，slave節點之間不會主動通信。
a.Master slaver 模式：
1.High consistency:一致性。當文件中的一個數據塊寫入slave節點時，當且僅當數據塊被成功寫入到所有備份的slave節點，slave節點向client反饋寫入操作成功，否則，重傳寫入；
2.Simple design:易設計：不需要考慮子節點如何通信。只需要考慮主節點的工作；
3.單master節點不具有魯棒性。
b.Peer peer 模式：
1.所有的讀寫操作均勻分布在每一個節點上，每一個節點的負載不會很高；
2.任意一個節點掛掉不會影響其他節點；
3.低一致性。沒有數據的復制步驟。
2.更好的理解hadoop生態系統
a.master節點會傳輸數據嗎？
不會，master節點只接收client的請求，決定哪一個slave節點進行讀寫操作，然後，client直接與slave節點進行通信。如果數據從master節點傳輸，那麼master節點就會成為影響數據傳輸的瓶頸。
b.slave節點如何存儲數據？
整個大文件？小的文件塊？。HDFS借鑒GFS的設計理念，以block為傳輸單位，將大文件拆分成一個一個小文件，而一個小文件就是block。block的大小可以由Configuration定義，默認大小是128M。
c.誰來決定將文件拆分成塊？
master?slave?。兩者都不是，由HDFS client決定將大文件拆分成block(塊)。HDFS的目的是將所有的節點包裝起來，可以理解成將所有的節點放在一個黑箱里，我們不需要知道黑箱里到底發生了什麼，只需要告訴黑箱需要做什麼工作，這里的HDFS client相當於HDFS與user通信的中間媒介。HDFS client相當於一個軟體包(api)，可以存放在master或者slave或者額外的一個新節點上。
寫入in memory失敗(ACK出現問題)時，master會重新選擇3個新的slave節點。