HDFS

大數(shù)據(jù)學習線路圖

1.png

縮略詞

NN - NameNode
SNN - Secondry NameNode
DN - DataNode

概念

HDFS-Hadoop Distributed File System

• 為什么要有HDFS
  隨著區(qū)塊鏈、大數(shù)據(jù)等技術的推動进鸠，全球數(shù)據(jù)量正在無限制地擴展和增加盖呼。分布式存儲的興起與互聯(lián)網(wǎng)的發(fā)展密不可分沽瞭，互聯(lián)網(wǎng)公司由于其大數(shù)據(jù)褐缠、輕資產(chǎn)的特點懊直，通常使用大規(guī)模分布式存儲系統(tǒng)

設計思想

• 設計思想

  • 切塊存儲
    當一個文件過大笔宿，一個節(jié)點存儲不下，采用分塊存儲
    （1）Hadoop 1.x 默認塊大小為64M
    （2）Hadoop 2.x 默認塊大小為128M稳摄，當塊不足128M時稚字，也會單獨存一個塊
  • 備份機制
    塊備份默認個數(shù)為3，hdfs-site.xml文件dfs.replication參數(shù)配置厦酬，所有備份地位相同胆描，沒有主次之分
  2.png

1仆嗦、如果集群節(jié)點只有兩個训唱，但是dfs.replication=3， 實際存儲幾個米愿？
實際存儲2個减噪，當集群的幾點數(shù)>=3時短绸，會復制這個副本，最終達到3個

2筹裕、 達到如果節(jié)點有4個醋闭，副本3個，有一個副本的機器宕機饶碘，只是后發(fā)現(xiàn)副本的個數(shù)小于設定的個數(shù)，就會進行復制馒吴，達到3個副本
如果宕機的節(jié)點恢復了扎运，集群等待一段時間發(fā)現(xiàn)副本是4個，集群隨機刪除一個

3饮戳、備份越多越好嗎豪治？
理論上來說，副本越多扯罐，數(shù)據(jù)安全性越高负拟，
但是副本越多，占用過多的存儲資源歹河，造成集群維護變得困難
100個node掩浙，副本50個，HDFS系統(tǒng)需要同時維護50個副本秸歧，在50個副本中厨姚，一旦有節(jié)點宕機，就需要進行復制工作

整體架構

