一hdfs.寫資料流程

• 1.客戶端通過Distributed FileSystem模塊向NameNode請求上傳檔案，NameNode檢查目標檔案是否已存在，父目錄是否存在，
• 2.NameNode回傳是否可以上傳，不能上傳會回傳例外，
• 3.確定可以上傳，客戶端請求第一個block上傳到哪幾個datanode服務器上，
• 4.NameNode回傳3個datanode節點，假定分別為dn1,dn2,dn3，
• 5.客戶端通過FSDataOutputStream模塊請求dn1上傳資料，dn1收到請求會繼續呼叫dn2，然后dn2呼叫dn3，將這個通信管道建立完成，
• 6.dn1,dn2,dn3逐級應答客戶端，
• 7.客戶端開始往dn1上傳第一個block（先從磁盤讀取資料放到一個本地記憶體快取），以packet（64KB）為單位，dn1收到一個packet就會傳給dn2,dn3傳給dn3；dn1每傳一個packet會放入一個應答佇列等待應答，
• 8.當一個block傳輸完成之后，客戶端再次請求NameNode上傳第二個block的服務器，（重復執行3-7步），

二.hdfs讀資料流程

• 1.首先呼叫FileSystem.open()方法，獲取到DistributedFileSystem實體，
• 2.DistributedFileSystem向NameNode發起RPC（遠程程序呼叫）請求獲得檔案的開始部分或全部block串列，對于每個回傳的塊，都包含塊所在的DataNode地址，這些DataNode會按照Hadoop定義的集群拓撲結構得出客戶端的距離，然后再進行排序，如果客戶端本身就是一個DataNode，那么它將從本地讀取檔案，(只會選取一個最近的檔案)
• 3.DistributedFileSystem會向客戶端client回傳一個支持檔案定位的輸入流物件FSDataInputStream,用于客戶端讀取資料，FSDataInputStream包含一個DFSInputStream物件，這個物件用來管理DataNode和NameNode之間的I/O，
• 4.客戶端呼叫read()方法，DFSInputStream就會找出離客戶端最近的datanode并連接datanode.
• 5.DFSInputStream物件中包含檔案開始部分的資料塊所在的DataNode地址，首先它會連接包含檔案第一塊最近的DataNode，隨后，在資料流中重復呼叫read()函式，直到這個塊去全部讀完為止，如果第一個block塊的資料讀完，就會關閉指向第一個block塊的datanode連接，接著讀取下一個block塊，
• 6.如果第一批block都讀完了，DFSInputStream就會去NameNode拿下一批blocks的location,然后繼續讀，如果所有的block塊都讀完，這時就會關閉掉所有的流，
  注意 read方法是并行的讀取block資訊,不是一塊一塊的讀取；NameNode只是回傳Client請求包含塊的DataNode地址，并不是回傳請求塊的資料，最終讀取來所有的block會合并成一個完整的最終檔案，

三.簡單說說HDFS中NameNode,DataNode的作用？

1.NameNode

• 就是Master，它是一個主管，管理者，也叫HDFS的元資料節點，集群中只能有一個Active的NameNode對外提供服務，
  1)管理HDFS的名稱空間（檔案目錄樹）；HDFS很方便的一點就是對于用戶來說很友好，用戶不考慮細節的話，看到的目錄結構和我們使用Window和Linux檔案系統很像，
  2)管理資料塊（Block）映射資訊及副本資訊；一個檔案對應的塊的名字以及塊被存盤在哪里，以及每一個檔案備份多少都是由NameNode來管理，
  3)處理客戶端讀寫請求，

2.DataNode

• 就是Slave，實際存盤資料塊的節點，NameNode下達命令，DataNode執行實際的操作，
  1)存盤實際的資料塊
  2)執行資料庫的讀/寫操作，

四.SecondaryNameNode的作用？或者是NameNode的啟動程序？

SecondaryNameNode有兩個作用:一是鏡像備份,二是日志與鏡像的定期合并,即合并NameNode的edit logs到fsimage檔案中

第一階段：NameNode啟動
1)第一次啟動NameNode格式化后，創建fsimage和edits檔案，如果不是第一次啟動，直接加載編輯日志和鏡像檔案到記憶體，
2)客戶端對元資料進行增刪改的請求，
3)NameNode記錄操作日志，更新滾動日志，
4)NameNode在記憶體中對資料進行增刪改查，

