hdfs怎麼存儲數據

㈠ 大數據之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中的。

㈡ hadoop 中文件是怎麼存儲的

1、存儲文件的時候需要指定存儲的路徑，這個路徑是HDFS的路徑。而不是哪個節點的某個目錄。比如./hadoopfs-putlocalfilehdfspat

一般操作的當前路徑是/user/hadoop比如執行./hadoopfs-ls.實際上就相當於./hadoopfs-ls/user/hadoop

2、HDFS本身就是一個文件系統，在使用的時候其實不用關心具體的文件是存儲在哪個節點上的。如果需要查詢可以通過頁面來查看，也可以通過API來實現查詢。

㈢ 1g的文件在hadoop是怎麼存儲的

hdfs是按塊進行存儲的。1GB文件會劃分成若干塊（默認64MB一個塊，也可以自己配置），然後分配到不同的存儲節點上存儲。
nameserver會記錄哪些塊存儲在哪個節點上，等讀的時候需要訪問nameserver，獲取到不同的數據節點，然後再訪問數據即可。

㈣ 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 的原因。

㈤ hadoop存儲方式

傳統化集中式存儲存在已有一段時間。但大數據並非真的適合集中式存儲架構。Hadoop設計用於將計算更接近數據節點，同時採用了HDFS文件系統的大規模橫向擴展功能。雖然，通常解決Hadoop管理自身數據低效性的方案是將Hadoop數據存儲在SAN上。但這也造成了它自身性能與規模的瓶頸。現在，如果你把所有的數據都通過集中式SAN處理器進行處理，與Hadoop的分布式和並行化特性相悖。你要麼針對不同的數據節點管理多個SAN，要麼將所有的數據節點都集中到一個SAN。但Hadoop是一個分布式應用，就應該運行在分布式存儲上，這樣存儲就保留了與Hadoop本身同樣的靈活性，不過它也要求擁抱一個軟體定義存儲方案，並在商用伺服器上運行，這相比瓶頸化的Hadoop自然更為高效。大數據培訓這么火的原因有很多。注意不要混淆超融合與分布式。某些超融合方案是分布式存儲，但通常這個術語意味著你的應用和存儲都保存在同一計算節點上。這是在試圖解決數據本地化的問題，但它會造成太多資源爭用。這個Hadoop應用和存儲平台會爭用相同的內存和CPU。Hadoop運行在專有應用層，分布式存儲運行在專有存儲層這樣會更好。之後，利用緩存和分層來解決數據本地化並補償網路性能損失。

㈥ HDFS的特點分析以及如何存儲數據

存放到HDFS 一般都是要分析的數據。分析完成的數據直接存儲到MYSQL 或者ORACLE 中。這種處理方式是離線處理。如日誌文件存儲到hdfs 分析出網站的流量 UV PV 等等。一般都是用pig hive 和mr 等進行分析的。 存放到HBASE 一般都是數據拿過來直接用...

㈦ 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並釋放空間。

㈧ 3.4 HDFS存儲原理

一、涉及的問題

1. 冗餘數據保存

2. 數據保存策略

3. 數據恢復

二、冗餘數據保存問題

1. 冗餘因子

出於成本考慮（也是HDFS優勢），HDFS常架構在廉價機器上——經常出故障。所以必須有冗餘機制。一般每個塊都保存3份，即冗餘因子默認是3

注意：偽分布式配置，即名稱節點和數據節點都放在同一個機器上，則冗餘因子顯然只能是1，因為只有一個機器

2. 冗餘機制的好處

(1) 加快數據傳輸速度——當多個客戶端同時想訪問相同數據塊時，可以同時並行而不需要排隊

(2) 很容易檢查數據錯誤——互相對照發現錯誤

(3) 保證數據可靠性——HDFS有這樣的機制：一旦探測到一個副本故障，會自動復制正確副本，使冗餘因子恢復默認值

三、數據保存與讀取

1. 第一副本存放策略：

(1) 如果保存請求來自集群內部，第一個副本放在發起者（應用）所在節點。比如一個在DataNode1上的應用發起存數據請求，那就把它第一份副本也存在DataNode1

(2) 如果保存請求來自集群外部，HDFS會隨機挑選一台磁碟不太忙且CPU不太忙的節點來放置第一個副本

2. 第二個副本存放策略：

放在和第一副本不同的機架的節點上 。如下圖中DataNode4，它和DataNode1在不同機架上

3. 第三副本放置策略：

