3.1.1 計算機集群結(jié)構(gòu)

1. 分布式文件系統(tǒng)，把文件分布存儲到多個計算機節(jié)點上，成千上萬的計算機節(jié)點構(gòu)成計算機集群。
2. 與之前使用多個處理器和專用高級硬件的并行化處理裝置不同的是,此由普通硬件構(gòu)成，降低開銷。

有點像路由網(wǎng)絡(luò)

STR.png

3.1.2 分布式文件系統(tǒng)的結(jié)構(gòu)

1. 一類叫“主節(jié)點”(Master Node)或者也被稱為“名稱結(jié)點”(NameNode)
2. 一類叫“從節(jié)點”（Slave Node）或者也被稱為“數(shù)據(jù)節(jié)點”(DataNode)

STR1.png

主節(jié)點：像核心交換機，記錄路由表等等重要信息
從節(jié)點：像單點的終端服務(wù)器，提供數(shù)據(jù)/流量服務(wù)

3.2 HDFS簡介

優(yōu)點：
●兼容廉價的硬件設(shè)備
●流數(shù)據(jù)讀寫
●大數(shù)據(jù)集
●簡單的文件模型
●強大的跨平臺兼容性

局限
●不適合低延遲數(shù)據(jù)訪問
●無法高效存儲大量小文件
●不支持多用戶寫入及任意修改文件

3.3.2 名稱節(jié)點

?在HDFS中，名稱節(jié)點（NameNode）負責管理分布式文件系統(tǒng)的命名空間
（Namespace），保存了兩個核心的數(shù)據(jù)結(jié)構(gòu)，即FsImage和EditLog

component-1.png

namenode.png

名稱節(jié)點運行期間EditLog不斷變大的問題: SecondaryNameNode第二名稱節(jié)點

第二名稱節(jié)點是HDFS架構(gòu)中的一個組成部分，它是用來保存名稱節(jié)點中對HDFS 元數(shù)據(jù)信息的備份，并減少名稱節(jié)點重啟的時間。SecondaryNameNode一般是單獨運行在一臺機器上

SecondaryNameNode.png

FsImage: 有點像配置和現(xiàn)場日志
EditLog：有點像CLI歷史
太長的時候就搞個backup file，存另一臺機做備份。
然后跑一個新的日志。

3.3.2 數(shù)據(jù)節(jié)點（DataNode）

?數(shù)據(jù)節(jié)點是分布式文件系統(tǒng)HDFS的工作節(jié)點，負責數(shù)據(jù)的存儲和讀取，會根據(jù)客戶端或者是名稱節(jié)點的調(diào)度來進行數(shù)據(jù)的存儲和檢索，并且向名稱節(jié)點定期發(fā)送自己所存儲的塊的列表

?每個數(shù)據(jù)節(jié)點中的數(shù)據(jù)會被保存在各自節(jié)點的本地Linux文件系統(tǒng)中

3.4.1. HDFS體系結(jié)構(gòu)概述

這里比較像路由網(wǎng)絡(luò)，名稱節(jié)點像一個核心交換機，
其他數(shù)據(jù)節(jié)點就像一個單臺的服務(wù)器，就是把流量變成了一個數(shù)據(jù)網(wǎng)絡(luò)。
文件號或數(shù)據(jù)塊號就像流量里面的報頭一樣，數(shù)據(jù)塊號就像路由表，
核心交換機，決定它下一跳是哪里，這里的namenode就決定datanode的服務(wù)器在哪里。
這里提到的文件均衡，就有點像流量的負載均衡。

HDFS采用了主從（Master/Slave）結(jié)構(gòu)模型，一個HDFS集群包括一個名稱節(jié)點（NameNode）和若干個數(shù)據(jù)節(jié)點（DataNode）（如圖3-4所示）。名稱節(jié)點作為中心服務(wù)器，負責管理文件系統(tǒng)的命名空間及客戶端對文件的訪問。集群中的數(shù)據(jù)節(jié)點一般是一個節(jié)點運行一個數(shù)據(jù)節(jié)點進程，負責處理文件系統(tǒng)客戶端的讀/寫請求，在名稱節(jié)點的統(tǒng)一調(diào)度下進行數(shù)據(jù)塊的創(chuàng)建、刪除和復制等操作。每個數(shù)據(jù)節(jié)點的數(shù)據(jù)實際上是保存在本地Linux文件系統(tǒng)中的

