數(shù)據(jù)一致性
HDFS作為分布式文件系統(tǒng)在分布式環(huán)境下如何保證數(shù)據(jù)一致性。HDFS中壮不，存儲的文件將會被分成若干的大小一致的block分布式地存儲在不同的機器上汗盘，需要NameNode節(jié)點來對這些數(shù)據(jù)進行管理，存儲這些block的結(jié)點稱為DataNode询一，NameNode是用來管理這些元數(shù)據(jù)的隐孽。
NameNode保證元數(shù)據(jù)的一致性
客戶端上傳文件時，NameNode首先往edits log文件中記錄元數(shù)據(jù)的操作日志健蕊。與此同時菱阵，NameNode將會在磁盤做一份持久化處理（fsimage文件）：它跟內(nèi)存中的數(shù)據(jù)是對應(yīng)的，如何保證和內(nèi)存中的數(shù)據(jù)的一致性缩功？在edits logs滿之前對內(nèi)存和fsimage的數(shù)據(jù)做同步晴及，合并edits logs和fsimage上的數(shù)據(jù)，然后edits logs上的數(shù)據(jù)即可清除嫡锌。而當edits logs滿之后虑稼，文件的上傳不能中斷，所以將會往一個新的文件edits.new上寫數(shù)據(jù)世舰，而老的edits logs的合并操作將由secondNameNode來完成动雹，即所謂的checkpoint操作。
checkpoint的觸發(fā)一般由兩種限制跟压，一個是edits logs的大小限制胰蝠，即fs.checkpoint.size配置；一個是指定時間震蒋，即fs.checkpoint.period配置茸塞。根據(jù)規(guī)定，大小的限制是優(yōu)先的查剖，規(guī)定edits文件一旦超過閾值钾虐，則不管是否達到最大時間間隔，都會強制checkpoint笋庄。
SecondaytNameNode 是 HA（High Available 高可用性）的一個解決方案效扫，但不支持熱備蝌麸，配置即可橄浓。SecondaryNameNode執(zhí)行過程：從NameNode上下載元數(shù)據(jù)信息（fsimage供璧、edits）佩伤，然后把二者合并，生成新的fsimage济丘，在本地保存谱秽，并將其推送到NameNode，替換舊的fsimage摹迷。(注：SecondaryNameNode 只存在于Hadoop1.0中疟赊，Hadoop2.0以上版本中沒有，但在偽分布模式中是有SecondaryNameNode的峡碉，在集群模式中是沒有SecondaryNameNode的)
SecondaryNameNode 工作流程步驟：
- SecondaryNameNode 通知NameNode切換edits文件
- SecondaryNameNode 從NameNode獲得fsimage和edits(通過http)
- SecondaryNameNode 將fsimage載入內(nèi)存近哟，然后開始合并edits。同樣合并edits操作是需要滿足一定條件才進行的鲫寄，有兩個條件：
1)fs.checkpoint.period指定兩次checkpoint的最大時間間隔椅挣，默認3600秒
2)fs.checkpoint.size規(guī)定edits文件的最大值，一旦超過這個值（默認大小是64M）則強制checkpoint塔拳，不管是否到達最大時間間隔。） - SecondaryNameNode 將新的fsimage發(fā)回給NameNode
- NameNode用新的fsimage替換舊的fsimage
校驗和
HDFS 會對寫入的所有數(shù)據(jù)計算校驗和(checksum)峡竣，并在讀取數(shù)據(jù)時驗證校驗和靠抑。針對指定字節(jié)的數(shù)目計算校驗和。字節(jié)數(shù)默認是512 字節(jié)适掰，可以通過io.bytes.per.checksum屬性設(shè)置颂碧。通過CRC-32編碼后為4字節(jié)。
DataNode 在保存數(shù)據(jù)前負責驗證checksum类浪。client 會把數(shù)據(jù)和校驗和一起發(fā)送到一個由多個DataNode 組成的隊列中载城，最后一個DataNode 負責驗證checksum。如果驗證失敗费就，會拋出一個ChecksumException诉瓦。客戶端需要處理這種異常力细〔窃瑁客戶端從DataNode 讀取數(shù)據(jù)時，也會驗證checksum眠蚂。每個DataNode 都保存了一個驗證checksum的日志煞聪。每次客戶端成功驗證一個數(shù)據(jù)塊后，都會告知DataNode 逝慧，DataNode 會更新日志昔脯。
每個DataNode 也會在一個后臺線程中運行一個DataBlockScanner啄糙，定期驗證這個 DataNode 上的所有數(shù)據(jù)塊。在用 hadoop fs get 命令讀取文件時云稚，可以用 -ignoreCrc 忽略驗證隧饼。如果是通過FileSystem API 讀取時，可以通過setVerifyChecksum(false)碱鳞，忽略驗證桑李。Hadoop中的LocalFileSystem會進行客戶端的檢驗和，寫文件時窿给，會在目錄下創(chuàng)建一個名為.filename.crc的隱藏文件贵白，如果想禁止校驗和功能，可以用RawLocalFileSystem代替LocalFileSystem 崩泡。
Configuration conf = ...
FileSystem fs = new RawLocalFileSystem();
fs.initialize(null, conf);
或者直接設(shè)置fs.file.impl屬性為org.apache.hadoop.fs.RawLocalFileSystem禁荒，這樣會全局禁用checksum。LocalFileSystem內(nèi)部使用了ChecksumFileSystem完成checksum工作角撞。通過ChecksumFileSystem可以添加校驗和功能呛伴。
HA高可用
冗余副本
HDFS處理節(jié)點失效的一個方法就是數(shù)據(jù)冗余，即對數(shù)據(jù)做多個備份谒所，在HDFS中可以通過配置文件設(shè)置備份的數(shù)量热康，如果不進行設(shè)置，這個數(shù)量默認為3劣领。注意參數(shù)dfs.replication.min和dfs.replication的區(qū)別：在一個塊被寫入期間姐军，只要至少寫入了dfs.replication.min個副本數(shù)（默認是1），寫操作就會成功尖淘，直到達到其目標副本數(shù)dfs.replication（默認是3）
HDFS副本在機架上如何分布奕锌？
HDFS采用一種稱為機架感知的策略來改進數(shù)據(jù)的可靠性、可用性和網(wǎng)絡(luò)帶寬的利用率村生。在大多數(shù)情況下惊暴，HDFS副本系數(shù)是默認為3(dfs.replication)，HDFS的存放策略是將一個副本存放在本地機架節(jié)點上趁桃，一個副本存放在同一個機架的另一個節(jié)點上辽话，最后一個副本放在不同機架的節(jié)點上。這種策略減少了機架間的數(shù)據(jù)傳輸镇辉，提高了寫操作的效率屡穗。機架的錯誤遠遠比節(jié)點的錯誤少，所以這種策略不會影響到數(shù)據(jù)的可靠性和可用性忽肛。與此同時村砂，因為數(shù)據(jù)塊只存放在兩個不同的機架上，所以此策略減少了讀取數(shù)據(jù)時需要的網(wǎng)絡(luò)傳輸總帶寬屹逛。
機架感知
通常础废，大型Hadoop集群是以機架的形式來組織的汛骂，同一個機架上不同節(jié)點間的網(wǎng)絡(luò)狀況比不同機架之間的更為理想。Namenode設(shè)法將數(shù)據(jù)塊副本保存在不同的機架上以提高容錯性
HDFS如何得知哪個Datanode在哪個機架上评腺？
HDFS使用了一種稱為“機架感知”的策略帘瞭。HDFS不能夠自動判斷集群中各個Datanode的網(wǎng)絡(luò)拓撲情況，必須通過配置dfs.network.script參數(shù)來確定節(jié)點所處的機架蒿讥。文件提供了IP->rackid的翻譯蝶念，NameNode通過這個得到集群中各個Datanode節(jié)點的rackid。
心跳機制
檢測節(jié)點失效使用“心跳機制”芋绸。每個DataNode節(jié)點周期性地向NameNode發(fā)送心跳信號媒殉。網(wǎng)絡(luò)分區(qū)可能導致一部分DataNode跟NameNode失去聯(lián)系。NameNode通過心跳信號的缺失來檢測這一情況摔敛，并將這些近期不再發(fā)送心跳信號DataNode標記為宕機廷蓉，不會再將新的IO請求發(fā)給它們。
任何存儲在宕機DataNode上的數(shù)據(jù)將不再有效马昙。DataNode的宕機可能會引起一些數(shù)據(jù)塊的副本系數(shù)低于指定值桃犬，NameNode不斷地檢測這些需要復制的數(shù)據(jù)塊，一旦發(fā)現(xiàn)就啟動復制操作行楞。
在下列情況下攒暇，可能需要重新復制：
a) 某個DataNode節(jié)點失效
b) 某個副本遭到損壞
c) DataNode上的硬盤錯誤
d) 文件的冗余因子增大
DataNode與NameNode心跳報告內(nèi)容
一個數(shù)據(jù)塊在DataNode以文件存儲在磁盤上，包括兩個文件子房，一個是數(shù)據(jù)本身扯饶，一個是元數(shù)據(jù)包括數(shù)據(jù)塊的長度、塊數(shù)據(jù)的校驗和以及時間戳池颈。當DataNode讀取block的時候，它會計算checksum钓丰，如果計算后的checksum躯砰，與block創(chuàng)建時值不一樣，說明該block已經(jīng)損壞携丁。如果塊已損壞琢歇，Client會讀取其它DataNode上的block。NameNode標記該塊已經(jīng)損壞梦鉴，然后復制block達到預期設(shè)置的文件備份數(shù)李茫。
DataNode啟動后向NameNode注冊，心跳是每3秒一次肥橙，目的是告訴namenode自己的存活狀況以及可用空間魄宏。心跳返回結(jié)果帶有NameNode給該DataNode的命令如復制塊數(shù)據(jù)到另一臺機器，或刪除某個數(shù)據(jù)塊存筏。
確認datanode宕機
（1）停止發(fā)送心跳報告
默認連續(xù)10次心跳接受不到即連續(xù)10*3=30s不間斷宠互。這10次中間只要有1次接受到了重新記錄心跳味榛。
（2）namenode發(fā)送檢查
在連續(xù)10次NameNode沒有接收到DataNode的心跳報告之后，NameNode斷定DataNode可能宕機了予跌，NameNode主動向DataNode發(fā)送檢查 NameNode會開啟后臺的守護（阻塞）進程 等待檢查結(jié)果的搏色。NameNode檢查DataNode的時間：默認5min。
默認檢查2次每次檢查5min連續(xù)2次檢查（10min）都沒有反應(yīng)確認DataNode宕機了(發(fā)送一次等待5分鐘)券册。NameNode確認一個DataNode宕機需要的總時間： 103s+300s2=630s频轿。
當DataNode啟動的時候，它會遍歷本地文件系統(tǒng)烁焙，產(chǎn)生一份HDFS數(shù)據(jù)塊和本地文件對應(yīng)關(guān)系的列表航邢，這就是報告塊（BlockReport），報告塊包含了DataNode上所有塊的列表考阱。每小時DataNode默認向NameNode發(fā)送block report翠忠。匯報DataNode的數(shù)據(jù)節(jié)點情況。
安全模式
NameNode啟動后會進入一個稱為安全模式的特殊狀態(tài)乞榨。處于安全模式的NameNode對于客戶端來說是只讀的秽之。NameNode從所有的DataNode接收心跳信號和塊狀態(tài)報告（blockreport）。
每個數(shù)據(jù)塊都有一個指定的最小副本數(shù)（dfs.replication.min）吃既，當NameNode檢測確認某個數(shù)據(jù)塊的副本數(shù)目達到這個最小值考榨，那么該數(shù)據(jù)塊就會被認為是副本安全(safely replicated)的。
在一定百分比（這個參數(shù)配置于dfs.safemode.threshold.pct鹦倚，默認值是99.9%）的數(shù)據(jù)塊被NameNode檢測確認是安全之后河质，再過若干時間后（這個參數(shù)配置于dfs.safemode.extension，默認值是30秒）震叙，NameNode將退出安全模式狀態(tài)掀鹅。接下來NameNode會確定還有哪些數(shù)據(jù)塊的副本沒有達到指定數(shù)目，并將這些數(shù)據(jù)塊復制到其他DataNode上媒楼。
校驗和
- HDFS會對寫入的所有數(shù)據(jù)計算校驗和（checksum）乐尊，并在讀取數(shù)據(jù)時驗證。Datanode在收到客戶端的數(shù)據(jù)或者復制其他Datanode的數(shù)據(jù)時划址，在驗證數(shù)據(jù)后會存儲校驗和扔嵌。正在寫數(shù)據(jù)的客戶端將數(shù)據(jù)及其校驗和發(fā)送到由一系列Datanode組成的管線，管線中的最后一個Datanode負責驗證校驗和夺颤。如果Datanode檢測到錯誤痢缎，客戶端便會收到一個ChecksumException
- 客戶端從Datanode讀取數(shù)據(jù)時，也會驗證校驗和世澜，將它們與Datanode中存儲的校驗和進行比較独旷。每個Datanode均持久保存一個用于驗證的校驗和日志，所以它知道每個數(shù)據(jù)塊的最后一次驗證時間∈聘妫客戶端成功驗證一個數(shù)據(jù)塊后蛇捌，會通知這個Datanode更新次日志
- 此外，每個Datanode也會在一個后臺運行一個稱為DataBlockScanner的進程定期驗證存儲在這個Datanode上的所有數(shù)據(jù)塊咱台。檢測到錯誤后络拌，Namenode將這個已損壞的數(shù)據(jù)塊標記為已損壞，之后從其他Datanode復制此數(shù)據(jù)的副本回溺，最后使得數(shù)據(jù)的副本達到指定數(shù)目
回收站
當用戶或應(yīng)用程序刪除某個文件時春贸，這個文件并沒有立刻從HDFS中刪除。實際上遗遵，HDFS會將這個文件重命名轉(zhuǎn)移到/trash目錄萍恕。只要文件還在/trash目錄中，該文件就可以被迅速地恢復车要。
文件在/trash中保存的時間是可配置的（配置參數(shù)fs.trash.interval）允粤，當超過這個時間時，Namenode就會將該文件從命名空間中刪除翼岁。刪除文件會使得該文件相關(guān)的數(shù)據(jù)塊被釋放类垫。注意，從用戶刪除文件到HDFS空閑空間的增加之間會有一定時間的延遲琅坡。
元數(shù)據(jù)保護
FsImage和Editlog是HDFS的核心數(shù)據(jù)悉患。如果這些文件損壞了，整個HDFS都將失效榆俺。因而售躁，Namenode可以配置成支持維護多個FsImage和Editlog的副本。任何對FsImage或者Editlog的修改茴晋，都將同步到它們的副本上陪捷。這種多副本的同步操作可能會降低Namenode每秒處理的名字空間事務(wù)數(shù)量。然而這個代價是可以接受的诺擅，因為即使HDFS的應(yīng)用是數(shù)據(jù)密集的揩局，它們也非元數(shù)據(jù)密集的。當Namenode重啟的時候掀虎，它會選取最近的完整的FsImage和Editlog來使用
快照機制
快照支持某一特定時刻的數(shù)據(jù)的復制備份。利用快照付枫，可以讓HDFS在數(shù)據(jù)損壞時恢復到過去一個已知正確的時間點烹玉。HDFS目前還不支持快照功能，但計劃會在將來的版本支持阐滩。
容錯機制
故障的類型主要有以下三種二打，針對這三種故障類型，HDFS提供了不同的故障檢測機制：
針對DataNode失效問題掂榔，HDFS使用了心跳機制继效，DataNode定期向NameNode發(fā)送心跳信息症杏，NameNode根據(jù)心跳信息判斷DataNode是否存活
針對網(wǎng)絡(luò)故障而導致無法收發(fā)數(shù)據(jù)的問題，HDFS提供了ACK的機制瑞信，在發(fā)送端發(fā)送數(shù)據(jù)后厉颤，如果沒有收到ACK并且經(jīng)過多次重試后仍然如此，則認為網(wǎng)絡(luò)故障
針對數(shù)據(jù)損壞問題凡简，所有DataNode會定期向NameNode發(fā)送自身存儲的塊清單逼友，在傳輸數(shù)據(jù)的同時會發(fā)送總和校驗碼，NameNode依次來判斷數(shù)據(jù)是否丟失或損壞
讀容錯
讀失敗時：
- DFSInputStream 會去嘗試連接列表里的下一個 DataNode 秤涩，同時記錄下這個異常節(jié)點
- DFSInputStream 也會對獲取到的數(shù)據(jù)核查 checknums 帜乞。如果損壞的 block 被發(fā)現(xiàn)了，DFSInputStream 就試圖從另一個擁有備份的 DataNode 中去讀取備份塊中的數(shù)據(jù)
- 最后異常數(shù)據(jù)的同步工作也是由 NameNode 來安排完成
寫容錯
當寫流程中一臺 DataNode 宕機了：
首先 pipeline 被關(guān)閉筐眷，在確認隊列中的剩下的 package 會被添加進數(shù)據(jù)隊列的起始位置上不再發(fā)送黎烈，以防止在失敗的節(jié)點下游的節(jié)點再丟失數(shù)據(jù)
然后，存儲在正常的 DataNode 上的 block 會被指定一個新的標識匀谣，并將該標識傳遞給 NameNode照棋，以便故障DataNode在恢復后可以刪除自己存儲的那部分已經(jīng)失效的數(shù)據(jù)塊
失敗節(jié)點會從 pipeline 中移除，然后剩下兩個好的 DataNode 會組成一個的新的 pipeline 振定，剩下的這些 block 的包會繼續(xù)寫進 pipeline 中正常的 DataNode 中
最后必怜，NameNode 會發(fā)現(xiàn)節(jié)點宕機導致部分 block 的塊備份數(shù)小于規(guī)定的備份數(shù)，此時NameNode 會安排使節(jié)點的備份數(shù)滿足 dfs.replication 配置要求
DataNode失效
在NameNode中會持有數(shù)據(jù)塊表和DataNode兩張表后频。數(shù)據(jù)塊表存儲著某個數(shù)據(jù)塊（包括副本）所在的DataNode梳庆，DataNode表存儲著每個DataNode中保存的數(shù)據(jù)塊列表。由于DataNode會周期性地給NameNode發(fā)送自己所持有的數(shù)據(jù)塊信息卑惜，因此NameNode會持續(xù)更新數(shù)據(jù)塊表和DataNode表膏执。如果發(fā)現(xiàn)某個DataNode上的數(shù)據(jù)塊錯誤，NameNode會從數(shù)據(jù)塊表刪除該數(shù)據(jù)塊露久；如果發(fā)現(xiàn)某個DataNode失效更米，NameNode會對兩張表進行更新。NameNode還會周期性地掃描數(shù)據(jù)塊表毫痕，如果發(fā)現(xiàn)數(shù)據(jù)塊表中某個數(shù)據(jù)庫的備份數(shù)量低于所設(shè)置的備份數(shù)征峦，則會協(xié)調(diào)從其它DataNode復制數(shù)據(jù)到另一個DataNode上完成備份。
HDFS副本放置策略
如果寫請求出現(xiàn)在某個DataNode上消请，第一個副本就會存放在當前DataNode所在的機器上栏笆，如果該機器負載過重，可以將該備份放在同一個機架上的隨機機器上臊泰。接著第二個副本就會存放在不同于第一個副本所在機架的機架上蛉加，第三個副本會隨機存放在第二個副本所在機架的任一DataNode上。
在三個副本的情況下，第一個副本與原數(shù)據(jù)在相同機器上针饥，另外兩個副本放在其它機架的隨機機器上厂抽。這樣的設(shè)置可以使得性能與容災兼?zhèn)洌瑑?yōu)先從同機器上獲取備份數(shù)據(jù)丁眼，減少數(shù)據(jù)傳輸開銷筷凤；在該機器宕機的情況下，從另一個機架獲取備份數(shù)據(jù)户盯，避免同一個機架的機器集體宕機的情況出現(xiàn)嵌施。
HDFS的HA架構(gòu)
以上的所有容錯都是基于DataNode的故障問題進行考慮的，但是NameNode本身就存在單點故障莽鸭，如果NameNode出現(xiàn)故障吗伤，則整個集群會直接宕機。因此HDFS提供了HA的架構(gòu)硫眨，對于一個典型的HA集群而言足淆，NameNode會被配置在兩臺獨立的機器上，在任何時間上礁阁，一個NameNode處于Active狀態(tài)巧号，而另一個NameNode處于Standby狀態(tài)，Active狀態(tài)的NameNode會響應(yīng)集群中所有的客戶端的請求姥闭，Standby狀態(tài)的NameNode只是作為一個副本丹鸿，保證在必要的時候提供一個快速的轉(zhuǎn)移，使得上層對NameNode的切換無感知棚品，Standby NameNode與Active NameNode應(yīng)時刻保持同步靠欢，在Active NameNode和Standby NameNode之間要有個共享的存儲日志的地方，Active NameNode把EditLog寫到共享的存儲日志中铜跑，Standby NameNode讀取日志并執(zhí)行门怪，使得Active NameNode和Standby NameNode內(nèi)存中的HDFS元數(shù)據(jù)保持同步。
小編把阿里巴巴锅纺、騰訊掷空、美團等大廠的Java和大數(shù)據(jù)面試題整理成了電子書和資源，目錄如下：
資源
鏈接: https://pan.baidu.com/s/1ifHfofjawqD9jn2lvoh0NA 提取碼: h79x
另外囤锉，微信搜索關(guān)注【import_bigdata】,回復【資源】坦弟，還有幾百G大數(shù)據(jù)資源下載！
歡迎關(guān)注官地，《大數(shù)據(jù)成神之路》系列文章
