HDFS：Hadoop Distributed File System Hadoop 分佈式文件系統
將大文件，大批量文件，分佈式的存放於大量服務器上。以便於採取分而治
之的方式對海量數據進行運算分析；
HDFS 設計思路：
1.大文件被切割成小文件，使用分而治之的思想讓很多服務器對同一個文件進行聯合管理
2.每個小文件做冗餘備份，並且分散存到不同的服務器，做到高可靠不丟失
HDFS 架構：
主節點 Namenode：集羣老大，掌管文件系統目錄樹，處理客戶端讀且請求
SecondaryNamenode：嚴格 說並不是 namenode 備份節點，主要給 namenode 分擔壓力之用
從節點 Datanode ：存儲整個集羣所有數據塊，處理真正數據讀寫
重要特性如下：
1、HDFS 中的文件在物理上是分塊存儲（block），塊的大小可以通過配置參數(dfs.blocksize)
來規定，默認大小在 hadoop2.x 版本中是 128M，老版本中是 64M
2、HDFS 文件系統會給客戶端提供一個統一的抽象目錄樹，客戶端通過路徑來訪問文件，形
如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data
hdfs://hadoop02:9000/soft/hadoop-2.6.5-centos-6.7.tar.gz
3、目錄結構及文件分塊位置信息(元數據)的管理由 namenode 節點承擔
namenode 是 HDFS 集羣主節點，負責維護整個 hdfs 文件系統的目錄樹，以及每一個路徑（文
件）所對應的 block 塊信息（block 的 id，及所在的 datanode 服務器）
4、文件的各個 block 的存儲管理由 datanode 節點承擔
datanode 是 HDFS 集羣從節點，每一個 block 都可以在多個 datanode 上存儲多個副本（副本
數量也可以通過參數設置 dfs.replication，默認是 3）
- HDFS 是設計成適應一次寫入，多次讀出的場景，且不支持文件的修改
HDFS的優點：
可構建在廉價機器上
通過多副本提高可靠性，提供了容錯和恢復機制
高容錯性
數據自動保存多個副本，副本丟失後，自動恢復
適合批處理
移動計算而非數據，數據位置暴露給計算框架
適合大數據處理
GB、TB、甚至 PB 級數據，百萬規模以上的文件數量，10K+節點規模
流式文件訪問
一次性寫入，多次讀取，保證數據一致性
HDFS缺點：
不適於以下操作：
低延遲數據訪問
比如毫秒級
低延遲與高吞吐率
小文件存取
佔用 NameNode 大量內存 150b* 1000W = 15E,1.5G
尋道時間超過讀取時間
併發寫入、文件隨機修改
一個文件只能有一個寫者
僅支持 append
JAVA API:
Hadoop心跳機制：
Hadoop 是 Master/Slave 結構，Master 中有 NameNode 和 ResourceManager，Slave 中有
Datanode 和 NodeManager，NameNode 通過心跳得知 Datanode 的狀態
ResourceManager 通過心跳得知 NodeManager 的狀態
Namenode 感知到 Datanode 掉線死亡的時長計算：
HDFS 默認的超時時間爲 10 分鐘+30 秒。
這裏暫且定義超時時間爲 timeout
計算公式爲：
timeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval
而默認的 heartbeat.recheck.interval 大小爲 5 分鐘，dfs.heartbeat.interval 默認的大小爲 3 秒。
需要注意的是 hdfs-site.xml 配置文件中的 heartbeat.recheck.interval 的單位爲毫秒，
dfs.heartbeat.interval 的單位爲秒
HDFS 安全模式：
namenode 發現集羣中的 block 丟失率達到一定比例時（0.1%），namenode 就會進入
安全模式，在安全模式下，客戶端不能對任何數據進行操作，只能查看元數據信息（比
Stay hungry Stay foolish -- http://blog.csdn.net/zhongqi2513
如 ls/mkdir）
正常啓動的時候進入安全的原理：
(原理：namenode 的內存元數據中，包含文件路徑、副本數、blockid，及每一個 block 所在datanode 的信息，而 fsimage 中，不包含 block 所在的 datanode 信息，那麼，當 namenode冷啓動時，此時內存中的元數據只能從 fsimage 中加載而來，從而就沒有 block 所在的datanode 信息——>就會導致 namenode 認爲所有的 block 都已經丟失——>進入安全模式——>datanode 啓動後，會定期向 namenode 彙報自身所持有的 blockid 信息，——>隨着datanode 陸續啓動，從而陸續彙報 block 信息，namenode 就會將內存元數據中的 block 所在 datanode 信息補全更新——>找到了所有 block 的位置，從而自動退出安全模式)
HDFS 副本存放策略：
將每個文件的數據進行分塊存儲，每一個數據塊又保存有多個副本，這些數據塊副本分
布在不同的機器節點上。
在多數情況下，HDFS 默認的副本系數是 3，第一個block副本放在和client所在的node裏（如果client不在集羣範圍內，則這第一個node是隨機選取的，系統會嘗試不選擇哪些太滿或者太忙的 node）。
第二個副本放置在與第一個節點不同的機架中的 node 中（近乎隨機選擇，系統會嘗試不選擇哪些太滿或者太忙的 node）。第三個副本和第二個在同一個機架，隨機放在不同的 node 中。
修改副本數：
第一種方式：修改集羣文件 hdfs-site.xml
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
第二種方式：命令設置
bin/hadoop fs -setrep -R 1 /
負載均衡：
機器與機器之間磁盤利用率不平衡是 HDFS 集羣非常容易出現的情況
尤其是在 DataNode 節點出現故障或在現有的集羣上增添新的 DataNode 的時候分析數據塊分佈和重新均衡 DataNode 上的數據分佈的工具，自動進行均衡非常慢，一天能移動的數據量在 10G-10T 的級別，很難滿足超大集羣的需求原因：HDFS 集羣默認不允許 balance 操作佔用很大的網絡帶寬，這個帶寬是可以調整的
NAMENODE和DATANODE:
1、負責客戶端請求（讀寫數據請求）的響應
2、維護目錄樹結構（元數據的管理：查詢，修改）
3、配置和應用副本存放策略
4、管理集羣數據塊負載均衡問題
datanode 負責管理用戶的文件數據塊，並且通過心跳機制彙報給 namenode
datanode 會定期向 namenode 彙報自身所保存的文件 block 信息，而 namenode 則會負責保持文件的副本數量
HDFS 的內部工作機制對客戶端保持透明，客戶端請求訪問 HDFS 都是通過向 namenode
申請來進行
HDFS 寫數據流程：
1、 client 發寫數據請求
2、 namenode 響應請求，然後做一系列校驗，如果能上傳該數據，則返回該文件的所有切
塊應該被存在哪些 datanode 上的 datanodes 列表:
blk-001:hadoop02 hadoop03
blk-002:hadoop03 hadoop04
3、 client 拿到 datanode 列表之後，開始傳數據
4、 首先傳第一塊 blk-001，datanode 列表就是 hadoop02,hadoop03, client 就把 blk-001 傳到hadoop02 和 hadoop03 上
5、 ……… 用傳第一個數據塊同樣的方式傳其他的數據塊
6、 當所有的數據塊都傳完之後，client 會給 namenode 返回一個狀態信息，表示數據已全部寫入成功，或者是失敗的信息
7、 namenode 接收到 client 返回的狀態信息來判斷當次寫入數據的請求是否成功，如果成功，就需要更新元數據信息
namenode做的檢查操作：
- 對client的請求進行合理性檢查（是否上傳的文件已存在等）
- Client的權限是否符合
詳細步驟文字說明
1、使用 HDFS 提供的客戶端 Client，向遠程的 namenode 發起 RPC 請求
2、namenode 會檢查要創建的文件是否已經存在，創建者是否有權限進行操作，成功則會
爲文件創建一個記錄，否則會讓客戶端拋出異常；
3、當客戶端開始寫入文件的時候，客戶端會將文件切分成多個 packets，並在內部以數據隊列“data queue（數據隊列）”的形式管理這些 packets，並向 namenode 申請 blocks，獲取用來存儲 replicas 的合適的 datanode 列表，列表的大小根據 namenode 中 replication的設定而定；
4、開始以 pipeline（管道）的形式將 packet 寫入所有的 replicas 中。客戶端把 packet 以流的方式寫入第一個 datanode，該 datanode 把該 packet 存儲之後，再將其傳遞給在此 pipeline中的下一個 datanode，直到最後一個 datanode，這種寫數據的方式呈流水線的形式。
5、最後一個 datanode 成功存儲之後會返回一個 ack packet（確認隊列），在 pipeline 裏傳遞至客戶端，在客戶端的開發庫內部維護着"ack queue"，成功收到 datanode 返回的 ack
packet 後會從"data queue"移除相應的 packet。
6、如果傳輸過程中，有某個 datanode 出現了故障，那麼當前的 pipeline 會被關閉，出現故障的 datanode 會從當前的 pipeline 中移除，剩餘的 block 會繼續剩下的 datanode 中繼續以 pipeline 的形式傳輸，同時 namenode 會分配一個新的 datanode，保持 replicas 設定的數量。
7、客戶端完成數據的寫入後，會對數據流調用 close()方法，關閉數據流；
8、只要寫入了 dfs.replication.min（最小寫入成功的副本數）的複本數（默認爲 1），寫操作就會成功，並且這個塊可以在集羣中異步複製，直到達到其目標複本數（dfs.replication
的默認值爲 3），因爲 namenode 已經知道文件由哪些塊組成，所以它在返回成功前只需
要等待數據塊進行最小量的複製。
HDFS 讀數據流程：
客戶端將要讀取的文件路徑發送給 namenode，namenode 獲取文件的元信息（主要是 block的存放位置信息）返回給客戶端，客戶端根據返回的信息找到相應 datanode 逐個獲取文件的 block 並在客戶端本地進行數據追加合併從而獲得整個文件。
詳細文字說明
1、使用 HDFS 提供的客戶端 Client，向遠程的 namenode 發起 RPC 請求；
2、namenode 會視情況返回文件的全部 block 列表，對於每個 block，namenode 都會返回有該 block 拷貝的 datanode 地址；
3、客戶端Client會選取離客戶端最近的datanode來讀取block；如果客戶端本身就是datanode，那麼將從本地直接獲取數據；
4、讀取完當前 block 的數據後，關閉當前的 datanode 鏈接，併爲讀取下一個 block 尋找最佳的 datanode；
5、當讀完列表 block 後，且文件讀取還沒有結束，客戶端會繼續向 namenode 獲取下一批的block 列表；
6、讀取完一個 block 都會進行 checksum 驗證，如果讀取 datanode 時出現錯誤，客戶端會通知 namenode，然後再從下一個擁有該 block 拷貝的 datanode 繼續讀。
NameNode 元數據管理：
NameNode 對數據的管理採用了 兩 種存儲形式：內存和磁盤
首先是 內存中存儲了一份完整的元數據，包括目錄樹結構，以及文件和數據塊和副本存儲地的映射關係；
1 、 內存元數據 metadata（全部存在內存中）
其次是在 磁盤中也存儲了一份完整的元數據。有三種格式：
2 、 磁盤元數據鏡像文件 fsimage_0000000000000000555 fsimage_0000000000000000555
等價於
edits_0000000000000000001-0000000000000000018
……
edits_0000000000000000444-0000000000000000555
合併之和
3 、 數據 歷史 操作日誌文件 edits ：edits_0000000000000000001-0000000000000000018
（可通過日誌運算出元數據，全部存在磁盤中）
4 、數據預寫操作日誌文件 edits_inprogress_0000000000000000556
（存儲在磁盤中）
metadata = 最新 fsimage_0000000000000000555 + edits_inprogress_0000000000000000556
metadata = 所有的 edits 之和（edits_001_002 + …… + edits_444_555 + edits_inprogress_556）
核心：
HDFS中的namenode每次在進行元數據的修改相關操作時，都會記錄日誌到最新的edist_inprogress中。當edist_inprogress超過了某個標準時，就進行滾動生成新的 edist_x_y這種格式的日誌文件。當edist_x_y這種格式的日誌文件變多時，那麼又會被合併成fsimage_xx這種格式的文件。由於fsimage是被序列化了之後的一個鏡像文件，所以它是能夠被快速加載到內存中的最合理的存儲格式。元數據的 CheckPoint每隔一段時間，會由 secondary namenode 將 namenode 上積累的所有 edits 和一個最新的fsimage 下載到本地，並加載到內存進行 merge（這個過程稱爲 checkpoint）
SecondaryNamenode 工作機制
把最新的fsimage文件和最新的edists進行合併，分擔 namenode 的合併元數據的壓力。所以在配置
SecondaryNamenode 的工作節點時，一定切記，不要和 namenode 處於同一節點。