HDFS-str.png

3.4.3 通信協(xié)議

? 所有的HDFS通信協(xié)議都是構(gòu)建在TCP/IP協(xié)議基礎(chǔ)之上的

• Hadoop 1.0 的局限性
  HDFS只設(shè)置唯一一個名稱節(jié)點，這樣做雖然大大簡化了系統(tǒng)設(shè)計，但也帶來了一些明顯的局限性，具體如下：
  （1）命名空間的限制：名稱節(jié)點是保存在內(nèi)存中的，因此，名稱節(jié)點能夠容納的對象（文件、塊）的個數(shù)會受到內(nèi)存空間大小的限制。
  （2）性能的瓶頸：整個分布式文件系統(tǒng)的吞吐量，受限于單個名稱節(jié)點的吞吐量。
  （3）隔離問題：由于集群中只有一個名稱節(jié)點，只有一個命名空間，因此，無法對不同應(yīng)用程序進行隔離。
  （4）集群的可用性：一旦這個唯一的名稱節(jié)點發(fā)生故障，會導致整個集群變得不可用。

這里無論是數(shù)據(jù)的備份還是流水，跟路由器和交換機的溝通是很像的，
它都需要有響應(yīng)，然后要有確認。
1. 命名空間的限制，就像路由表不能太大，不然就很難跳過去
2. 性能的瓶頸，就像通信報文的窗口期不能太大，單個名稱節(jié)點的吞吐量太大，時延會很大
3. 隔離問題，就像內(nèi)網(wǎng)的時候，如果你隔離不好的話就會串IP
4. 集訓可用性，就像核心交換機不能只有一臺，必須得有冗余，不然一臺機當了，整個網(wǎng)絡(luò)都當?shù)袅恕?

3.5 HDFS存儲原理

3.5.1 冗余數(shù)據(jù)保存

copy-1.png

1.數(shù)據(jù)存放

?第一個副本：放置在上傳文件的數(shù)據(jù)節(jié)點；如果是集群外提交，則隨機挑選一臺磁盤不太滿、CPU不太忙的節(jié)點
?第二個副本：放置在與第一個副本不同的機架的節(jié)點上
?第三個副本：與第一個副本相同機架的其他節(jié)點上
?更多副本：隨機節(jié)點

how-to-place.png

3.5.3 數(shù)據(jù)錯誤與恢復

1. 名稱節(jié)點出錯： 備機上
   根據(jù)備份服務(wù)器SecondaryNameNode中的FsImage和Editlog數(shù)據(jù)進行恢復。

2. 數(shù)據(jù)節(jié)點出錯： failed heartbeat--> 減壞點-->重生冗余
   ?HDFS和其它分布式文件系統(tǒng)的最大區(qū)別就是可以調(diào)整冗余數(shù)據(jù)的位置
   a. failed heartbeat: 數(shù)據(jù)節(jié)點就會被標記為“宕機”，節(jié)點上面的所有數(shù)據(jù)都會被標記為“不可讀”，名稱節(jié)點不會再給它們發(fā)送任何I/O請求
   b. 一旦發(fā)現(xiàn)某個數(shù)據(jù)塊的副本數(shù)量小于冗余因子，就會啟動數(shù)據(jù)冗余復制，為它生成新的副本

3. 數(shù)據(jù)出錯: 校驗-->重傳 -->修正
   ?客戶端在讀取到數(shù)據(jù)后，會采用md5和sha1對數(shù)據(jù)塊進行校驗，以確定讀取到正確的數(shù)據(jù)
   ?校驗出錯，客戶端就會請求到另外一個數(shù)據(jù)節(jié)點讀取該文件塊，并且向名稱節(jié)點報告這個文件塊有錯誤，名稱節(jié)點會定期檢查并且重新復制這個塊

3.6 HDFS數(shù)據(jù)讀寫過程

暫時不會寫java，讓我遲點再來看。
粗看好像跟python的 open, read, close 很像

3.7.1 HDFS常用命令

粗看下去就是 linux指令前面加個Hadoop...

2018.6.9.

以上括起來的注釋來自我的瞎類比，這樣對我自己比較好學。