• 架構
  HDFS 采用Master/Slave的架構來存儲數(shù)據(jù)键菱，一個主節(jié)點多個從節(jié)點
  這種架構主要由四個部分組成谬墙，分別為HDFS Client、NameNode、DataNode和Secondary

  • Client

    • 文件切分
      文件上傳時拭抬，Client將文件切分為一個一個的block部默，再進行存儲
    • 與NN交互，獲取文件的位置信息
    • 與DN交互造虎，讀取或者寫入數(shù)據(jù)
    • 管理HDFS
    • 訪問HDFS

  • NameNode

    • 存儲元數(shù)據(jù)
      一條元數(shù)據(jù)大小150byte左右
    • 處理客戶端讀寫請求
    • 負責分配數(shù)據(jù)塊的存儲節(jié)點傅蹂，管理數(shù)據(jù)塊的映射信息
    • 負載均衡

  • Secondary NameNode
    并非NN的熱備份，當NN宕機時累奈，它并不能馬上替換掉NN并提供服務
    但是贬派，SNN中存儲的數(shù)據(jù)和NN基本相同

    • 輔助NN，分擔其工作量
    • 進行checkpoint澎媒， 幫助NN進行元數(shù)據(jù)合并搞乏，定期合并fsimage和fsedits，并推送給NN
    • 幫助NN做元數(shù)據(jù)備份戒努，在緊急情況下请敦，可輔助恢復NN，但是無法成為NN（這里有別于高可用組網(wǎng)中standby NN）

    當NN宕機時储玫，SNN不能主動切換為NN侍筛，可進行手動切換：
    在實驗室環(huán)境，可以在Hadoop1停止NN撒穷，刪除name目錄匣椰，將Hadoop2的 SNN拷貝到hadoop1并重命名為name，hadoop1的NN進程可以經(jīng)常啟動

  • DataNode
    DN就是Slave從服務端礼，NN下達命令禽笑，DN負責執(zhí)行實際的操作

    • 負責真正的數(shù)據(jù)存儲，存儲實際的數(shù)據(jù)塊block
    • 執(zhí)行數(shù)據(jù)塊的讀/寫操作
    • 定期向NN發(fā)送心跳報告（狀態(tài)信息蛤奥，塊位置信息）

    數(shù)據(jù)塊位置信息補充說明：
    數(shù)據(jù)塊存儲在DN上佳镜，但每個DN只知道自己節(jié)點上存儲了哪些塊兒，并不知道這些塊兒分別屬于哪個文件凡桥，NN才知道這些塊屬于哪個文件（存儲的數(shù)據(jù)和block的對應關系）
    NN記錄在磁盤中的元數(shù)據(jù)不包含block塊存儲的位置信息蟀伸，但包含數(shù)據(jù)與塊兒的對應關系，NN記錄元數(shù)據(jù)時會如下存儲：
    xxxxx.tar.gz：blk_1:[ ], blk_2[ ]
    數(shù)據(jù)塊的存儲信息會先存為一個空的列表缅刽，當DN向NN發(fā)送塊報告的時候啊掏，會把對應塊的存儲節(jié)點添加到列表中[ ]。
    磁盤上的元數(shù)據(jù)信息永遠不保存塊的位置信息衰猛，只保存一個空列表脖律，快的位置信息時加載到內存后有DN匯報添加上的。

優(yōu)點缺點

• 適用場景
  HDFS專門為解決大數(shù)據(jù)的存儲問題而產(chǎn)生
  • 可存儲超大文件(PB級別)
  • 流式數(shù)據(jù)訪問
    一次寫入腕侄，多次讀取
    數(shù)據(jù)集通常從數(shù)據(jù)源復制而來小泉，每次分析都涉及該數(shù)據(jù)集的大部分甚至全部
  • 商用硬件
    不需要運行在高昂可靠的硬件上芦疏，可以運行上普通的商用硬件上，節(jié)點的故障不會影響系統(tǒng)的運行

• 優(yōu)點
  • 可構建在廉價機器上微姊，成本低
    • 它通過多副本機制酸茴，提高可靠性。
    • 它提供了容錯和恢復機制兢交。比如某一個副本丟失薪捍，可以通過其它副本來恢復
  • 高容錯性
    • 數(shù)據(jù)自動保存多個副本。它通過增加副本的形式配喳，提高容錯性
    • 某一個副本丟失以后酪穿，它可以自動恢復，這是由 HDFS 內部機制實現(xiàn)的晴裹，我們不必關心被济。
  • 適合批處理 適合離線數(shù)據(jù)處理
    • 它是通過移動計算而不是移動數(shù)據(jù)
    • 它會把數(shù)據(jù)位置暴露給計算框架
  • 適合大數(shù)據(jù)處理
    • 處理數(shù)據(jù)達到 GB、TB涧团、甚至PB級別的數(shù)據(jù)
    • 能夠處理百萬規(guī)模以上的文件數(shù)量只磷，數(shù)量相當之大
    • 能夠處理10K節(jié)點的規(guī)模
  • 流式文件訪問 不支持數(shù)據(jù)修改
    • 一次寫入，多次讀取泌绣。文件一旦寫入不能修改钮追，只能追加
    • 它能保證數(shù)據(jù)的一致性
    • 數(shù)據(jù)塊以副本存儲，一旦可以修改阿迈，需要修改所有副本元媚，十分占資源