放在和第一副本相同的機架的其他節點。如圖中的DataNode2或DataNode3

4. 更多副本存放策略：

全部隨機放置（依靠隨機演算法）

5、數據讀取

原則：就近讀取

——HDFS提供一個API可以告訴數據節點的機架ID，客戶端也可以用API診斷自己所在機架ID。ID相同說明在同一機架。而相同機架數據間通信很快，它們就是「相近」的數據。

——而前面也說了，每個數據塊都有多個不同的副本，如果找到某個副本和客戶端在同一個機架上，就優先選此副本。如果沒有就隨機找一個副本讀取

四、數據的錯誤與恢復

1. 名稱節點出錯

只有一個名稱節點，而且它保存了核心數據結構FsImage和EditLog。恢復方法：

(1) 在HDFS1.0里只能暫停服務，從第二名稱節點（冷備份）恢復

(2) 在HDFS2.0里可以直接用熱備份恢復而不用暫停服務

2. 數據節點出錯

(1) 如何發現數據節點出問題：

在整個運行期間，DataNode都會定期通過遠程調用向NameNode發送心跳信息。一旦隔了一個周期收不到心跳信息，則NameNode就知道這個DataNode發生了故障

(2) 如何恢復數據節點：

NameNode會在狀態列表裡把出錯的DataNode標記為不可用（宕機），然後把它裡面的數據塊對應的備份（在其他DataNode上）復制到另一個DataNode上去

——HDFS和其他分布式文件系統最大的區別就是 可以調整冗餘數據位置 。這種調整不僅發生在故障時，也可以在在機器負載不均衡時把一個DataNode的數據遷移到另一個上面以平衡負載

3. 數據出錯

(1) 如何發現數據出錯：

「校驗碼機制」——客戶端每寫入一個數據塊，都會為其生成一個校驗碼並保存在同一文件目錄下。讀取數據塊同時會核對其校驗碼，如果不對說明數據出問題了。

(2) 如何恢復數據：

從備份復制過來

Reference:

https://www.icourse163.org/learn/XMU-1002335004#/learn/content?type=detail&id=1214310117&cid=1217922275&replay=true

