資料一致性
HDFS作為分布式檔案系統在分布式環境下如何保證資料一致性，HDFS中，存盤的檔案將會被分成若干的大小一致的block分布式地存盤在不同的機器上，需要NameNode節點來對這些資料進行管理，存盤這些block的結點稱為DataNode，NameNode是用來管理這些元資料的，
NameNode保證元資料的一致性
客戶端上傳檔案時，NameNode首先往edits log檔案中記錄元資料的操作日志，與此同時，NameNode將會在磁盤做一份持久化處理（fsimage檔案）：它跟記憶體中的資料是對應的，如何保證和記憶體中的資料的一致性？在edits logs滿之前對記憶體和fsimage的資料做同步，合并edits logs和fsimage上的資料，然后edits logs上的資料即可清除，而當edits logs滿之后，檔案的上傳不能中斷，所以將會往一個新的檔案edits.new上寫資料，而老的edits logs的合并操作將由secondNameNode來完成，即所謂的checkpoint操作，
checkpoint的觸發一般由兩種限制，一個是edits logs的大小限制，即fs.checkpoint.size配置；一個是指定時間，即fs.checkpoint.period配置，根據規定，大小的限制是優先的，規定edits檔案一旦超過閾值，則不管是否達到最大時間間隔，都會強制checkpoint，
SecondaytNameNode 是 HA（High Available 高可用性）的一個解決方案，但不支持熱備，配置即可，SecondaryNameNode執行程序：從NameNode上下載元資料資訊（fsimage、edits），然后把二者合并，生成新的fsimage，在本地保存，并將其推送到NameNode，替換舊的fsimage，(注：SecondaryNameNode 只存在于Hadoop1.0中，Hadoop2.0以上版本中沒有，但在偽分布模式中是有SecondaryNameNode的，在集群模式中是沒有SecondaryNameNode的)
SecondaryNameNode 作業流程步驟：
- SecondaryNameNode 通知NameNode切換edits檔案
- SecondaryNameNode 從NameNode獲得fsimage和edits(通過http)
- SecondaryNameNode 將fsimage載入記憶體，然后開始合并edits，同樣合并edits操作是需要滿足一定條件才進行的，有兩個條件：
1)fs.checkpoint.period指定兩次checkpoint的最大時間間隔，默認3600秒
2)fs.checkpoint.size規定edits檔案的最大值，一旦超過這個值（默認大小是64M）則強制checkpoint，不管是否到達最大時間間隔，） - SecondaryNameNode 將新的fsimage發回給NameNode
- NameNode用新的fsimage替換舊的fsimage
校驗和
HDFS 會對寫入的所有資料計算校驗和(checksum)，并在讀取資料時驗證校驗和，針對指定位元組的數目計算校驗和，位元組數默認是512 位元組，可以通過io.bytes.per.checksum屬性設定，通過CRC-32編碼后為4位元組，
DataNode 在保存資料前負責驗證checksum，client 會把資料和校驗和一起發送到一個由多個DataNode 組成的佇列中，最后一個DataNode 負責驗證checksum，如果驗證失敗，會拋出一個ChecksumException，客戶端需要處理這種例外，客戶端從DataNode 讀取資料時，也會驗證checksum，每個DataNode 都保存了一個驗證checksum的日志，每次客戶端成功驗證一個資料塊后，都會告知DataNode ，DataNode 會更新日志，
每個DataNode 也會在一個后臺執行緒中運行一個DataBlockScanner，定期驗證這個 DataNode 上的所有資料塊，在用 hadoop fs get 命令讀取檔案時，可以用 -ignoreCrc 忽略驗證，如果是通過FileSystem API 讀取時，可以通過setVerifyChecksum(false)，忽略驗證，Hadoop中的LocalFileSystem會進行客戶端的檢驗和，寫檔案時，會在目錄下創建一個名為.filename.crc的隱藏檔案，如果想禁止校驗和功能，可以用RawLocalFileSystem代替LocalFileSystem ，
Configuration conf = ...
FileSystem fs = new RawLocalFileSystem();
fs.initialize(null, conf);
或者直接設定fs.file.impl屬性為org.apache.hadoop.fs.RawLocalFileSystem，這樣會全域禁用checksum，LocalFileSystem內部使用了ChecksumFileSystem完成checksum作業，通過ChecksumFileSystem可以添加校驗和功能，
HA高可用
冗余副本
HDFS處理節點失效的一個方法就是資料冗余，即對資料做多個備份，在HDFS中可以通過組態檔設定備份的數量，如果不進行設定，這個數量默認為3，注意引數dfs.replication.min和dfs.replication的區別：在一個塊被寫入期間，只要至少寫入了dfs.replication.min個副本數（默認是1），寫操作就會成功，直到達到其目標副本數dfs.replication（默認是3）
HDFS副本在機架上如何分布？
HDFS采用一種稱為機架感知的策略來改進資料的可靠性、可用性和網路帶寬的利用率，在大多數情況下，HDFS副本系數是默認為3(dfs.replication)，HDFS的存放策略是將一個副本存放在本地機架節點上，一個副本存放在同一個機架的另一個節點上，最后一個副本放在不同機架的節點上，這種策略減少了機架間的資料傳輸，提高了寫操作的效率，機架的錯誤遠遠比節點的錯誤少，所以這種策略不會影響到資料的可靠性和可用性，與此同時，因為資料塊只存放在兩個不同的機架上，所以此策略減少了讀取資料時需要的網路傳輸總帶寬，
機架感知
通常，大型Hadoop集群是以機架的形式來組織的，同一個機架上不同節點間的網路狀況比不同機架之間的更為理想，Namenode設法將資料塊副本保存在不同的機架上以提高容錯性
HDFS如何得知哪個Datanode在哪個機架上？
HDFS使用了一種稱為“機架感知”的策略，HDFS不能夠自動判斷集群中各個Datanode的網路拓撲情況，必須通過配置dfs.network.script引數來確定節點所處的機架，檔案提供了IP->rackid的翻譯，NameNode通過這個得到集群中各個Datanode節點的rackid，
心跳機制
檢測節點失效使用“心跳機制”，每個DataNode節點周期性地向NameNode發送心跳信號，網路磁區可能導致一部分DataNode跟NameNode失去聯系，NameNode通過心跳信號的缺失來檢測這一情況，并將這些近期不再發送心跳信號DataNode標記為宕機，不會再將新的IO請求發給它們，
任何存盤在宕機DataNode上的資料將不再有效，DataNode的宕機可能會引起一些資料塊的副本系數低于指定值，NameNode不斷地檢測這些需要復制的資料塊，一旦發現就啟動復制操作，
在下列情況下，可能需要重新復制：
a) 某個DataNode節點失效
b) 某個副本遭到損壞
c) DataNode上的硬碟錯誤
d) 檔案的冗余因子增大
DataNode與NameNode心跳報告內容
一個資料塊在DataNode以檔案存盤在磁盤上，包括兩個檔案，一個是資料本身，一個是元資料包括資料塊的長度、塊資料的校驗和以及時間戳，當DataNode讀取block的時候，它會計算checksum，如果計算后的checksum，與block創建時值不一樣，說明該block已經損壞，如果塊已損壞，Client會讀取其它DataNode上的block，NameNode標記該塊已經損壞，然后復制block達到預期設定的檔案備份數，
DataNode啟動后向NameNode注冊，心跳是每3秒一次，目的是告訴namenode自己的存活狀況以及可用空間，心跳回傳結果帶有NameNode給該DataNode的命令如復制塊資料到另一臺機器，或洗掉某個資料塊，
確認datanode宕機
（1）停止發送心跳報告
默認連續10次心跳接受不到即連續10*3=30s不間斷，這10次中間只要有1次接受到了重新記錄心跳，
（2）namenode發送檢查
在連續10次NameNode沒有接收到DataNode的心跳報告之后，NameNode斷定DataNode可能宕機了，NameNode主動向DataNode發送檢查 NameNode會開啟后臺的守護（阻塞）行程 等待檢查結果的，NameNode檢查DataNode的時間：默認5min，
默認檢查2次每次檢查5min連續2次檢查（10min）都沒有反應確認DataNode宕機了(發送一次等待5分鐘)，NameNode確認一個DataNode宕機需要的總時間： 103s+300s2=630s，
當DataNode啟動的時候，它會遍歷本地檔案系統，產生一份HDFS資料塊和本地檔案對應關系的串列，這就是報告塊（BlockReport），報告塊包含了DataNode上所有塊的串列，每小時DataNode默認向NameNode發送block report，匯報DataNode的資料節點情況，
安全模式
-
NameNode啟動后會進入一個稱為安全模式的特殊狀態，處于安全模式的NameNode對于客戶端來說是只讀的，NameNode從所有的DataNode接收心跳信號和塊狀態報告（blockreport），
-
每個資料塊都有一個指定的最小副本數（dfs.replication.min），當NameNode檢測確認某個資料塊的副本數目達到這個最小值，那么該資料塊就會被認為是副本安全(safely replicated)的，
-
在一定百分比（這個引數配置于dfs.safemode.threshold.pct，默認值是99.9%）的資料塊被NameNode檢測確認是安全之后，再過若干時間后（這個引數配置于dfs.safemode.extension，默認值是30秒），NameNode將退出安全模式狀態，接下來NameNode會確定還有哪些資料塊的副本沒有達到指定數目，并將這些資料塊復制到其他DataNode上，
校驗和
- HDFS會對寫入的所有資料計算校驗和（checksum），并在讀取資料時驗證，Datanode在收到客戶端的資料或者復制其他Datanode的資料時，在驗證資料后會存盤校驗和，正在寫資料的客戶端將資料及其校驗和發送到由一系列Datanode組成的管線，管線中的最后一個Datanode負責驗證校驗和，如果Datanode檢測到錯誤，客戶端便會收到一個ChecksumException
- 客戶端從Datanode讀取資料時，也會驗證校驗和，將它們與Datanode中存盤的校驗和進行比較，每個Datanode均持久保存一個用于驗證的校驗和日志，所以它知道每個資料塊的最后一次驗證時間，客戶端成功驗證一個資料塊后，會通知這個Datanode更新次日志
- 此外，每個Datanode也會在一個后臺運行一個稱為DataBlockScanner的行程定期驗證存盤在這個Datanode上的所有資料塊，檢測到錯誤后，Namenode將這個已損壞的資料塊標記為已損壞，之后從其他Datanode復制此資料的副本，最后使得資料的副本達到指定數目
回收站
當用戶或應用程式洗掉某個檔案時，這個檔案并沒有立刻從HDFS中洗掉，實際上，HDFS會將這個檔案重命名轉移到/trash目錄，只要檔案還在/trash目錄中，該檔案就可以被迅速地恢復，
檔案在/trash中保存的時間是可配置的（配置引數fs.trash.interval），當超過這個時間時，Namenode就會將該檔案從命名空間中洗掉，洗掉檔案會使得該檔案相關的資料塊被釋放，注意，從用戶洗掉檔案到HDFS空閑空間的增加之間會有一定時間的延遲，
元資料保護
FsImage和Editlog是HDFS的核心資料，如果這些檔案損壞了，整個HDFS都將失效，因而，Namenode可以配置成支持維護多個FsImage和Editlog的副本，任何對FsImage或者Editlog的修改，都將同步到它們的副本上，這種多副本的同步操作可能會降低Namenode每秒處理的名字空間事務數量，然而這個代價是可以接受的，因為即使HDFS的應用是資料密集的，它們也非元資料密集的，當Namenode重啟的時候，它會選取最近的完整的FsImage和Editlog來使用
快斬訓制
快照支持某一特定時刻的資料的復制備份，利用快照，可以讓HDFS在資料損壞時恢復到過去一個已知正確的時間點，HDFS目前還不支持快照功能，但計劃會在將來的版本支持，
容錯機制
故障的型別主要有以下三種，針對這三種故障型別，HDFS提供了不同的故障檢測機制：
針對DataNode失效問題，HDFS使用了心跳機制，DataNode定期向NameNode發送心跳資訊，NameNode根據心跳資訊判斷DataNode是否存活
針對網路故障而導致無法收發資料的問題，HDFS提供了ACK的機制，在發送端發送資料后，如果沒有收到ACK并且經過多次重試后仍然如此，則認為網路故障
針對資料損壞問題，所有DataNode會定期向NameNode發送自身存盤的塊清單，在傳輸資料的同時會發送總和校驗碼，NameNode依次來判斷資料是否丟失或損壞
讀容錯
讀失敗時：
- DFSInputStream 會去嘗試連接串列里的下一個 DataNode ，同時記錄下這個例外節點
- DFSInputStream 也會對獲取到的資料核查 checknums ，如果損壞的 block 被發現了，DFSInputStream 就試圖從另一個擁有備份的 DataNode 中去讀取備份塊中的資料
- 最后例外資料的同步作業也是由 NameNode 來安排完成
寫容錯
當寫流程中一臺 DataNode 宕機了：
首先 pipeline 被關閉，在確認佇列中的剩下的 package 會被添加進資料佇列的起始位置上不再發送，以防止在失敗的節點下游的節點再丟失資料
然后，存盤在正常的 DataNode 上的 block 會被指定一個新的標識，并將該標識傳遞給 NameNode，以便故障DataNode在恢復后可以洗掉自己存盤的那部分已經失效的資料塊
失敗節點會從 pipeline 中移除，然后剩下兩個好的 DataNode 會組成一個的新的 pipeline ，剩下的這些 block 的包會繼續寫進 pipeline 中正常的 DataNode 中
最后，NameNode 會發現節點宕機導致部分 block 的塊備份數小于規定的備份數，此時NameNode 會安排使節點的備份數滿足 dfs.replication 配置要求
DataNode失效
在NameNode中會持有資料塊表和DataNode兩張表，資料塊表存盤著某個資料塊（包括副本）所在的DataNode，DataNode表存盤著每個DataNode中保存的資料塊串列，由于DataNode會周期性地給NameNode發送自己所持有的資料塊資訊，因此NameNode會持續更新資料塊表和DataNode表，如果發現某個DataNode上的資料塊錯誤，NameNode會從資料塊表洗掉該資料塊；如果發現某個DataNode失效，NameNode會對兩張表進行更新，NameNode還會周期性地掃描資料塊表，如果發現資料塊表中某個資料庫的備份數量低于所設定的備份數，則會協調從其它DataNode復制資料到另一個DataNode上完成備份，
HDFS副本放置策略
如果寫請求出現在某個DataNode上，第一個副本就會存放在當前DataNode所在的機器上，如果該機器負載過重，可以將該備份放在同一個機架上的隨機機器上，接著第二個副本就會存放在不同于第一個副本所在機架的機架上，第三個副本會隨機存放在第二個副本所在機架的任一DataNode上，
在三個副本的情況下，第一個副本與原資料在相同機器上，另外兩個副本放在其它機架的隨機機器上，這樣的設定可以使得性能與容災兼備，優先從同機器上獲取備份資料，減少資料傳輸開銷；在該機器宕機的情況下，從另一個機架獲取備份資料，避免同一個機架的機器集體宕機的情況出現，
HDFS的HA架構
以上的所有容錯都是基于DataNode的故障問題進行考慮的，但是NameNode本身就存在單點故障，如果NameNode出現故障，則整個集群會直接宕機，因此HDFS提供了HA的架構，對于一個典型的HA集群而言，NameNode會被配置在兩臺獨立的機器上，在任何時間上，一個NameNode處于Active狀態，而另一個NameNode處于Standby狀態，Active狀態的NameNode會回應集群中所有的客戶端的請求，Standby狀態的NameNode只是作為一個副本，保證在必要的時候提供一個快速的轉移，使得上層對NameNode的切換無感知，Standby NameNode與Active NameNode應時刻保持同步，在Active NameNode和Standby NameNode之間要有個共享的存盤日志的地方，Active NameNode把EditLog寫到共享的存盤日志中，Standby NameNode讀取日志并執行，使得Active NameNode和Standby NameNode記憶體中的HDFS元資料保持同步，
歡迎關注，《大資料成神之路》系列文章
歡迎關注，《大資料成神之路》系列文章
歡迎關注，《大資料成神之路》系列文章
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/251376.html
標籤：Java
上一篇：一個程式員的自述