• 缺點
  • 不支持低延時數(shù)據(jù)訪問，查詢慢苗沧，不支持實時/近實時
    • 比如毫秒級的來存儲數(shù)據(jù)刊棕，這是不行的，它做不到
    • 它適合高吞吐率的場景崎页，就是在某一時間內寫入大量的數(shù)據(jù)鞠绰。但是它在低延時的情況下是不行的腰埂，比如毫秒級以內讀取數(shù)據(jù)飒焦，這樣它是很難做到的
  • 不擅長存儲大量的小文件
    • 小文件存儲，尋址時間可能會超過讀取數(shù)據(jù)的時間屿笼，不劃算牺荠，它違反了HDFS的設計目標
    • 存儲大量小文件的話，造成元數(shù)據(jù)存儲量過大驴一，它會占用 NameNode大量的內存來存儲文件休雌、目錄和塊信息。這樣是不可取的肝断，因為NameNode的內存總是有限的杈曲。一條元數(shù)據(jù)大小150byte左右
  • 不支持并發(fā)寫入驰凛、文件隨機修改
    • 一個文件只能有一個寫，不允許多個線程同時寫
    • 僅支持數(shù)據(jù) append（追加）担扑，不支持文件的隨機修改

HDFS應用

• 命令行

  • HDFS命令方式

    • 開啟hadoop或hdfs客戶端：
    • 任意目錄下： hsdoop fs
      這些命令在集群中任意節(jié)點都可以做恰响、hdfs文件系統(tǒng)中看到的目錄結構只是一個抽象目錄樹，實際存儲在集群的節(jié)點上
      例如：
      aa.txt 150M hadoop fs -put aa.txt /
      會在/目錄下看到aa.txt涌献，
      但是aa.txt 真實存儲的時候會進行分塊（128M+22M）胚宦，分兩塊進行存儲
      假設集群中有5個存儲節(jié)點，這兩個塊存儲在哪個節(jié)點由NameNode進行分配
    3.png

  • 支持的命令Shell
    這里不一一闡述燕垃，類似Linux命令枢劝，參考官網(wǎng)鏈接：
    http://hadoop.apache.org/docs/r1.0.4/cn/hdfs_shell.html#ls

    FS Shell
    cat
    chgrp
    chmod
    chown
    copyFromLocal
    copyToLocal
    cp
    du
    dus
    expunge
    get
    getmerge
    ls
    lsr
    mkdir
    movefromLocal
    mv
    put
    rm
    rmr
    setrep
    stat
    tail
    test
    text
    touchz

四大機制兩大核心

