大數據課程
一、分佈式存儲HDFS
1、 Hadoop的歷史
-
作者Doug Cutting
-
Lucene
-
三駕馬車
GFS
MapReduce
BigTable -
hadoop生態圈
hdfs
mapreduce
yarn
common
2、HDFS的存儲原理
各個角色的作用
-
NameNode
1、接受客戶端的讀寫請求
2、管理元數據
①上傳的文件的權限
②上傳文件的屬主以及屬組
③上傳文件的時間
④上傳文件的block數以及ID號
⑤每一個Block的位置信息是由DN在集羣啓動之時彙報的 不會持久化
⑥各個DN位置信息
3、管理DN
-
DataNode
1、接受客戶端的讀請求
2、存儲block塊
3、向active NN彙報心跳
4、構建pipeline
5、管理本機上block元數據
-
SNN
負責持久化
-
拉取NN節點上的edits+fsimage文件 合併
edits文件存儲客戶端對HDFS的操作
爲什麼要搞edits來存儲操作呢？
因爲如果不把操作存儲在文件中，而是在內存中，在SNN獲取NN的數據之時，NN的服務會被迫暫停，直到數據傳輸完畢，降低了整個集羣的可用性。
如果數據存儲在在edits文件中，在SNN從NN獲取數據的過程就必拿的非常簡單，不會對NN的服務造成影響。
合併過程
文件拉取之時，在NN節點上回創建edits_new 目的就是爲了存儲在合併期間對HDFS的操作
1、基於拉來的edits文件重演 產出元數據
2、將重演產出的元數據合併到fsimage中
3、將合併後fsimage推送給NN
4、將edits.new文件的後綴去掉
合併觸發機制
1、超過3600s就合併一次
2、edits文件大小超過64M
-
ZKFC
監控各自的NN，將監控的情況彙報給ZK集羣
接受zk的選舉結果，確認一下另外一個NN是否真的掛了，將自己監控的NN提升爲active狀態 -
JournalNode
寫數據的時候只需要保證半數以上的節點寫入成功就可以了
爲啥要超過半數？
防止出現腦裂問題 網絡分區問題
最終一致性/弱一致性
存儲的是edits文件
-
備用的NN
1、監控journalnode中數據變化，實時更新自己的內存元數據
2、將內存中元數據持久化到fsimage中，然後推送給NN
備份機制
如果是集羣外操作，第一個block存儲在負載不高的節點上
默認128M dfs.blocksize
嚴格按照字節切割，如果存儲的是中文，會出現亂碼問題
如果集羣內操作，在本機
第二個block在其他機架隨機一臺節點還是那個
第三個block與第二個block同機架的其他節點上
3、HDFS的讀寫流程
讀流程
寫流程
讀和寫的流程在我的另一篇博客中有詳細介紹
https://blog.csdn.net/PowerBlogger/article/details/82989434
1.僞分佈式 測試環境使用
2.完全分佈式
hdfs-site.xml
core-site,xml
slaves從節點hostname
2.高可用的完全分佈式
hdfs-site,xnml
core-site,xml
slaves從節點hostname
先啓動所有的journalnode
格式化
將本機的NN啓動
去備用的NN節點，同步元數據
格式化zkfc (先啓動zookeeper)
關閉所有的節點
start-dfs.sh
安全模式
1、NN會將fsimage與edits合併
2、檢查各個節點上的block塊以及副本是否符合要求 若不符合要求，指揮存儲數據丟 失的DN做備份
3、檢查各個DN的健康情況
4、 正常對外提供存儲服務
HDFS優缺點
優點
-
副本機制，所以數據更安全
-
因爲是分佈式存儲，所以適合批處理
-
高可用行 元數據持久化
-
禁掉了一些功能，使得集羣更加完美
1、修改
2、文件一旦上傳成功，就不能修改block塊的大小
缺點
-
無法毫秒級的讀寫數據
讀寫複雜需要找nn請求
形成管道，文件切割block block packet
-
不適合存儲大量的小文件
容易造成元數據過多，NN內存溢出
-
解決辦法
1、將小文件合併成一個大文件
2、聯邦機制
-
-
不能併發寫入，但是可以併發的讀
3、Java API
-
準備環境
1.本機配置HADOOP_HOME
2.替換bin目錄
3.修改用戶名
4.導入jar包
5.安裝插件，方便在eclipse中操作hdfs集羣