㈨ HDFS簡介：不用HDFS我們如何存儲大規模數據

        大數據技術主要是要解決大規模數據的計算處理問題，但是我們要想對數據進行計算，首先要解決的其實是大規模數據的存儲問題。

         如果一個文件的大小超過了一張磁碟的大小，你該如何存儲？ 單機時代，主要的解決方案是 RAID ；分布式時代，主要解決方案是 分布式文件系統 。

           其實不論是在 RAID 還是 分布式文件系統 ，大規模數據存儲都需要解決幾個核心問題，這些問題都是什麼呢？總結一下，主要有以下三個方面。       

        1. 數據存儲容量的問題。 既然大數據要解決的是數以 PB 計的數據計算問題，而一般的伺服器磁碟容量通常 1～2TB，那麼如何存儲這么大規模的數據呢？

        2. 數據讀寫速度的問題。 一般磁碟的連續讀寫速度為幾十 MB，以這樣的速度，幾十 PB 的數據恐怕要讀寫到天荒地老。

        3. 數據可靠性的問題。 磁碟大約是計算機設備中最易損壞的硬體了，通常情況一塊磁碟使用壽命大概是一年，如果磁碟損壞了，數據怎麼辦？

        RAID（獨立磁碟冗餘陣列）技術是將多塊普通磁碟組成一個陣列，共同對外提供服務。主要是為了改善磁碟的存儲容量、讀寫速度，增強磁碟的可用性和容錯能力。目前伺服器級別的計算機都支持插入多塊磁碟，通過使用 RAID 技術，實現數據在多塊磁碟上的並發讀寫和數據備份。

        常用 RAID 技術有圖中下面這幾種，RAID0，RAID1，RAID10，RAID5， RAID6。

           首先，我們先假設伺服器有 N 塊磁碟。

            RAID 0  是數據在從內存緩沖區寫入磁碟時，根據磁碟數量將數據分成 N 份，這些數據同時並發寫入 N 塊磁碟，使得數據整體寫入速度是一塊磁碟的 N 倍；讀取的時候也一樣，因此 RAID 0 具有極快的數據讀寫速度。但是 RAID 0 不做數據備份，N 塊磁碟中只要有一塊損壞，數據完整性就被破壞，其他磁碟的數據也都無法使用了。

            RAID 1 是數據在寫入磁碟時，將一份數據同時寫入兩塊磁碟，這樣任何一塊磁碟損壞都不會導致數據丟失，插入一塊新磁碟就可以通過復制數據的方式自動修復，具有極高的可靠性。

           結合 RAID 0 和 RAID 1 兩種方案構成了 RAID 10 ，它是將所有磁碟 N 平均分成兩份，數據同時在兩份磁碟寫入，相當於 RAID 1；但是平分成兩份，在每一份磁碟（也就是 N/2 塊磁碟）裡面，利用 RAID 0 技術並發讀寫，這樣既提高可靠性又改善性能。不過 RAID 10 的磁碟利用率較低，有一半的磁碟用來寫備份數據。

           一般情況下，一台伺服器上很少出現同時損壞兩塊磁碟的情況，在只損壞一塊磁碟的情況下，如果能利用其他磁碟的數據恢復損壞磁碟的數據，這樣在保證可靠性和性能的同時，磁碟利用率也得到大幅提升。

           順著這個思路， RAID 3  可以在數據寫入磁碟的時候，將數據分成 N-1 份，並發寫入 N-1 塊磁碟，並在第 N 塊磁碟記錄校驗數據，這樣任何一塊磁碟損壞（包括校驗數據磁碟），都可以利用其他 N-1 塊磁碟的數據修復。但是在數據修改較多的場景中，任何磁碟數據的修改，都會導致第 N 塊磁碟重寫校驗數據。頻繁寫入的後果是第 N 塊磁碟比其他磁碟更容易損壞，需要頻繁更換，所以 RAID 3 很少在實踐中使用，因此在上面圖中也就沒有單獨列出。

           相比 RAID 3， RAID 5 是使用更多的方案。RAID 5 和 RAID 3 很相似，但是校驗數據不是寫入第 N 塊磁碟，而是螺旋式地寫入所有磁碟中。這樣校驗數據的修改也被平均到所有磁碟上，避免 RAID 3 頻繁寫壞一塊磁碟的情況。

            如果數據需要很高的可靠性，在出現同時損壞兩塊磁碟的情況下，仍然需要修復數據，這時候可以使用 RAID 6。

             RAID 6 和 RAID 5 類似 ， 但是數據只寫入 N-2 塊磁碟，並螺旋式地在兩塊磁碟中寫入校驗信息（使用不同演算法生成）。

            從下面表格中你可以看到在相同磁碟數目（N）的情況下，各種 RAID 技術的比較。

        現在我來總結一下，看看 RAID 是如何解決我一開始提出的，關於存儲的三個關鍵問題。

         1. 數據存儲容量的問題。 RAID 使用了 N 塊磁碟構成一個存儲陣列，如果使用 RAID 5，數據就可以存儲在 N-1 塊磁碟上，這樣將存儲空間擴大了 N-1 倍。

         2. 數據讀寫速度的問題。 RAID 根據可以使用的磁碟數量，將待寫入的數據分成多片，並發同時向多塊磁碟進行寫入，顯然寫入的速度可以得到明顯提高；同理，讀取速度也可以得到明顯提高。不過，需要注意的是，由於傳統機械磁碟的訪問延遲主要來自於定址時間，數據真正進行讀寫的時間可能只佔據整個數據訪問時間的一小部分，所以數據分片後對 N 塊磁碟進行並發讀寫操作並不能將訪問速度提高 N 倍。

         3. 數據可靠性的問題。 使用 RAID 10、RAID 5 或者 RAID 6 方案的時候，由於數據有冗餘存儲，或者存儲校驗信息，所以當某塊磁碟損壞的時候，可以通過其他磁碟上的數據和校驗數據將丟失磁碟上的數據還原。

        RAID 可以看作是一種垂直伸縮，一台計算機集成更多的磁碟實現數據更大規模、更安全可靠的存儲以及更快的訪問速度。而 HDFS 則是水平伸縮，通過添加更多的伺服器實現數據更大、更快、更安全存儲與訪問。

        RAID 技術只是在單台伺服器的多塊磁碟上組成陣列，大數據需要更大規模的存儲空間和更快的訪問速度。將 RAID 思想原理應用到分布式伺服器集群上，就形成了 Hadoop 分布式文件系統 HDFS 的架構思想。

㈩ HDFS寫數據流程

1）客戶端向namenode請求上傳文件，namenode檢查目標文件是否已存在，父目錄是否存在。

