A. 大數據之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中的。
B. HDFS 架構
HDFS 涉及兩個重要進程：NameNode、DataNode。
他們一般都部署單獨部署在不同伺服器上，運行 NameNode 的伺服器是主伺服器，運行 DataNode 的伺服器是從伺服器。主伺服器只有一個，從伺服器有多個。
這種一主多從的架構基本適用於所有分布式系統或框架。可重復使用的架構方案叫作架構模式，一主多從可謂是大數據領域的最主要的架構模式。主伺服器只有一台，掌控全局。從伺服器有很多台，負責具體的事情。這樣很多台伺服器可以有效組織起來，對外表現出一個統一又強大的存儲計算能力。
DataNode 負責文件數據的存儲和讀寫操作，HDFS 將文件數據分割成若干數據塊（Block），每個 DataNode 存儲一部分數據塊，這樣文件就分布存儲在整個 HDFS 伺服器集群中。應用程序客戶端（Client）可以並行對這些數據塊進行訪問，從而使得 HDFS 可以在伺服器集群規模上實現數據並行訪問，極大地提高了訪問速度。
在實踐中，HDFS 集群的 DataNode 伺服器會有很多台，一般在幾百台到幾千台這樣的規模，每台伺服器配有數塊磁碟，整個集群的存儲容量大概在幾 PB 到數百 PB。
NameNode 負責整個分布式文件系統的元數據（MetaData）管理，也就是文件路徑名、數據塊的 ID 以及存儲位置等信息，相當於操作系統中文件分配表（FAT）的角色。HDFS 為了保證數據的高可用，會將一個數據塊復制為多份（默認3份），並將多份相同的數據塊存儲在不同的機架的伺服器上。這樣當有磁碟損壞，或者某個 DataNode 伺服器宕機，甚至某個交換機宕機時，系統能通過其備份的數據塊進行查找。
處理客戶端的請求。
客戶端向 HDFS 上傳文件。
客戶端向 HDFS 讀取文件。
像 NameNode 這樣主從伺服器管理同一份數據的場景，如果從伺服器錯誤地以為主伺服器宕機而接管集群管理，會出現主從伺服器一起對 DataNode 發送指令，進而導致集群混亂，也就是所謂的「腦裂」。這也是這類場景選舉主伺服器時，引入 ZooKeeper 的原因。
C. 下面哪個程序負責hdfs數據存儲
存放到HDFS 一般都是要分析的數據。分析完成的數據直接存儲到MYSQL 或者ORACLE 中。這種處理方式是離線處理。如日誌文件存儲到hdfs 分析出網站的流量 UV PV 等等。一般都是用pig hive 和mr 等進行分析的。 存放到HBASE 一般都是數據拿過來直接用...
D. hdfs有哪些進程並說明其作用
Hadoop分布式文件系統(HDFS)被設計成適合運行在通用硬體(commodity hardware)上的分布式文件系統。它和現有的分布式文件系統有很多共同點。但同時，它和其他的分布式文件系統的區別也是很明顯的。HDFS是一個高度容錯性的系統，適合部署在廉價的機器上。HDFS能提供高吞吐量的數據訪問，非常適合大規模數據集上的應用。HDFS放寬了一部分POSIX約束，來實現流式讀取文件系統數據的目的。HDFS在最開始是作為Apache Nutch搜索引擎項目的基礎架構而開發的。HDFS是Apache Hadoop Core項目的一部分。 Hadoop分布式文件系統架構 1 NameNode（名稱節點） HDFS命名空間採用層次化（樹狀——譯者注）的結構存放文件和目錄。 2 映像和日誌 Inode和定義metadata的系統文件塊列表統稱為Image(映像).NameNode將整個命名空間映像保存在RAM中。而映像的持久化記錄則保存在NameNode的本地文件系統中，該持久化記錄被稱為Checkpoint(檢查點)。NameNode還會記錄HDFS中寫入的操作，並將其存入一個記錄文件，存放在本地文件系統中，這個記錄文件被叫做Journal(日誌)。 3 數據節點 DataNode上的每一個塊(block)副本都由兩個本地文件系統上的文件共同表示。其中一個文件包含了塊（block）本身所需包含的數據，另一個文件則記錄了該塊的元數據，包括塊所含數據大小和文件生成時間戳。數據文件的大小等於該塊（block）的真實大小，而不是像傳統的文件系統一樣，需要用額外的存儲空間湊成完整的塊。因此，如果一個塊里只需要一半的空間存儲數據，那麼就只需要在本地系統上分配半塊的存儲空間即可。 4 HDFS客戶端 用戶應用程序通過HDFS客戶端連接到HDFS文件系統，通過庫文件可導出HDFS文件系統的介面。像很多傳統的文件系統一樣，HDFS支持文件的讀、寫和刪除操作，還支持對目錄的創建和刪除操作。與傳統的文件系統不同的是，HDFS提供一個API用以暴露文件塊的位置。這個功能允許應用程序。 5 檢查點節點 HDFS中的NameNode節點，除了其主要職責是相應客戶端請求以外，還能夠有選擇地扮演一到兩個其他的角色，例如做檢查點節點或者備份節點。該角色是在節點啟動的時候特有的。 6 備份節點 HDFS的備份節點是最近在加入系統的一項特色功能。就像CheckpintNode一樣，備份節點能夠定期創建檢查點，但是不同的是，備份節點一直保存在內存中，隨著文件系統命名空間的映像更新和不斷更新，並與NameNode的狀態隨時保持同步。 7 系統更新和文件系統快照 在軟體更新的過程中，由於軟體的bug或者人為操作的失誤，文件系統損壞的幾率會隨之提升。在HDFS中創建系統快照的目的，就在於把系統升級過程中可能對數據造成的隱患降到最低。快照機制讓系統管理員將當前系統狀態持久化到文件系統中，這樣以來，如果系統升級後出現了數據丟失或者損壞，便有機會進行回滾操作，將HDFS的命名空間和存儲狀態恢復到系統快照進行的時刻。
E. 下面哪個程序負責 hdfs 數據存儲
負責「hdfs」和「數據存儲」的程序是HDFS。
F. HDFS 系統架構
HDFS Architecture
Hadoop Distributed File System (HDFS) 是設計可以運行於普通商業硬體上的分布式文件系統。它跟現有的分布式文件系統有很多相通的地方，但是區別也是顯著的。HDFS具有高度容錯性能，被設計運行於低成本硬體上。HDFS可以向應用提供高吞吐帶寬，適合於大數據應用。HDFS 放寬了一些 POSIX 的要求，以開啟對文件系統數據的流式訪問。HDFS 最初是作為Apache Nutch web 搜索引擎項目的基礎設施開發的。HDFS 現在是 Apache Hadoop 核心項目的一部分。
HDFS是主從架構。一個HDFS集群包含一個NameNode，一個管理文件系統命名空間和控制客戶端訪問文件的master server。以及，若乾的 DataNodes，通常集群的每個node一個，管理運行DataNode的節點上的存儲。HDFS 發布一個文件系統命名空間，並允許用戶數據已文件的形式存儲在上面。內部，一個文件被分成一個或多個塊，存儲在一組DataNodes上。NameNode 執行文件系統命名空間操作，比如：打開、關閉、重命名文件或目錄。它還確定塊到DataNodes的映射。DataNodes 負責向文件系統客戶端提供讀寫服務。DataNodes 根據 NameNode 的指令執行塊的創建、刪除以及復制。
NameNode 和 DataNode 是設計運行於普通商業機器的軟體。這些機器通常運行 GNU/Linux 操作系統。HDFS 是Java 語言編寫的；任何支持Java的機器都可以運行NameNode or DataNode 軟體。使用高移植性Java語言，意味著HDFS可以部署在很大范圍的機器上。一個典型的部署就是一台特定的機器只運行NameNode 軟體，而集群內的其他機器運行DataNode 軟體的一個實例。這種架構不排除一台機器上運行多個DataNodes ，但是在實際部署中很少見。
單 NameNode 節點的存在大大簡化了架構。NameNode 是所有HDFS 元數據的仲裁和倉庫。系統設計上，用戶數據永遠不經過NameNode。
HDFS 支持傳統的文件分級組織。用戶或應用可以創建目錄，並在目錄內存儲文件。 文件系統命名空間的層次結構跟其他文件系統類似；可以創建、刪除、移動、重命名文件。HDFS 支持 user quotas 和 access permissions 。 HDFS 不支持軟、硬鏈接。但是，HDFS 架構不排除實現這些功能。
雖然HDFS遵守 文件系統命名約定 ，一些路徑和名稱 (比如/.reserved 和.snapshot ) 保留了。比如功能 transparent encryption 和 snapshot 就使用的保留路徑。
NameNode 維護文件系統命名空間。任何文件系統命名空間或屬性的變化，都會被NameNode記錄。 應用可以指定HDFS應維護的文件副本數量。文件副本的數量被稱為該文件的復制因子 replication factor 。該信息存儲於NameNode。
HDFS 被設計用於在一個大規模集群上跨機器可靠地存儲巨大的文件。它以一序列的塊的方式存儲文件。每個文件都可以配置塊尺寸和復制因子。
一個文件除了最後一個塊外，其他的塊一樣大。在 append 和 hsync 添加了可變長度塊的支持後，用戶可以啟動一個新的塊，而不用填充最後一個塊到配置的塊大小。
應用可以指定一個文件的副本數量。復制因子可以在創建的時候指定，也可以以後更改。HDFS的文件只寫一次(除了 appends 和 truncates) ，並在任何時候只允許一個 writer 。
NameNode 指定塊復制的所有決策。它周期性的從集群的每個DataNodes 接受 Heartbeat 和 Blockreport。Heartbeat 的接受代表 DataNode 工作正常。Blockreport 包含了DataNode上所有塊的清單。
副本的位置對HDFS的可靠性和性能至關重要。副本位置的優化是HDFS和其他大多數分布式文件系統的區別。這是一個需要大量調優和經驗的特性。Rack-aware 復制策略的目的就是提高數據可靠性，可用性和網路帶寬利用率。當前副本位置策略的實現是這個方向的第一步。實施該策略的短期目標是在生產環境驗證它，了解其更多的行為，為測試和研究更復雜的策略打下基礎。
大型HDFS實例運行在跨多個Rack的集群伺服器上。不同rack的兩個node通信需要通過交換機。大多數情況下，同一rack內的帶寬大於rack之間的帶寬。
NameNode 通過在 Hadoop Rack Awareness 內的進程描述 判斷DataNode 屬於哪個rack id。一個簡單但是並非最佳的策略是將副本分布於不同的racks。這可以防止整個機架發生故障時丟失數據，並允許在讀取數據時使用多個機架的帶寬。該策略在群集中均勻地分布副本，使得組件故障時很容易平衡負載。 但是，該策略會增加寫入成本，因為寫入操作需要將塊傳輸到多個機架。
一般，復制因子設置為3， HDFS 的分布策略是：如果writer在datanode上則將一個副本放到本地機器， 如果writer不在datanode上則將一個副本放到writer所在機櫃的隨機datanode 上；另一個副本位於不同機架的node上；最後一個副本位於同一遠程機架的不同node上。 該策略減少了機架間的寫流量，提升了寫性能。機架故障的概率遠小於節點故障的概率；此策略不會影響數據可靠性和可用性承諾。但是，在讀取數據時，它確實減少了聚合帶寬，因為塊存儲於兩個機櫃而不是三個機櫃內。使用此策略，副本不會均勻的分布於機架上。1/3 副本 位於同一節點， 2/3 副本位於同一機架， 另1/3副本位於其他機架。該策略提升了寫性能而不影響數據可靠性和讀性能。
如果復制因子大於3，那麼第4個及以後的副本則隨機放置，只要滿足每個機架的副本在(replicas - 1) / racks + 2)之下。
因為 NameNode 不允許 DataNodes 擁有同一個塊的多個副本，所以副本的最大數就是DataNodes的數量。
在把對 存儲類型和存儲策略 的支持添加到 HDFS 後，除了上面介紹的rack awareness外， NameNode 會考慮其他副本排布的策略。NameNode 先基於rack awareness 選擇節點，然後檢查候選節點有文件關聯的策略需要的存儲空間。 如果候選節點沒有該存儲類型， NameNode 會查找其他節點。如果在第一條路徑中找不到足夠的節點來放置副本，NameNode會在第二條路徑中查找具有回滾存儲類型的節點。 、
當前，這里描述的默認副本排布策略正在使用中。
為了最小化全局帶寬消耗和讀取延遲， HDFS 會嘗試從最靠近reader的副本響應讀取請求。如果在reader節點的同一機架上上存在副本，則該副本有限響應讀請求。如果HDFS集群跨多個數據中心，則本地數據中心優先。
啟動時，NameNode 會進入一個稱為 Safemode 的特殊狀態。當NameNode處於Safemode狀態時，不會復制數據塊。NameNode從DataNodes接收Heartbeat和Blockreport消息。Blockreport包含DataNode託管的數據塊列表。每個塊都指定了最小副本數。當數據塊的最小副本數已與NameNode簽入時，該塊被認為是安全復制的。在NameNode簽入安全復制數據塊的已配置百分比（加上額外的30秒）後，NameNode退出Safemode狀態。然後，它判斷列表內的數據塊清單是否少於副本指定的數量。NameNode 然後復制這些塊給其他 DataNodes。
HDFS 命名空間由 NameNode 存儲。NameNode 使用事務日誌 EditLog 來持久化的保存系統元數據的每次變更。比如，在HDFS創建一個新文件，NameNode會在 EditLog 插入一條記錄來指示該變更。類似的，變更文件的復制因子也會在 EditLog 插入一條新記錄。NameNode 以文件的形式，將 EditLog 保存在本地OS文件系統上。整個文件系統命名空間，包括塊到文件的映射、文件系統屬性，都存儲於名字為 FsImage 的文件內。 FsImage 也以文件的形式，存儲在NameNode的本地文件系統上。
NameNode 將包含整個文件系統和塊映射的image保存在內存中。當NameNode啟動時，或檢查點被預先定義的閾值觸發時，它會從磁碟讀取 FsImage 和 EditLog ，把 EditLog 內的事物應用到內存中的FsImage，再將新版本刷新回磁碟的新 FsImage 。然後會截斷舊的 EditLog ，因為它的事物已經應用到了持久化的 FsImage 上。 這個過程稱為檢查點 checkpoint 。檢查點的目的是通過對文件系統元數據進行快照並保存到FsImage，來確保HDFS擁有文件系統元數據的一致性視圖。盡管讀取 FsImage 是高效的，但是對 FsImage 直接增量修改是不高效的。不是對每次編輯修改 FsImage ，而是將每次編輯保存到 Editlog 。在檢查點期間，將 Editlog 的變更應用到 FsImage 。一個檢查點可以在固定周期(dfs.namenode.checkpoint.period)(以秒為單位)觸發，也可以文件系統事物數量達到某個值(dfs.namenode.checkpoint.txns)的時候觸發。
DataNode 在本地文件系統上以文件的形式存儲 HDFS data 。DataNode 不知道 HDFS 文件。它將HDFS data 的每個塊以獨立的文件存儲於本地文件系統上。DataNode 不在同一目錄創建所有的文件。而是，使用heuristic來確定每個目錄的最佳文件數量，並適當的創建子目錄。在一個目錄創建所有的本地文件是不好的，因為本地文件系統可能不支持單目錄的海量文件數量。當DataNode啟動的時候，它掃描本地文件系統，生成與本地文件系統一一對應的HDFS數據塊列表，然後報告給NameNode。這個報告稱為 Blockreport。
所有的HDFS通信協議都在TCP/IP協議棧上。客戶端與NameNode指定的埠建立連接。與NameNode以ClientProtocol 通信。DataNodes與NameNode以DataNode Protocol進行通信。遠程過程調用(RPC)封裝了Client Protocol 和 DataNode Protocol。設計上，NameNode從不啟動任何RPCs。相反，它只應答DataNodes or clients發出的RPC請求。
HDFS的主要目標是可靠的存儲數據，即使是在故障的情況下。常見故障類型有三種： NameNode failures , DataNode failures 和 network partitions 。
每個DataNode都周期性的向NameNode發送心跳信息。 一個 network partition 可能導致DataNodes子集丟失與NameNode的連接。NameNode會基於心跳信息的缺失來偵測這種情況。NameNode將沒有心跳信息的DataNodes標記為 dead ，並不再轉發任何IO請求給它們。任何注冊到dead DataNode的數據對HDFS將不再可用。DataNode death會導致某些塊的復制因子低於它們指定的值。NameNode不斷跟蹤需要復制的塊，並在必要時啟動復制。很多因素會導致重新復制：DataNode不可用，副本損壞，DataNode上硬碟故障，復制因子增加。
標記 DataNodes dead 的超時時間保守地設置了較長時間 (默認超過10分鍾) 以避免DataNodes狀態抖動引起的復制風暴。對於性能敏感的應用，用戶可以設置較短的周期來標記DataNodes為過期，讀寫時避免過期節點。
HDFS 架構支持數據再平衡schemes。如果一個DataNode的空餘磁碟空間低於閾值，sheme就會將數據從一個DataNode 移動到另外一個。在某些文件需求突然增長的情況下，sheme可能會在集群內動態的創建額外的副本，並再平衡其他數據。這些類型的數據再平衡schemes還沒有實現。
有可能從DataNode獲取的數據塊，到達的時候損壞了。這種損壞可能是由於存儲設備故障、網路故障、軟體bug。HDFS客戶端軟體會HDFS的內容進行校驗。當客戶端創建HDFS文件的時候，它計算文件每個塊的校驗值，並以獨立的隱藏文件存儲在同一HDFS命名空間內。當客戶端檢索文件時候，它會校驗從每個DataNode獲取的數據，是否與關聯校驗文件內的校驗值匹配。 如果不匹配，客戶端可以從另外擁有副本塊的DataNode檢索。
FsImage 和 EditLog 是HDFS的核心數據結構。這些文件的損壞將導致HDFS實例異常。 因此，NameNode可以配置為支持多 FsImage 和 EditLog 副本模式。任何對 FsImage or EditLog 的更新都會導致每個 FsImages 和 EditLogs 的同步更新。 FsImage 和 EditLog 的同步更新會導致降低命名空間每秒的事物效率。但是，這種降級是可以接受的，因為HDFS應用是數據密集型，而不是元數據密集型。當NameNode重啟的時候，它會選擇最新的一致的 FsImage 和 EditLog 。
另外一種提供故障恢復能力的辦法是多NameNodes 開啟HA，以 shared storage on NFS or distributed edit log (called Journal)的方式。推薦後者。
Snapshots - 快照，支持在特定時刻存儲數據的副本。快照功能的一個用法，可以回滾一個故障的HDFS實例到已知工作良好的時候。
HDFS被設計與支持超大的文件。與HDFS適配的軟體都是處理大數據的。這些應用都只寫一次，但是它們會讀取一或多次，並且需要滿足流式讀速度。HDFS支持文件的 一次寫入-多次讀取 語義。 HDFS典型的塊大小是128 MB.。因此，HDFS文件被分割為128 MB的塊，可能的話每個塊都位於不同的DataNode上。
當客戶端以復制因子3寫入HDFS文件時，NameNode以 復制目標選擇演算法 replication target choosing algorithm 檢索DataNodes 列表。該列表包含了承載該數據塊副本的DataNodes清單。然後客戶端寫入到第一個DataNode。第一DataNode逐步接受數據的一部分，將每一部分內容寫入到本地倉庫，並將該部分數據傳輸給清單上的第二DataNode。第二DataNode，按順序接受數據塊的每個部分，寫入到倉庫，然後將該部分數據刷新到第三DataNode。最終，第三DataNode將數據寫入到其本地倉庫。
因此，DataNode從管道的前一個DataNode獲取數據，同時轉發到管道的後一個DataNode。因此，數據是以管道的方式從一個DataNode傳輸到下一個的。
應用訪問HDFS有很多方式。原生的，HDFS 提供了 FileSystem Java API 來給應用調用。還提供了 C language wrapper for this Java API 和 REST API 。另外，還支持HTTP瀏覽器查看HDFS實例的文件。 通過使用 NFS gateway ，HDFS還可以掛載到客戶端作為本地文件系統的一部分。
HDFS的用戶數據是以文件和目錄的形式組織的。它提供了一個命令行介面 FS shell 來提供用戶交互。命令的語法類似於其他shell (比如：bash, csh)。如下是一些範例：
FS shell 的目標是向依賴於腳本語言的應用提供與存儲數據的交互。
DFSAdmin 命令用於管理HDFS集群。這些命令僅給HDFS管理員使用。如下範例：
如果啟用了回收站配置，那麼文件被 FS Shell 移除時並不會立即從HDFS刪除。HDFS會將其移動到回收站目錄(每個用戶都有回收站，位於 /user/<username>/.Trash )。只要文件還在回收站內，就可以快速恢復。
最近刪除的文件大多數被移動到 current 回收站目錄 ( /user/<username>/.Trash/Current )，在配置周期內，HDFS給 current目錄內的文件創建檢查點 checkpoints (位於 /user/<username>/.Trash/<date> ) ，並刪除舊的檢查點。參考 expunge command of FS shell 獲取更多關於回收站檢查點的信息。
在回收站過期後，NameNode從HDFS命名空間刪除文件。刪除文件會將文件關聯的塊釋放。注意，在用戶刪除文件和HDFS增加free空間之間，會有一個明顯的延遲。
如下範例展示了FS Shell如何刪除文件。我們在delete目錄下創建兩個文件(test1 & test2)
我們刪除文件 test1。如下命令顯示文件被移動到回收站。
現在我們嘗試以skipTrash參數刪除文件，該參數將不將文件發送到回收站。文件將會從HDFS完全刪除。
我們檢查回收站，只有文件test1。
如上，文件test1進了回收站，文件test2被永久刪除了。
當縮減文件的復制因子時，NameNode選擇可以被刪除的多餘副本。下一個Heartbeat會通報此信息給DataNode。DataNode然後會刪除響應的塊，相應的剩餘空間會顯示在集群內。同樣，在setReplication API調用完成和剩餘空間在集群顯示之間會有一個時間延遲。
Hadoop JavaDoc API .
HDFS source code: http://hadoop.apache.org/version_control.html
G. 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並釋放空間。