目錄2.3 學點datanode
缺點隨著資料量越來越大，在一台機器上已經無法儲存所有的資料了，那我們會將這些資料分配到不同的機器來進行儲存，但是這就帶來乙個問題：不方便管理和維護
所以，我們就希望有乙個系統可以將這些分布在不同操作伺服器上的資料進行統一管理，這就有了分布式檔案系統
hdfs是分布式檔案系統的其中一種（目前用得最廣泛的一種）在使用hdfs的時候是非常簡單的：雖然hdfs是將檔案儲存到不同的機器上，但是我去使用的時候是把這些檔案當做是儲存在一台機器的方式去使用（背後卻是多台機器在執行）：
好比：我呼叫了乙個rpc介面，我給他引數，他返回乙個response給我。rpc介面做了什麼事其實我都不知道的（可能這個rpc介面又調了其他的rpc介面）-----遮蔽掉實現細節，對使用者友好
hdfs使用
明確一下：hdfs就是乙個分布式檔案系統，乙個檔案系統，我們用它來做什麼？存資料呀。
下面，我們來了解一下hdfs的一些知識，能夠幫我們更好地去「使用」hdfs
從上面我們已經提到了，hdfs作為乙個分布式檔案系統，那麼它的資料是儲存在多個系統上的。
例如，下面的圖：乙個1gb的檔案，會被切分成幾個小的檔案，每個伺服器都會存放一部分。
那肯定會有人會問：那會切分多少個小檔案呢？
預設以128mb的大小來切分，每個128mb的檔案，在hdfs叫做塊(block)
顯然，這個128mb大小是可配的。如果設定為太小或者太大都不好。如果切分的檔案太小，那乙份資料可能分布到多台的機器上（定址時間就很慢）。
如果切分的檔案太大，那資料傳輸時間的時間就很慢。
ps：老版本預設是64mb乙個使用者發出了乙個1gb的檔案請求給hdfs客戶端，hdfs客戶端會根據配置(現在預設是128mb)，對這個檔案進行切分，所以hdfs客戶端會切分為8個檔案(也叫做block)，然後每個伺服器都會儲存這些切分後的檔案(block)。現在我們假設每個伺服器都儲存兩份。這些存放真實資料的伺服器，在hdfs領域叫做datanode
現在問題來了，hdfs客戶端按照配置切分完以後，怎麼知道往哪個伺服器（datanode）放資料呢？這個時候，就需要另乙個角色了，管理者（namenode）。
namenode實際上就是管理檔案的各種資訊（這種資訊專業點我們叫做metadata「元資料」），其中包括：檔案路徑名，每個block的id和存放的位置等等。
所以，無論是讀還是寫，hdfs客戶端都會先去找namenode，通過namenode得知相應的資訊，再去找datanode
作為乙個分布式系統（把大檔案切分為多個小檔案，儲存到不同的機器上），如果沒有備份的話，只要有其中的一台機器掛了，那就會導致「資料」是不可用狀態的。
kafka對partition備份，elasticsearch對分片進行備份，而到hdfs就是對block進行備份。盡可能將資料備份到不同的機器上，即便某台機器掛了，那就可以將備份資料拉出來用。注：這裡的備份並不需要hdfs客戶端去寫，只要datanode之間互相傳遞資料就好了從上面我們可以看到，namenode是需要處理hdfs客戶端請求的。（因為它是儲存元資料的地方，無論讀寫都需要經過它）。
現在問題就來了，namenode是怎麼存放元資料的呢？
現在也有個問題：
如果namenode一直長期執行的話，那editlog檔案應該會越來越大（因為所有的修改元資料資訊都需要在這追加一條）。重啟的時候需要依賴editlog檔案來恢復資料，如果檔案特別大，那啟動的時候不就特別慢了嗎？
的確是如此的，那hdfs是怎麼做的呢？
為了防止editlog過大，導致在重啟的時候需要較長的時間恢復資料，所以namenode會有乙個記憶體快照，叫做fsimage
說到快照，有沒有想起redis的rdb這樣一來，重啟的時候只需要載入記憶體快照fsimage+部分的editlog就可以了。想法很美好，現實還需要解決一些事：我什麼時候生成乙個記憶體快照fsimage？我怎麼知道載入哪一部分的editlog？
問題看起來好像複雜，其實我們就只需要乙個定時任務。
hdfs也是類似上面這樣幹的，只不過它不是在namenode起個定時的任務跑，而是用了乙個新的角色：secondnamenode。至於為什麼？
可能hdfs覺得合併所耗費的資源太大了，不同的工作交由不同的伺服器來完成，也符合分布式的理念。
現在問題還是來了，此時的架構namenode是單機的。secondnamenode的作用只是給namenode合併editlog和fsimage檔案，如果namenode掛了，那client就請求不到了，而所有的請求都需要走namenode，這導致整個hdfs集群都不可用了。
於是我們需要保證namenode是高可用的。一般現在我們會通過zookeeper來實現。架構圖如下：
主namenode和從namenode需要保持元資料的資訊一致（因為如果主namenode掛了，那從namenode需要頂上，這時從namenode需要有主namenode的資訊）。
所以，引入了shared edits來實現主從namenode之間的同步，shared edits也叫做journalnode ['dʒɜːnl]。實際上就是主namenode如果有更新元資料的資訊，它的editlog會寫到journalnode，然後從namenode會在journalnode讀取到變化資訊，然後同步。從namenode也實現了上面所說的secondnamenode功能（合併editlog和fsimage）
小結從上面我們就知道，我們的資料是存放在datanode上的（還會備份）。
如果某個datanode掉線了，那hdfs是怎麼知道的呢？
datanode啟動的時候會去namenode上註冊，他倆會維持心跳，如果超過時間閾值沒有收到datanode的心跳，那hdfs就認為這個datanode掛了。
還有乙個問題就是：
我們將block存到datanode上，那還是有可能這個datanode的磁碟損壞了部分，而我們datanode沒有下線，但我們也不知道損壞了。
乙個block除了存放資料的本身，還會存放乙份元資料（包括資料塊的長度，塊資料的校驗和，以及時間戳）。datanode還是會定期向namenode上報所有當前所有block的資訊，通過元資料就可校驗當前的block是不是正常狀態。
HDFS面試問題整理
1 hdfs讀取流程，小檔案處理 2 hdfs的資料壓縮演算法 3 datanode什麼情況下不會進行備份 4 hdfs的體系結構 5 hdfs的儲存機制 6 hdfs的基本原理 7 hdfs上傳檔案的流程 8 hadoop1.0和2.0hdfs的block各為多少？9 hdfs為什麼不太適合小檔案...
Hadoop基礎 HDFS結構
1 簡述hdfs的特點以及優點缺點。hdfs的優點 1 支援超大檔案的儲存 2 支援流式檔案訪問。3 執行於廉價的商用機器集群。hdfs的缺點 1 不適合低延遲資料訪問 2 無法高效儲存大量小檔案 3 不支援多使用者寫入及任意修改檔案。2 簡述namenode,datanode,secondary ...
shell 基礎整理
shell 基礎整理 1，指令碼檔名以 sh 2，命名變數 1 自定義變數 name zhangsan 2 evn 大小寫字母 3 echo name echo path 4 作用域 預設自定義變數 區域性 通過呼叫多個shell程序 開啟shell 父 再次開啟shell 子 env shlvl ...