• 四大機制

  • 心跳機制
    HDFS是主從架構，所有為了實時的得知dataNode是否存活卜壕，必須建立心跳機制您旁，在整個hdfs運行過程中，dataNode會定時的向nameNode發(fā)送心跳報告已告知nameNode自己的狀態(tài)印叁。

    • 心跳內容：
      ?? ? 報告自己的存活狀態(tài)被冒，每次匯報之后都會更新維護的計數(shù)信息
      ?? ? 向NN匯報自己的存儲的block列表信息：（hdfs-default.xml）

                 <property> 
                    <name>dfs.heartbeat.interval</name 
                    <value>3</value//單位秒，決定datanode向namenode發(fā)送心跳報告的間隔時間  
                </property>
      

    • NN判斷一個DN宕機的基準
      連續(xù)10次接收不到DN的心跳信息轮蜕，和2次的檢查時間昨悼。
      檢查時間：表示在nameNode在接收不到dataNode的心跳時，此時會向dataNode主動發(fā)送檢查

      <property>
        <name>dfs.namenode.heartbeat.recheck-interval</name>
        <value>300000</value//單位毫秒跃洛，5min
      </property>  
      

      DN每隔3S向NN發(fā)送一次心跳報告率触，當NN連續(xù)10次沒有收到DN的心跳報告，判定DN可能死了汇竭，但沒有斷定死亡葱蝗，只是可能；
      這時候细燎，NN主動向DN發(fā)送一次檢查两曼，5分鐘，NN給2次機會玻驻，如果一次檢查沒有返回信息悼凑，這是NN會再進行一次，共兩次璧瞬，如果還是獲取不到DN的返回信息户辫，這時候才會判定DN死亡。
      總判斷時間：
      計算公式：10dfs.heartbeat.interval + 2dfs.namenode.heartbeat.recheck-interval+=103+2*300=630s=10.5min

  • 安全機制
    在HDFS啟動的時候嗤锉，首先會進入安全模式中渔欢，當達到規(guī)定的要求時，會退出安全模式瘟忱。在安全模式中奥额，不能執(zhí)行任何修改元數(shù)據(jù)的操作

    • 如何進入安全模式苫幢？
      集群啟動后分三步驟：
      1，namenode將元數(shù)據(jù)加載到內存中垫挨；抽象目錄樹+數(shù)據(jù)與塊的對應關系
      2态坦，namenode接收datanode的心跳報告：獲取datanode存活狀況+獲取block塊存放位置信息
      3，啟動secondnamenode
      集群在啟動過程中棒拂，不允許外界對集群進行操作伞梯，這時候集群處于安全模式。
      也就是說帚屉，集群在處于安全模式的時候谜诫，在加載元數(shù)據(jù)/獲取datanode心跳報告
      如果集群處于維護或升級時候，可以手動將集群設置為安全模式：hdfs dfsadmiin -safemode enter

    • 安全模式下用戶可以做的操作攻旦？
      只有不修改元數(shù)據(jù)的操作才可以
      安全模式下用戶可執(zhí)行的操作：
      ls-查看目錄
      cat-查看文件
      get-下載
      安全模式下用戶不可執(zhí)行的操作：
      mkdir-創(chuàng)建文件夾
      put-上傳
      修改文件名
      文件追加

      • 如何退出安全模式喻旷？
        自動退出安全模式的條件：
        • 如果在集群啟動時dfs.namenode.safemode.min.datanodes（啟動的dataNode個數(shù)）為0時，并且牢屋，數(shù)據(jù)塊的最小副本數(shù)dfs.namenode.replication.min為1時且预，此時會退出安全模式，也就是說烙无，集群達到了最小副本數(shù)锋谐，并且能運行的datanode節(jié)點也達到了要求，此時退出安全模式
        • 啟動的dataNode個數(shù)為0時截酷，并且所有的數(shù)據(jù)塊的存貨率達到0.999f時涮拗，集群退出安全模式（副本數(shù)達到要求）（99%的機器的心跳報告接收到）

        <property>
         <name>dfs.namenode.safemode.threshold-pct</name>
         <value>0.999f</value>
        </property>
        

        手動退出或者進入安全模式
        • hdfs dfsadmin -safemode enter 進入
        • hdfs dfsadmin -safemode leave 退出
        • hdfs dfsadmin -safemode get 查看, 開啟返回ON，關閉返回OFF
        • hdfs dfsadmin -safemode wait 等待自行退出安全模式迂苛，沒啥用

  • 機架策略

    • 默認每個數(shù)據(jù)塊有三個副本：

      • 第一個副本三热，放置在離客戶端最近的那個機架的任意節(jié)點，如果客戶端是本機三幻，那就存放在本機（保證有一個副本數(shù)）就漾，
      • 第二個副本，放置在跟第一個副本不同機架的任意節(jié)點上念搬，（防止機架斷電抑堡，數(shù)據(jù)訪問不到）
      • 第三個副本，放置在跟第一個副本相同機架的不同節(jié)點上锁蠕。（在風險度相同的情況下夷野，優(yōu)先網(wǎng)絡傳輸少的）

    • 真實生產(chǎn)中懊蒸，需要手動配置機架策略
      真實生產(chǎn)中荣倾，我們可以自定義機架策略: 不同節(jié)點，不同機架骑丸，不同數(shù)據(jù)中心

      • 修改副本的方法：
        • 修改配置文件：

         <property>
        <name>dfs.replication</name>
        <value>3</value>
        </property>
        

        • 命令設置： hadoop fs -setrep 3 -R dir

    • 負載均衡
      hdfs的負載均衡：表示每一個dataNode存儲的數(shù)據(jù)與其硬件相匹配舌仍，即占用率相當
      每個節(jié)點上存儲的數(shù)據(jù)的百分比相差不大妒貌，能力越大責任越大。

      總	已用	占比
      5T	2.5T	50%
      2T	1T	50%
      8T	4T	50%

      在進行文件上傳時铸豁，會優(yōu)先選擇客戶端所在節(jié)點灌曙，
      如果習慣性的使用同一個客戶端會造成客戶端所在節(jié)點存儲數(shù)據(jù)比較多，集群有一個自動的負載均衡操作节芥，只不過這個自動負載均衡操作比較慢在刺，

      • 自動進行負載均衡：
        ? - 集群自動調整負載均衡的帶寬：（默認為1M）

              <property>
              <name>dfs.datanode.balance.bandwidthPerSec</name>
              <value>1048576</value//1048576byte=1024kb=1M，限制負載均衡的帶寬头镊，默認1M/s
              </property>  
      

      • 手動開啟負載均衡：
        在集群大的情況下蚣驼，由于要滿足帶寬條件，過程十分緩慢相艇，可以通過以下方式手動開啟負載均衡：
        告訴集群進行負載均衡：start-balancer.sh -t 10% 表示節(jié)點最大占用率與節(jié)點的最小的占用率之間的差值當超過10%時颖杏，此時集群不會立刻進行負載均衡，會在集群不忙的時候進行坛芽。

      負載均衡什么時候發(fā)生概率高留储？
      在集群中有新增節(jié)點時

  • 兩大核心：

    • 文件上傳：
      • 使用HDFS提供的客戶端client，向遠程的NN發(fā)起RPC請求咙轩。
      • NN會檢查要創(chuàng)建的文件是否已經(jīng)存在获讳、創(chuàng)建者是否有權限，成功則會為文件創(chuàng)建一個記錄活喊，否則向客戶端拋出異常赔嚎。
      • 當客戶端開始寫入文件的時候，客戶端會將文件切分成多個packets胧弛，并在內部以數(shù)據(jù)隊列“data queue（數(shù)據(jù)隊列）”的形式管理這些packet尤误，并向namenode申請blocks，獲取用來存儲replicas的合適的datanode列表结缚，列表的大小根據(jù)namenode中的replication個數(shù)來設定损晤。
      • client獲取block列表之后，開始以pipeline（管道）的形式红竭，將packet寫入所有的replicas中尤勋，客戶端把packet以流的形式寫入到第一個datanode中，該datanode把packet存儲之后茵宪，在將其傳遞到此pipeline中的下一個datanode最冰，直到最后一個 datanode。
      • 最后一個 datanode 成功存儲之后會返回一個 ack packet（確認隊列）稀火，在 pipeline 里傳遞至客戶端暖哨，在客戶端的開發(fā)庫內部維護著"ack queue"，成功收到 datanode 返回的 ackpacket 后會從"data queue"移除相應的 packet凰狞。
      • 如果傳輸過程中篇裁，有某個datanode出現(xiàn)了故障沛慢，那么當前pipeline會被關閉，出現(xiàn)故障的節(jié)點达布，會被剔除此pipeline团甲，剩余的block會繼續(xù)剩下的的 datanode 中繼續(xù)以 pipeline 的形式傳輸，同時 namenode 會分配一個新的 datanode黍聂，保持 replicas 設定的數(shù)量躺苦。
      • 客戶端完成數(shù)據(jù)的寫入后，會對數(shù)據(jù)流調用close方法产还，關閉數(shù)據(jù)流
      • 只要寫入了 dfs.replication.min（最小寫入成功的副本數(shù)）的復本數(shù)（默認為 1）圾另，寫操作就會成功，并且這個塊可以在集群中異步復制雕沉，直到達到其目標復本數(shù)（dfs.replication的默認值為 3）集乔，因為namenode已經(jīng)知道文件由哪些塊組成，所以他在返回成功前只需要等待數(shù)據(jù)塊進行最小量的復制坡椒。
      • 最后當這個文件上傳成功后扰路，此時namenode會將預寫如日志的操作，同步到內存中
        
        文件上傳.png