第二階段：Secondary NameNode作業
1)Secondary NameNode詢問NameNode是否需要checkpoint，直接帶回NameNode是否檢查結果，
2)Secondary NameNode請求執行checkpoint，
3)NameNode滾動正在寫的edits日志，
4)將滾動前的編輯日志和鏡像檔案拷貝到Secondary NameNode，
5)Secondary NameNode加載編輯日志和鏡像檔案到記憶體，并合并，
6)生成新的鏡像檔案fsimage.chkpoint，
7)拷貝fsimage.chkpoint到NameNode，
8)NameNode將fsimage.chkpoint重新命名成fsimage，

五.集群安全模式？什么情況下會進入到安全模式？安全模式的解決辦法？

1.進入安全模式的情況

• 集群啟動時必定會進入安全模式：
• NameNode啟動時，首先將鏡像檔案（fsimage）載入記憶體，并執行編輯日志（edits）中的各項操作，一旦在記憶體中成功建立檔案系統元資料的映像，則創建一個新的fsimage檔案和一個空的編輯日志，此時，NameNode開始監聽DataNode請求，但是此刻，NameNode運行在安全模式，即NameNode的檔案系統對于客戶端來說是只讀的，
• 系統中的資料塊的位置并不是由NameNode維護的，而是以塊串列的形式存盤在DataNode中，在系統的正常操作期間，NameNode會在記憶體中保留所有塊位置的映射資訊，在安全模式下，各個DataNode會向NameNode發送最新的塊串列資訊，NameNode了解到足夠多的塊位置資訊之后，即可高效運行檔案系統，
• 如果滿足“最小副本條件”，NameNode會在30秒鐘之后就退出安全模式，所謂的最小副本條件指的是在整個檔案系統中99.9%的塊滿足最小副本級別（默認值：dfs.replication.min=1），在啟動一個剛剛格式化的HDFS集群時，因為系統中還沒有任何塊，所以NameNode不會進入安全模式，

2.例外情況下導致的安全模式

• 原因：block確實有缺失，當namenode發現集群中的block丟失數量達到一個閥值時，namenode就會進入安全模式狀態，不再接受客戶端的資料更新請求，

解決辦法

• 1)調低閥值

<!-- hdfs-site.xml中：-->
<name>dfs.namenode.safemode.threshold</name>
<value>0.999f</name>

• 2)強制離開: hdfs dfsadmin -safemode leave
• 3)重新格式化集群
• 4)修復損壞的塊檔案

六.為什么HDFS不適合小檔案

• HDFS天生就是為存盤大檔案而生的，一個塊的元資料大小大概在150位元組左右，存盤一個小檔案就要占用NameNode150位元組記憶體，如果存盤大量的小檔案很快就將NameNode記憶體耗盡，而整個集群存盤的資料量很小，失去了HDFS的意義，同時也會影響NameNode的尋址時間，導致尋址時間過長，

七.HDFS支持的存盤格式和壓縮演算法？

1.存盤格式

1)SequenceFile
以二進制鍵值對的形式存盤資料，支持三種記錄存盤方式，
? 無壓縮：io效率較差，相對壓縮，不壓縮的情況下沒有什么優勢，
? 記錄級壓縮：對每條記錄都壓縮，這種壓縮效率比較一般，
? 塊級壓縮：這里的塊不同于HDFS中的塊的概念，這種方式會將達到指定塊大小的二進制資料壓縮為一個塊，

2)Avro

• 將資料定義和資料一起存盤在一條訊息中，其中資料定義以JSON格式存盤，資料以二進制格式存盤，Avro標記用于將大型資料集分割成適合MapReduce處理的子集，

3)RCFile

• 以列格式保存每個行組資料，它不是存盤第一行然后是第二行，而是存盤所有行上的第1列，然后是所行上的第2列，以此類推，

4)Parquet

• 是Hadoop的一種列存盤格式，提供了高效的編碼和壓縮方案，

2.壓縮演算法

1)Gzip壓縮

• 優點：壓縮率比較高，而且壓縮/解壓速度也比較快；Hadoop本身支持，在應用中處理gzip格式的檔案就和直接處理文本一樣；大部分Linux系統都自帶gzip命令，使用方便，
• 缺點;不支持split，
• 應用場景：當每個檔案壓縮之后在130M以內的（1個塊大小內），都可以考慮用gzip壓縮格式，例如說一天或者一個小時的日志壓縮成一個gzip檔案，運行MapReduce程式的時候通過多個gzip檔案達到并發，Hive程式，streaming程式，和Java寫的MapReduce程式完全和文本處理一樣，壓縮之后原來的程式不需要做任何修改，

