hdfs的四大核心和兩大機制

1.心跳機制：

叢集主從模式，主節點namenode，從節點datanode，datanode和namenode是需要通訊的，通訊通過心跳的方式進行通訊的。datanode向namenode定期傳送心跳報告，報告自己的存活狀態，和自己儲存的塊資訊。

如果一個datanode宕機了，namenode怎麼判定datanode一定宕機了？10次心跳報告收不到，如果10次都接收不到，這個時候namenode會主動檢查，向datanode傳送檢查報告，檢查datanode是否真的宕機了。一次檢查報告可能存在網路延時或者通訊問題，namenode會發送兩次檢查，如果兩次檢查都沒有得到迴應，這個時候才認為datanode宕機。

時間是多少？
一次報告時間：3s

<property>
  <name>dfs.heartbeat.interval</name>
  <value>3</value>
  <description>Determines datanode heartbeat interval in seconds.</description>
</property>

一次檢查的時間是多少？300000ms

<property>
  <name>dfs.namenode.heartbeat.recheck-interval</name
 
>
  <value>300000</value>
  <description>
    This time decides the interval to check for expired datanodes.
    With this value and dfs.heartbeat.interval, the interval of
    deciding the datanode is stale or not is also calculated.
    The unit of this configuration is millisecond.
  </description>
</property
 
>

2、安全模式

hdfs dfsadmin [-safemode enter | leave | get | wait]

hdfs啟動的時候，做了哪些事情？

1.元資料儲存了：1）抽象目錄樹 2）資料和塊的對應關係 3）塊的儲存位置

2.元資料存在磁碟上：讀寫慢，只存了1）抽象目錄樹 2）資料和塊的對應關係， 並沒有儲存塊的儲存位置

3.元資料儲存在記憶體：元資料包含1）抽象目錄樹 2）資料和塊的對應關係 3）塊的儲存位置。一旦機器宕機，記憶體中的元資料就丟失了。

4.叢集啟動，程序啟動順序：namenode>>>>>datanode>>>>>secondarynamenode

5.叢集啟動的時候：會將磁碟上的元資料載入到記憶體中，

磁碟中的元資料只有：1）抽象目錄樹 2）資料和塊的對應關係， 沒有 3）塊的儲存位置。磁碟上僅僅會儲存一個空的節點列表，這個節點列表是在datanode傳送心跳報告之後填上的。例如：：/aa/hadoop2.7.6.tar.gz [blk_237838365:[],blk_237838366:[]]

而塊的儲存位置是在datanode向namenode傳送心跳報告的時候彙報的
，datanode向namenode彙報自己身上的塊的儲存資訊。例如：hadoop01:blk_237838365，blk_237838366，blk_237838367

然後記憶體接收datanode的心跳包 ，補全塊的儲存位置列表整。例如：/aa/hadoop2.7.6.tar.gz [blk_237838365:[hadoop01,hadoop02],blk_237838366:[hadoop01]]

7.進行檢查塊的完整度，進行缺的塊的複製工作。在這個期間，叢集不對外提供服務的，叢集處於安全模式，安全模式下使用者不能對叢集進行操作。
如果說在這個期間，叢集的塊報告有99.99%正常，叢集會自動退出安全模式。安全模式下叢集處於一個自我保護的狀態，會進行塊的檢查和複製的工作

8.手動進入安全模式：hdfs dfsadmin -safemode enter 進入安全模式/leave 離開安全模式/wait 等待安全模式退出/get 獲取當前安全模式的狀態

9.在安全模式下哪些操作可以執行，哪些不可以執行？

修改元資料的操作都不可以執行：建立資料夾，上傳，檔案刪除需要修改元資料，不可以執行。例如mkdir，rm，put

檢視，下載僅僅是讀取元資料，可以執行。例如：ls，cat，get

3.機架策略

hdfs儲存塊副本份數，預設情況的下：副本3分。相同的副本不可能儲存在同一個節點上，存在一個節點沒有意義。

1）第一份副本放在客戶端所在機器，如果客戶端不是叢集中的節點 任意選一臺存放

2）第二個副本放在和第一個副本不同機架的任意節點上。目的是：怕機架斷電

3）第三個副本放在與第二個副本相同機架的不同節點上

實際生產中的機架策略：實際生產中機架很多個，資料中心也可能有很多，備份的資料中心。從不同節點，不同機架，不同資料中心去記憶，主要思想是用空間換資料安全

4.負載均衡

1.叢集中的每個節點儲存的資料的壓力均衡的。負載均衡與硬體配置有關。
正常情況下，叢集可以自動實現負載均衡，叢集會在叢集空閒的時候進行負載均衡。