如果上傳過程中倔叼，如果有一個節(jié)點塊上傳失敗汗唱，會怎么辦？
那么HDFS會立即重試一次丈攒，如果還是失敗哩罪，會將失敗的節(jié)點從pipeline中剔除，并將失敗的節(jié)點報告給NameNode
比如上圖blk_1: Client-DataNode01-02-04
如果02失敗巡验，則02從pipeline中剔除：Client-DataNode01-04
HDFS最終可以忍受最大極限是至少有一個節(jié)點上傳成功际插，如果節(jié)點全都失敗，這時候會向NameNode重新申請显设，重新構建pipeline
最終文件上傳過程中保證至少有一份即可框弛，剩下的副本在上傳成功后，進行內部復制捕捂。

數(shù)據(jù)上傳的時候瑟枫，為什么優(yōu)先選擇客戶端所在節(jié)點？
如果客戶端所在節(jié)點是數(shù)據(jù)節(jié)點指攒，一般情況下會返回客戶端所在節(jié)點慷妙，因為客戶端所在節(jié)點不存在網(wǎng)絡傳輸，上傳失敗的可能性小允悦，這時候可以保證至少上傳成功一個節(jié)點膝擂，其他節(jié)點即使失敗了，可以進行內部復制

• 文件下載
  • 客戶端對NN發(fā)送下載的指令，hadoop fs -get /a.txt
  • NN做一系列的校驗（是否權限猿挚、文件是否存在..）
  • NN向Client發(fā)送block的位置信息，根據(jù)情況發(fā)送一部分或者全部
  • Client計算出最進行DN驶鹉，然后建立連接绩蜻，進行文件下載
  • Client每下載一個塊就會做CRC校驗，如果下載失敗室埋，Client會向NN匯報办绝，然后從其他的DD相應的塊的副本，此時NN會記錄這個可能故障的DN姚淆，在下次上傳或者下載的時候孕蝉，盡量不使用它。
  • 當所有的塊下載成功的時候腌逢，Client向NN匯報成功信息

