Hadoop核心組件之HDFS

HDFS：分佈式文件系統

一句話總結

一個文件先被拆分爲多個Block塊（會有Block-ID：方便讀取數據），以及每一個Block是有幾個副本的形式存儲

1個文件會被拆分紅多個Block
blocksize：128M（Hadoop2.0之後默認的塊大小，能夠自定義配置）
130M ==> 2個Block： 128M 和 2M

HDFS設計目標

• 巨大的分佈式文件系統
• 知足大數據場景基本數據存儲的要求
• 廉價的機器上
• 當你的存儲空間不夠，你能夠水平橫向擴展機器方式提升

HDFS架構

NameNode + N個DataNode

典型的主從架構，即：
1 Master(NameNode/NN) 帶 N個Slaves(DataNode/DN)
建議：NN和DN是部署在不一樣的節點上
PS：
常見的主從架構還有：HDFS/YARN/HBase
主從架構一個難題就是：如何保證HA的問題，不少時候會使用Zookeeper來配置使用

NameNode/NN:主節點Master
1）負責客戶端請求的響應
2）負責元數據（文件的名稱、副本系數、Block存放的DN）的管理

DataNode/DN：從節點Slaves
1）存儲用戶的文件對應的數據塊(Block)
2）要按期向NN發送心跳信息，彙報自己及其全部的block信息，健康情況

HDFS副本機制

• replication factor：副本系數、副本因子

• 一個大的文件會被拆分爲許多塊，最終以多副本的方式存儲在多個節點上

• 一個文件，除了最後一個，其他全部塊的大小都是一致的

問題：那麼如何爲每一個Block選擇存儲在哪些節點上呢？

Rack表明的是機架：通常三份副本分別是這樣存儲的
第一份副本：存儲在當前提交存儲的機架中當前節點上
第二份副本：存儲在非當前機架上的某一節點上
第三份副本：和第二副本統一機架的不一樣節點之上
建議：生產只可以，起碼劃分兩個及其以上的機架

HDFS Shell

Usage: hdfs dfs [COMMAND [COMMAND_OPTIONS]]
hadoop fs -ls / 等價 hdfs dfs -ls /

[root@hadoop000 data]# ls
hadoop-tmp  hello.txt
上傳：
 [root@hadoop000 data]# hadoop fs -put hello.txt /
下載：
[root@hadoop000 data]# hadoop fs -get /test/a/b/h.txt
查看內容：
[root@hadoop000 data]# hadoop fs -text /hello.txt
[root@hadoop000 data]# hadoop fs -cat /hello.txt
創建目錄;
[root@hadoop000 data]# hadoop fs -mkdir /test
建立遞歸的目錄
[root@hadoop000 data]# hadoop fs -mkdir -p /test/a/b
遞歸展現目錄文件：
[root@hadoop000 data]# hadoop fs -ls -R /
本地拷貝到hdfs:
[root@hadoop000 data]# hadoop fs -copyFromLocal hello.txt /test/a/b/h.txt
刪除文件：
[root@hadoop000 data]# hadoop fs -rm /hello.txt
遞歸刪除文件夾：
[root@hadoop000 data]# hadoop fs -rm -R /test

HSFS的讀寫流程，工做原理（面試）

漫畫圖解
https://blog.csdn.net/eric_sunah/article/details/41546863

Client：客戶端，經過HDFS Shell或Java API發起讀寫請求
1個NameNode：全局把控
N 個DataNode: 數據存儲

寫數據流程：

1.客戶端把文件拆分爲多個Block
2.NameNode:提供剛纔拆分出來的Block塊的具體datanode存儲位置
3.DataNode:存儲Block塊的數據，把3個副本數據寫完

讀數據流程：

1.用戶提供文件名就能夠給客戶端
2.客戶端發起請求給NameNode
3.NameNode就會告訴客戶端具體的存儲位置和塊
4.發起最近距離節點請求給DataNode下載數據

HDFS的優缺點

優勢：
數據冗餘,硬件容錯
一次寫入，屢次讀取數據
適合存儲大文件
構建在廉價機器上

缺點： 延時性高 不適合小文件存儲