2.預設情況下叢集在進行自動負載均衡的時候的頻寬預設最大是1M，叢集在進行自動負載均衡的時候是很慢的

        <property>
            指定叢集進行自動負載均衡的最大頻寬
          <name>dfs.datanode.balance.bandwidthPerSec</name>
          <value>1048576</value>
          <description>
                Specifies the maximum amount of bandwidth that each datanode
                can utilize for the balancing purpose in term of
                the number of bytes per second.
          </description>
        </property>

3.叢集規模比較小（20節點）的時候可以依賴叢集的自動負載均衡，當叢集的規模比較大的時候，依賴叢集的自動的負載均衡就太慢了，我們可以手動啟動負載均衡

（1）使用命令：start-balancer.sh，這個命令不會立即執行，只是 通知叢集及時進行負載均衡

（2）調大叢集負載均衡的頻寬
            <property>
                    指定叢集進行自動負載均衡的最大頻寬
                 <name>dfs.datanode.balance.bandwidthPerSec</name>
                 <value>1048576</value>
                <description>
                 Specifies the maximum amount of bandwidth that each datanode
                 can utilize for the balancing purpose in term of
                 the number of bytes per second.
                </description>
            </property>

（3）start-balancer.sh -t 10%
    -t 10%： 任意節點在進行負載均衡的時候，最大節點的的容量佔比-最小節點的容量佔比不超過10%，就預設叢集的負載已經均衡了，例如：在此條件下，如下叢集是負載均衡的
            hadoop01    8T        4T         50%
            hadoop02    4T        2.1T       52.5%
            hadoop03    6T        3.2T       53.3%
            3.3%

檔案上傳—寫資料的流程

hadoop fs -put src dst

1.檔案分塊：
物理分塊：真正的進行切分，例如hadoop.tar.gz blk_001 blk_002
邏輯分塊:僅僅將塊的偏移量劃分出來，不會進行切分。例如：
hadoop.tar.gz 206M
blk01:0-128M
blk02:128-206M
2.檔案上傳流程：
- 1）客戶端向namenode傳送檔案上傳的請求
- 2）namenode會進行一系列的檢查：
- 父目錄是否存在
- 檔案是否已經上傳
- 是否有檔案上傳許可權等
- 如果檢查沒問題，則會發送允許上傳的響應
- 3）客戶端傳送真正的上傳請求 包含重要的資訊 檔案的大小（或長度）
- 4）namenode會向客戶端返回上傳檔案的節點。
- 根據檔案的大小進行計算返回的節點數的206/128M=2 2*副本3=6個節點
- 返回哪些節點？：
- 根據距離和空間
- 先返回客戶端所在機器節點>>>>同機架的節點>>>>>不同機架的節點
- 5)客戶端開始準備上傳
- 6）客戶端對資料進行邏輯切塊
- 7）客戶端開始上傳第一個資料塊
- 8）客戶端構建第一個資料塊的pipline
- 客戶端—-》hadoop01——>hadoop02——》hadoop03擴散
- 同時會開啟一個阻塞服務，這個服務的作用
- 1）用於檢測上傳的檔案是否和原檔案一樣
- 2）等待客戶端上傳成功的響應
- 9）客戶端開始進行真正的資料上傳，最終上傳成功之後，給客戶端響應
- 10）關閉當前的pipline
- 11）開始進行第二個塊的上傳，步驟重複 8,9,10
- 12）所有的塊都上傳成功之後 迴向namenode響應

3.如果在檔案上傳的過程中，有一個節點宕機了或者是通訊有問題，這個時候客戶端還會立即進行一次重試，如果重試還是失敗的這個時候會將這個節點剔除出pipline，用剩下的節點重新構建pipline 。 客戶端》》》hadoop02>>>hadoop03

4.客戶端這裡只要保證最終上傳成功的塊的副本有一個就認為資料塊上傳成功了，另外的副本等到叢集空閒的時候會自動進行資料塊的非同步複製。所以namenode返回節點的時候會優先返回客戶端所在節點，這個時候上傳的時候僅僅相當於本地複製的工作。
例如：

        hadoop01:hadoop fs -put /home/hadoop/hadoop.tar.gz   /
        第一個塊：客戶端hadoop01---》hadoop01--->hadoop02--->hadoop03
        /home/hadoop/hadoop.tar.gz塊1----->hadoop01:/home/hadoop/data/hadoopdata/data   此時是本地複製的，不需要網路傳輸

檔案下載

hadoop fs -get src dst

