在配置hbase集群將 hdfs 掛接到其它鏡像盤時，有不少困惑的地方，結合以前的資料再次學習; 大數據底層技術的三大基石起源于Google在2006年之前的三篇論文GFS、Map-Reduce、 Bigtable，其中GFS、Map-Reduce技術直接支持了ApacheHadoop項目的誕生，Bigtable催生了NoSQL這個嶄新的數據庫領域，由于map-Reduce處理框架高延時的缺陷， Google在2009年后推出的Dremel促使了實時計算系統的興起，以此引發大數據第二波技術浪潮，一些大數據公司紛紛推出自己的大數據查詢分析產品，如： Cloudera 開源了大數據查詢分析引擎 Impala 、 Hortonworks 開源了 Stinger 、 Fackbook 開源了 Presto 、UC Berkeley AMPLAB實驗室開發了 Spark 計算框架，所有這些技術的數據來源均基于hdsf, 對于 hdsf 最基本的不外乎就是其讀寫操作
目錄：hdfs 名詞解釋hdsf 架構NameNode(NN)Secondary NNhdfs 寫文件hdfs 讀文件block持續化結構HDFS名詞解釋：Block： 在HDFS中，每個文件都是采用的分塊的方式存儲，每個block放在不同的datanode上，每個block的標識是一個三元組（ block id， numBytes，generationStamp ），其中block id是具有唯一性，具體分配是由namenode節點設置，然后再由datanode上建立block文件，同時建立對應block meta文件Packet： 在DFSclient與DataNode之間通信的過程中，發送和接受數據過程都是以一個packet為基礎 的方式進行Chunk： 中文名字也可以稱為塊，但是為了與block區分，還是稱之為chunk。在DFSClient與DataNode之間通信的過程中，由于文件采用的是基于塊的方式來進行的，但是在發送數據的過程中是以packet的方式來進行的， 每個packet包含了多個chunk ，同時對于每個chunk進行checksum計算，生成checksum bytes小結：Packet結構與定義： Packet分為兩類，一類是實際數據包，另一類是heatbeat包。一個Packet數據包的組成結構，如圖所示
上圖中，一個Packet是由Header和Data兩部分組成，其中Header部分包含了一個Packet的概要屬性信息，如下表所示：
Data部分是一個Packet的實際數據部分，主要包括一個4字節校驗和（Checksum）與一個Chunk部分，Chunk部分最大為512字節在構建一個Packet的過程中，首先將字節流數據寫入一個buffer緩沖區中，也就是從偏移量為25的位置（checksumStart）開始寫Packet數據Chunk的Checksum部分，從偏移量為533的位置（dataStart）開始寫Packet數據的Chunk Data部分，直到一個Packet創建完成為止。當寫一個文件的最后一個Block的最后一個Packet時，如果一個Packet的大小未能達到最大長度，也就是上圖對應的緩沖區中，Checksum與Chunk Data之間還保留了一段未被寫過的緩沖區位置，在發送這個Packet之前，會檢查Chunksum與Chunk Data之間的緩沖區是否為空白緩沖區（gap），如果有則將Chunk Data部分向前移動，使得Chunk Data 1與Chunk Checksum N相鄰，然后才會被發送到DataNode節點hdsf架構：hdfs的構架圖網上一堆，抓了一張表述比較清楚的圖如下, 主要包含因類角色：Client、NameNode、SecondayNameNode、DataNode
HDFS Client: 系統使用者，調用HDFS API操作文件;與 NN交互獲取文件元數據 ;與DN交互進行數據讀寫, 注意： 寫數據時文件 切分由Client完成 Namenode： Master節點（也稱元數據節點），是系統唯一的管理者。負責元數據的管理( 名稱空間和數據塊映射信息 );配置 副本策略 ；處理客戶端請求Datanode： 數據存儲節點(也稱Slave節點)， 存儲實際的數據；執行 數據塊的讀寫；匯報存儲信息給NNSecondary NameNode： 小弟角色，分擔大哥namenode的工作量；是NameNode的冷備份； 合并fsimage和fsedits然后再發給namenode, 注意： 在hadoop 2.x 版本，當啟用 hdfs ha 時，將沒有這一角色。（詳見第二單）解釋說明：hdfs構架原則：NameNode:NameNode是整個文件系統的管理節點，也是HDFS中最復雜的一個實體，它維護著HDFS文件系統中最重要的兩個關系：第一個關系即目錄樹、元數據和數據塊的索引信息會 持久化到物理存儲 中，實現是保存在命名空間的鏡像 fsimage 和編輯 日志edits 中， 注意： 在fsimage中， 并沒有記錄每一個block對應到哪幾個Datanodes的對應表信息第二個關系是在NameNode啟動后，每個Datanode對本地磁盤進行掃描，將 本Datanode上保存的block信息匯報給Namenode ，Namenode在接收到每個Datanode的塊信息匯報后，將接收到的塊信息，以及其所在的Datanode信息等保存在內存中。HDFS就是通過這種塊信息匯報的方式來 完成 block -> Datanodes list的對應表構建fsimage 記錄了自最后一次檢查點之前HDFS文件系統中所有目錄和文件的序列化信息;edits 是元數據操作日志(記錄每次保存fsimage之后到下次保存之間的所有hdfs操作)在NameNode啟動時候，會先將fsimage中的文件系統元數據信息 加載到內存 ，然后根據eidts中的記錄將內存中的元數據 同步至最新狀態， 將這個新版本的 FsImage 從內存中保存到本地磁盤上，然后刪除 舊的 Editlog，這個過程稱為一個 檢查 點 (checkpoint)， 多長時間做一次 checkpoint？（ 見第四章 參數配置 ） checkpoint 能手工觸發嗎？ 驗證重啟hdfs服務后editlog沒刪除呢？類似于 據庫中的檢查點，為了避免edits日志過大，在Hadoop1.X中，SecondaryNameNode會按照時間閾值（比如24小時）或者edits大小閾值（比如1G），周期性的將fsimage和edits的合并，然后將最新的fsimage推送給NameNode。而在Hadoop2.X中，這個動作是由Standby NameNode來完成 .由此可看出，這兩個文件一旦損壞或丟失，將導致整個HDFS文件系統不可用，在HDP2.4安裝(五)：集群及組件安裝 集 群安裝過程中，hdfs 默認的只能選擇一個NN，是否意味著 NN存在單點呢？，2.X版本默認block的大小是 128M （見第四章參數配置）
Client將FileA按64M分塊。分成兩塊，block1和Block2;Client向nameNode發送寫數據請求，如圖藍色虛線①------>NameNode節點，記錄block信息。并返回可用的DataNode ( NameNode按什么規則返回DataNode? 參見第三單 hadoop機架感知 ），如粉色虛線②--------->Block1: host2,host1,host3Block2: host7,host8,host4client向DataNode發送block1；發送過程是以流式寫入，流式寫入過程如下：將64M的block1按64k的packet劃分然后將第一個packet發送給host2host2接收完后，將第一個packet發送給host1，同時client想host2發送第二個packethost1接收完第一個packet后，發送給host3，同時接收host2發來的第二個packet以此類推，如圖紅線實線所示，直到將block1發送完畢host2,host1,host3向NameNode，host2向Client發送通知，說“消息發送完了”。如圖粉紅顏色實線所示client收到host2發來的消息后，向namenode發送消息，說我寫完了。這樣就真完成了。如圖黃色粗實線發送完block1后，再向host7，host8，host4發送block2，如圖藍色實線所示 說明：
客戶端通過調用FileSystem對象的open()方法來打開希望讀取的文件，對于HDFS來說，這個對象時分布文件系統的一個實例；DistributedFileSystem通過使用RPC來調用NameNode以確定文件起始塊的位置，同一Block按照重復數會返回多個位置，這些位置按照 Hadoop集群拓撲結構排序，距離客戶端近的排在前 面 ( 詳見第三章 ）前兩步會返回一個FSDataInputStream對象，該對象會被封裝成DFSInputStream對象，DFSInputStream可以方便的管理datanode和namenode數據流，客戶端對這個輸入流調用read()方法存儲著文件起始塊的DataNode地址的DFSInputStream隨即連接距離最近的DataNode，通過對數據流反復調用read()方法，將數據從DataNode傳輸到客戶端到達塊的末端時，DFSInputStream會關閉與該DataNode的連接，然后尋找下一個塊的最佳DataNode，這些操作對客戶端來說是透明的，客戶端的角度看來只是讀一個持續不斷的流一旦客戶端完成讀取，就對FSDataInputStream調用close()方法關閉文件讀取block持續化結構: DataNode節點上一個Block持久化到磁盤上的物理存儲結構，如下圖所示：
每個Block文件（如上圖中blk_1084013198文件）都對應一個meta文件（如上圖中blk_1084013198_10273532.meta文件）， Block文件是一個一個Chunk的二進制數據 （每個Chunk的大小是512字節），而meta文件是與 每一個Chunk對應的Checksum數據 ，是序列化形式存儲Loading...
京公網安備 11010502049343號