2)Bzip2壓縮

• 優點：支持split；具有很高的壓縮率，比gzip壓縮率都高；Hadoop本身支持，但不支持native；在Linux系統下自帶bzip2命令，使用方便，
• 缺點：壓縮/解壓速度慢；不支持native，
• 應用場景：適合對速度要求不高，但需要較高的壓縮率的時候，可以作為MapReduce作業的輸出格式；或者輸出之后的資料比較大，處理之后的資料需要壓縮存檔減少磁盤空間并且以后資料用得比較少的情況；或者對單個很大的文本檔案想壓縮減少存盤空間，同時又需要支持split，而且兼容之前的應用程式（即應用程式不需要修改）的情況，

3)Lzo壓縮

• 優點：壓縮/解壓速度也比較快，合理的壓縮率；支持split，是Hadoop中最流行的壓縮格式；可以在Linux系統下安裝lzop命令，使用方便，
• 缺點：壓縮率比gzip要低一些；Hadoop本身不支持，需要安裝；在應用中對lzo格式的檔案需要做一些特殊處理（為了支持split需要建索引，還需要指定inputformat為lzo格式），
• 應用場景：一個很大的文本檔案，壓縮之后還大于200M以上的可以考慮，而且單個檔案越大，lzo優點越明顯，

4)Snappy壓縮

• 優點：高速壓縮速度和合理的壓縮率，
• 缺點：不支持split；壓縮率比gzip要低；Hadoop本身不支持，需要安裝；
• 應用場景：當MapReduce作業的Map輸出的資料比較大時，作為Map到Reduce的中間資料的壓縮格式；或者作為一個MapReduce作業的輸出和另外一個MapReduce作業的輸入，

八.HDFS的可靠性策略

1.檔案完整性

• 1)在檔案建立時，每個資料塊都產生校驗和，校驗和會保存在.meta檔案內，
• 2)客戶端獲取資料時可以檢查校驗和是否相同，從而發現資料塊是否損壞，
• 3)如果正在讀取的資料塊損壞，則可以繼續讀取其他副本，NameNode標記該塊已經損壞，然后復制block達到預期設定的檔案備份數，
• 4)DataNode在其檔案創建后三周驗證其checksum，

2.網路或者機器失效時

• 1)副本冗余，
• 2)機架感知策略（副本放置策略），
• 3)心跳機制策略，

3.NameNode掛掉時

• 1)主備切換（高可用），
• 2)鏡像檔案和操作日志磁盤存盤，
• 3)鏡像檔案和操作日志可以存盤多份，多磁盤存盤，

4.其他保障可靠性機制

• 1)快照（和虛擬機快照意義相同，保存了系統某一時刻的影像，可以還原到該時），
• 2)回收站機制，
• 2)安全模式

九.HDFS的優缺點？

1.HDFS優點

• 1)高容錯性：資料自動保存多個副本，副本丟失后，會自動恢復，
• 2)適合批處理：移動計算而非資料，資料位置暴露給計算框架，
• 3)適合大資料處理：GB，TB，甚至PB級資料，百萬規模以上的檔案數量，1000以上節點規模，
• 4)流式檔案訪問：一次性寫入，多次讀取；保證資料一致性，
• 5)可構建在廉價機器上：通過多副本提高可靠性，提供了容錯和恢復機制，

2.HDFS缺點

• 1)不適合低延遲資料訪問：比如毫秒級，低延遲與高吞吐率，
• 2)不適合小檔案存取：占用NameNode大量記憶體，尋道時間超過了讀取時間，
• 3)不適合并發寫入，檔案隨機修改：一個檔案只能有一個寫者，僅支持append，

十.DataNode宕機后，集群能否立即將宕機的DataNode下線？DataNode下線后，集群將進行什么作業？

• 不能立即下線，需要等待10分鐘30秒，
• DataNode下線后，集群將復制下線的datanode管理的塊，

十一.將一個集群重新格式化NameNode后，使用start-dfs.sh啟動集群，DataNode能啟動起來么？為什么？

• 不能，namenode重新格式化后，clusterid改變了，而datanode還保持著原來的clusterid，

十二.DataNode在什么情況下不會備份？

• DataNode在強制關倍訓者非正常斷電不會備份，

十三.3個DataNode中有一個DataNode出現錯誤會怎樣？

• 這個DataNode的資料會在其他的DataNode上重新做備份，

十四.一個DataNode宕機，怎么一個流程恢復

• 將DataNode資料洗掉，重新當成新節點加入即可，