好程序員大數據學習路線分享HDFS總結
好程序員大數據學習路線分享HDFS總結
HDFS介紹
HDFS(Hadoop Distributed File System)是分佈式文件系統,是Hadoop項目的核心子項目.
設計思想:將大文件、大批量文件，分佈式存放在大量服務器上，以便於採取分而治之的方式對海量數據進行運算分析。
HDFS的重要特性
1. HDFS中的文件在物理上是**分塊存儲**(block)，塊的大小可以通過配置參數( dfs.blocksize)來規定，默認大小在hadoop2.x版本中是128M，老版本中是64M
2. HDFS文件系統會給客戶端提供一個**統一的抽象目錄樹**，客戶端通過路徑來訪問文件
3. **目錄結構及文件分塊信息(元數據)**的管理由namenode節點承擔
4. 文件的各個block的存儲管理由datanode節點承擔
5. HDFS是設計成適應一次寫入，多次讀出的場景，且不支持文件的修改
HDFS的優點
1. 高可靠性
Hadoop按位存儲和處理數據的能力強
2. 高擴展性
Hadoop是在可用的計算機集群中分配數據完成計算計算任務
3. 高效性
Hadoop能夠在節點之間動態的移動數據,並保證每個節點的動態平衡
4. 高容錯性
Hadoop能夠自動保存的多個副本,並且能夠自動將失敗的任務重新分配
HDFS的缺點
1. 不適合低延遲訪問,不能快速訪問
HDFS是單Master的，所有的對文件的請求都要經過它，當請求多時，肯定會有延時。它適合高吞吐率的場景，就是在某一時間內寫入大量的數據
2. 無法高效存儲大量小文件
存儲大量小文件的話，它會佔用 NameNode大量的內存來存儲文件、目錄和塊信息(元數據)
3. 不支持多用戶寫入即任意修改文件
僅支持數據append(追加)，不支持文件隨意修改
針對HDFS缺點可能的改進措施
1. 多Master設計，正在研發中的GFS II也要改為分佈式多Master設計，還支持Master的Failover，而且Block大小改為1M，有意要調優處理小文件。（Alibaba DFS的設計，也是多Master設計，它把Metadata的映射存儲和管理分開了，由多個Metadata存儲節點和一個查詢Master節點組成。）
2. 使用緩存或多master設計可以降低client的數據請求壓力，以減少延時。
3. 橫向擴展，一個Hadoop集群能管理的小文件有限，那就把幾個Hadoop集群拖在一個虛擬服務器後面，形成一個大的Hadoop集群。google也是這麼幹過的。
HDFS的Shell命令
| **-help** 輸出命令的手冊 |
| :----------------------------------------------------------- |
| **-ls** 顯示目錄信息 `hadoop fs -ls hdfs://hadoop-server01:9000/` ps：這些參數中，所有的hdfs**路徑都可以簡寫 -->`hadoop fs -ls /` 等同於上一條命令的效果 |
| **-put** 向HDSF上傳文件 `hdfs dfs -put 本地文件路徑 HDFS文件系統路徑` *<易錯：記 源路徑→目的路徑>* |
| **-get** 將HDFS文件系統中的文件下載回來 `hdfs dfs -get HDFS文件系統路徑 本地文件系統路徑` *<易錯>* ps：HDFS有一個和put和get類似的而方法 copyFromlocal 相當於put 和 copyTolocal 相當於 get |
| **-cat** 查看HDFS文件系統中的文件內容 `hdfs dfs -cat HDFS文件系統中文件的路徑` ps:不要查看非文件 |
| **-cp** HDFS文件系統中進行復制操作 `hdfs dfs -cp 源HDFS文件系統中的文件路徑 目標HDFS文件系統中的路徑` |
| **-mv** HDFS文件系統中的文件進行移動操作 `hdfs dfs -mv 源HDFS文件系統中的文件路徑 目標HDFS文件系統中的路徑` ps： 將源文件移動目標路徑,這個命令可允許有多個源路徑,此時目標路徑必須是一個文件夾(目錄)不允許不同的文件系統互相移動文件 |
| **-du** 查看HDFS文件系統中文件的大小 `hdfs dfs -du HDFS文件系統中路徑中的一個文件` |
| **-mkdir** 在HDSF系統中創建文件夾 mkdir 創建文件夾 ps：遞歸創建+`-p` |
| **-rm** 刪除HDFS文件系統中的目錄或文件 `hdfs dfs -rm HDFS文件系統路徑` `hdfs dfs -rm -r HDFS文件系統路徑` ps： 只能是單個文件 或 空目錄，若參數文件夾中有多個文件 加 -r |
| **-chmod** 更改文件的權限 `hdfs dfs -chmod -R 權限值 HDFS文件系統路徑下的文件夾` ps： 所有每三位可以作為一個八進制處理 777是滿權限 rwx ，+R之後， 文件夾下的所有子文件和文件夾都會被修改 |
| **-appendTofile** 追加一個文件到已經存在文件的末尾 `hadoop fs -appendTofile ./hello.txt /hello.txt` |
| **-getmerge** 合併下載多個文件 `hadoop fs -getmerge /aaa/log.* ./log.sum` |
| **-df** 統計文件系統的可用空間信息 `hadoop fs -df -h /` |
| |
HDFS的工作機制
在瞭解工作機制之前，我們先來看看幾個重要角色：
NameNode
1. master，它是一個管理者,維護著整個文件系統的文件目錄樹
2. 儲存數據庫（Block）映射信息，保存元數據信息包括：文件的所屬權,文件的權限,文件大小,時間(Block列表,Block偏移量),位置信息
3. 主要職責：處理客戶端讀寫請求，收集DateNode彙報的Block列表信息<*不會保存到本地系統中*>
**DateNode**
1. Slave，它是一個從節點，簡單理解就是NameNode的奴隸
2. 存儲用戶的文件塊數據
3. 主要職責：定期向NameNode彙報自身所持有的block信息（心跳機制），執行數據塊的讀/寫操作
Secondary NameNode
1. 檢查點節點，表面上看SecondaryNameNode是NameNode的備份,實際上SecondaryNameNode的主要作用並不是備份
2. 主要職責：定期合併fsimage和edit log ，並推送給NameNode
問題引入：一個已經 運行十年的集群，最近的fsimage（鏡像）是NameNode十年前格式化產生，這麼多年的操作日誌被edit log（日誌）記錄已達幾百T。那麼問題來了，如果我要重啟這個集群，這麼大日誌文件，必定要重啟很久，我們的時間並不充裕該 如何解決這個問題？
*<問題提取：只要NameNode不格式化或重新啟動,fsimage將保持原始狀態,edits會不斷的增加 >*
此時我們引入Secondary NameNode， 把PN中的edit log 和fsimage在SN中merge,此時PN還會繼續產生新的日誌,記錄合併和合並期間的操作,合併之後新fsimage會拷貝回PN中,循環上面的操作.以此能保持edit log文件處於比較小的狀態,fsimage的時間點也不會太久遠
**fsimage是如何產生的呢？**
HDFS系統要開始運行的時候需要先對NameNode進行一次格式化,那麼第一次格式化就會產生一個fsimage文件,但是這個文件是個空文件,NameNode啟動的時候會加載fsimage 然後執行edit log加載到內存中,然後立刻向磁盤中寫一個新的fsimage文件,這個fsimage就是一個最新的儲存信息
**緊急情況時，可以輔助恢復NameNode**
namenode和secondary namenode的工作目錄存儲結構完全相同，所以，當namenode故障退出需要重新恢復時，可以從secondary namenode的工作目錄中將fsimage拷貝到namenode的工作目錄，以恢復namenode的元數據
HDFS讀寫數據流程
HDFS讀數據流程
簡單版本
客戶端將要讀取的文件路徑發送給namenode，namenode獲取文件的元信息（主要是block的存放位置信息）返回給客戶端，客戶端根據返回的信息找到相應datanode逐個獲取文件的block並在客戶端本地進行數據追加合併從而獲得整個文件