• 1)客戶端向namenode傳送檔案下載的請求
• 2）namenode也會進行一系列的檢查
  
  • 檔案是否存在，是否有許可權等
  • 如果這一系列的檢查沒有問題，這個時候開始查詢自己的元資料庫
  • 返回資料對應的塊以及塊的儲存位置給客戶端
    例如：

            hadoop.tar.gz
            blk_9988789:hadoop01   hadoop02
            blk_9988790:hadoop02   hadoop03

• 3）客戶端拿到資料快的儲存資訊，開始進行第一個塊的下載
  
  • 從哪一個節點下載？就近原則，優先選擇客戶端所在的節點》》》同機架》》》不同機架
  • 如果塊下載失敗怎麼辦？會再進行嘗試一次， 如果還失敗客戶端會將這個失敗的節點返回給namenode 同時會繼續從另外的節點進行下載這個塊。
• 4）第一個塊下載完成之後，會進行crc校驗，如果校驗通過 則認為下載成功。
• 5）開始進行第二個塊的下載，重複步驟4，進行檔案追加
• 6）當所有的資料塊下載成功之後，客戶端向namenode反饋

checkpoint：又叫元資料的合併過程

1、元資料儲存了：1）抽象目錄樹 2）資料和塊的對映 3）塊的儲存位置

2、元資料資訊儲存的檔案：

在/home/hadoop/data/hadoopdata/name/current下
    edits_0000000000000000001-0000000000000000002
    edits_inprogress_0000000000000000376
    fsimage_0000000000000000372
    fsimage_0000000000000000372.md5
    seen_txid
    VERSION

3.元資料檔案分成4類：

1）edits_0000000000000000001-0000000000000000002

    歷史日誌檔案，記錄元資料的操作日誌的，記的是流水賬

2）edits_inprogress_0000000000000000376

    正在編輯的日誌檔案 

3）fsimage_0000000000000000372

    fsimage_0000000000000000372.md5   加密檔案
    是一個磁碟映象檔案，儲存的是真實的元資料資訊序列化之後檔案

4）seen_txid：合併點，記錄的下次需要合併的edits檔案的編號

4.元資料修改的時候為什麼需要記錄edits檔案？為什麼不直接修改fsimage檔案？

答：fsimage檔案儲存在磁碟，直接進行修改，會耗費大量的namenode的時間和io，所以不會直接寫在fsimage中，而是先寫在edits中。 合併的工作由助理secondarynamenode來做。

5.fsimage檔案怎麼來的？舊的fsiamge檔案+edits檔案合併得來的

答：根據edits檔案中記錄的日誌操作取修改fsimage檔案

6.元資料合併的過程：

主角：secondarynamenode

合併點：觸發合併的條件

1）時間節點  3600s=1h
<property>
    <name>dfs.namenode.checkpoint.period</name>
    <value>3600</value>
    <description>The number of seconds between two periodic checkpoints.
     </description>
</property>
2)元資料條數節點    1000000萬條資料
<property>
     <name>dfs.namenode.checkpoint.txns</name>
     <value>1000000</value>
    <description>The Secondary NameNode or CheckpointNode will create a checkpoint
     of the namespace every 'dfs.namenode.checkpoint.txns' transactions, regardless
     of whether 'dfs.namenode.checkpoint.period' has expired.
    </description>
</property>

以上兩個條件只要滿足一個就會觸發checkpoint過程，記憶體中的元資料永遠是最新的完整的元資料

• 1）snn向namenode傳送是否需要checkpoint請求
• 2）namenode如果達到1000000條資料或者1個小時的節點 就會向snn響應需要進行checkpoint、
• 3）snn向namenode傳送checkpoint的請求
• 4）namenode開始進行checkpoint的準備工作、
• 將正在編輯的edits檔案進行回滾 同時生成一個新的正在編輯的edits_inprogress檔案
• 5)snn將namenode中的fsimage檔案和edits檔案（合併點—-剛剛進行回滾的）拉去到snn的本地
• 6）snn開始進行fsimage檔案和edits檔案合併，在記憶體中合併
• 7）合併完成，寫入到磁碟，命名為fsimage.new
• 8)將合併完成的fsimage檔案傳送到namenode中並進行重新命名fsimage 將原來的檔案覆蓋掉

6.如果使用snn的元資料進行資料恢復，恢復的資料有沒有偏差？
答：存在資料丟失的風險的。

6.如果使用snn的元資料進行資料恢復，恢復的資料有沒有偏差？
答：存在資料丟失的風險的。

7.namenode作用：
1）接收客戶端的讀寫請求
2）儲存元資料資訊
3）分配副本的存放節點
4）負載均衡
secondarynamenode:
1)備份元資料
2）幫助namenode進行checkpoint,分擔namenode的壓力
datanode:
1)真正的儲存資料
2）處理客戶端的讀，寫的請求
3）向namenode傳送心跳報告