文件下載.png

文件下載過程中如果產(chǎn)生異常怎么辦降淮？
數(shù)據(jù)塊的某個節(jié)點讀取不到數(shù)據(jù)，這個時候會向NN進行匯報搏讶，NN就會對這個DN做個標記（這個節(jié)點可能是問題節(jié)點）佳鳖，接著讀取這個塊存儲的其他DN節(jié)點。

• 元數(shù)據(jù)管理

  • 元數(shù)據(jù)組成

    • 抽象目錄樹
    • 數(shù)據(jù)與數(shù)據(jù)塊的對應關系-文件被切分為多少塊
    • Block數(shù)據(jù)塊的存放位置信息

  • 元數(shù)據(jù)的存放目錄
    /opt/hadoop/data/hadoopdata 下有三個目錄：

    data	數(shù)據(jù)真實存儲的目錄媒惕，datanode存儲數(shù)據(jù)的存儲目,（Hadoop1既是namenode也是datanode）
    name	namenode存儲元數(shù)據(jù)的目錄
    nm-local-dir	HDFS的本地緩存

    /name/current 元數(shù)據(jù)存儲目錄系吩，文件包括四大類：

    edits_00000000001-00000000002	歷史日志文件	編輯完成的日志文件，記錄客戶端對元數(shù)據(jù)操作的日志妒蔚，只記錄操作穿挨。比如某一個用戶對某一個目錄執(zhí)行了某一種操作
    edits_inprogress_000000000001948	正在編輯的日志文件	目前對元數(shù)據(jù)修改的操作記錄文件
    fsimage_000000001945	鏡像文件	真實的元數(shù)據(jù)信息經(jīng)過序列化之后的文件，序列化能夠減少存儲的容量肴盏，集群啟動時會加載fsimage文件科盛，加載時會進行反序列化，md5是加密文件
    seen_txid	合并點記錄文件	為什么記錄合并點菜皂？ cat seen_txid -> 1948 （與正在編輯的文職文件id一致）土涝，記錄的是下一次需要合并的日志文件

    <img src="https://upload-images.jianshu.io/upload_images/22827736-45c098150391da71.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" width="100%">

    • 當HDFS格式化后，只有以下三個文件

    fsimage_00000000000	格式化的鏡像文件	只有跟目錄 /
    fsimage_00000000000.md5
    seen_txid

    • 當集群格式化后第一次啟動：start-dfs.sh幌墓，會生成一個正在編輯的日志文件

    edits_inprogress_000000001	正在編輯的日志文件
    fsimage_00000000000	格式化的鏡像文件	只有根目錄 /
    fsimage_00000000000.md5
    seen_txid

    真實的硬盤上存儲的完成的元數(shù)據(jù)：
    faimage+正在編輯的日志文件

    內存中的元數(shù)據(jù)是完整的嗎但壮？
    無論什么時候，內存中的保存的元數(shù)據(jù)永遠是最新的最完整的元數(shù)據(jù)

  • 元數(shù)據(jù)合并

    • 磁盤上為什么要做元數(shù)據(jù)合并常侣？
      如果fsimage和日志文件不進行合并蜡饵，那么fsimage和內存中的元數(shù)據(jù)差別會越來越大

    • 什么時候進行合并
      元數(shù)據(jù)的合并時機
      A/B兩個觸發(fā)條件滿足其一，則會觸發(fā)合并（checkpoint）

      A：時間節(jié)點：間隔多長時間合并一次

          <property>
          <name>dfs.namenode.checkpoint.period</name>
           <value>3600</value//單位秒胳施，3600s=1 hour
           </property>  
      

      B：元數(shù)據(jù)條數(shù)：操作日志記錄超過多少條合并一次

          <property>
          <name>dfs.namenode.checkpoint.txns</name>
          <value>1000000</value//100萬條
          </property>
      

    • 如何進行合并溯祸？
      secondaryNamenode對元數(shù)據(jù)進行合并：
      集群啟動時，加載fsimage鏡像文件到內存，如果是第一啟動集群或者集群正常關閉之后重啟此時nameNode會在硬盤中合并一個fsimage鏡像seconddaryNameNode定時（1分鐘）發(fā)送檢驗給nameNode焦辅，查看是否需要進行合并得知nameNode需要進行元數(shù)據(jù)合并seconddaryNameNode向nameNode發(fā)送合并請求nameNode將edits_inprogress_000095 根據(jù)seen_txid進行回滾博杖，并且生成一個新的空的edits_inprogress_000096，繼續(xù)記錄操作日志secondaryNameNode將回滾的edits和最新的fsiamge進行本地拉去secondaryNameNode將edits和最新的fsiamge進行合并筷登，在內存中根據(jù)edits修改fsiamgesecondaryNameNode將合并后的fsiamge推送回namenode剃根。并在本地保存一份。

5.png

secondaryNameNode將合并后的fsiamge推送回namenode后前方，為什么要在本機保存一份狈醉？
以防NameNode宕機后元數(shù)據(jù)丟失，可以用備份文件幫助NameNode進行恢復

如果不是第一次進行checkpoint惠险，SNN只需要拉取合并點seen_txid之后的edits文件就可以了

在沒有達到checkpoint過程的這段時間苗傅，如果集群正常關閉了，元數(shù)據(jù)會丟失嗎班巩？
在集群關閉之前渣慕，內存中的元數(shù)據(jù)會寫入到磁盤中一份，關閉集群時候抱慌，保證磁盤上元數(shù)據(jù)據(jù)和內存中的一致摇庙。