2）namenode返回是否可以上傳。

3）客戶端請求第一個 block上傳到哪幾個datanode伺服器上。

4）namenode返回3個datanode節點，分別為dn1、dn2、dn3。

5）客戶端請求dn1上傳數據，dn1收到請求會繼續調用dn2，然後dn2調用dn3，將這個通信管道建立完成

6）dn1、dn2、dn3逐級應答客戶端（ack響應）

7）客戶端開始往dn1上傳第一個block（先從磁碟讀取數據放到一個本地內存緩存），以packet為單位，dn1收到一個packet就會傳給dn2，dn2傳給dn3；dn1每傳一個packet會放入一個應答隊列等待應答

8）當一個block傳輸完成之後，客戶端再次請求namenode上傳第二個block的伺服器。（重復執行3-7步）

1.客戶端通過調用DistributedFileSystem的create方法創建新文件。

2.DistributedFileSystem通過RPC調用namenode去創建一個沒有blocks關聯的新文件，創建前， namenode會做各種校驗，比如文件是否存在，客戶端有無許可權去創建等。如果校驗通過， namenode就會記錄下新文件，否則就會拋出IO異常。

3.前兩步結束後，會返回FSDataOutputStream的對象，與讀文件的時候相似， FSDataOutputStream被封裝成DFSOutputStream。DFSOutputStream可以協調namenode和 datanode。客戶端開始寫數據到DFSOutputStream，DFSOutputStream會把數據切成一個個小的packet，然後排成隊 列data quene（數據隊列）。

4.DataStreamer會去處理接受data quene，它先詢問namenode這個新的block最適合存儲的在哪幾個datanode里（比如重復數是3，那麼就找到3個最適合的 datanode），把他們排成一個pipeline。DataStreamer把packet按隊列輸出到管道的第一個datanode中，第一個 datanode又把packet輸出到第二個datanode中，以此類推。

5.DFSOutputStream還有一個對列叫ack quene，也是由packet組成，等待datanode的收到響應，當pipeline中的所有datanode都表示已經收到的時候，這時ack quene才會把對應的packet包移除掉。

    如果在寫的過程中某個datanode發生錯誤，會採取以下幾步：

        1)pipeline被關閉掉；

        2)為了防止防止丟包ack quene里的packet會同步到data quene里；

        3)把產生錯誤的datanode上當前在寫但未完成的block刪掉；

        4)block剩下的部分被寫到剩下的兩個正常的datanode中；

        5)namenode找到另外的datanode去創建這個塊的復制。當然，這些操作對客戶端來說是無感知的。

6.客戶端完成寫數據後調用close方法關閉寫入流。

7.DataStreamer把剩餘得包都刷到pipeline里，然後等待ack信息，收到最後一個ack後，通知datanode把文件標視為已完成。

注意：客戶端執行write操作後，寫完的block才是可見的(注:和下面的一致性所對應)，正在寫的block對客戶端

#### 網路拓撲

在本地網路中，兩個節點被稱為「彼此近鄰」是什麼意思？在海量數據處理中，其主要限制因素是節點之間數據的傳輸速率——帶寬很稀缺。這里的想法是將兩個節點間的帶寬作為距離的衡量標准。

​ 節點距離：兩個節點到達最近的共同祖先的距離總和。

例如，假設有數據中心d1機架r1中的節點n1。該節點可以表示為/d1/r1/n1。利用這種標記，這里給出四種距離描述。

Distance(/d1/r1/n1, /d1/r1/n1)=0（同一節點上的進程）

Distance(/d1/r1/n1, /d1/r1/n2)=2（同一機架上的不同節點）

Distance(/d1/r1/n1, /d1/r3/n2)=4（同一數據中心不同機架上的節點）

Distance(/d1/r1/n1, /d2/r4/n2)=6（不同數據中心的節點）

#### 機架感知

- 官方ip地址：

http://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/RackAwareness.html

http://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html#Data_Replication

- 低版本Hadoop副本節點選擇

第一個副本在client所處的節點上。如果客戶端在集群外，隨機選一個。

第二個副本和第一個副本位於不相同機架的隨機節點上。

第三個副本和第二個副本位於相同機架，節點隨機。

- 高副本節點選擇

​ 第一個副本在client所處的節點上。如果客戶端在集群外，隨機選一個。

​ 第二個副本和第一個副本位於相同機架，隨機節點。

​ 第三個副本位於不同機架，隨機節點。