網上關於hdfs的一些初步總結不大好找，搞得初步瞭解hdfs花了比較多時間。現在準備寫點初步學習總結以便能加深記憶，順便爲網上多添點資料。
以下就從5大方面進行初步總結：
1. 整體框架：
總體來說，hdfs的大體框架是比較簡單的，作爲分佈式文件系統，相比普通的文件系統有很多類似之處。主要分成兩大類型節點，一個是NameNode,另一個是DataNode，前者承擔着文件系統的元信息的管理職責（比如datanode的信息，各個block的位置信息，文件名和其訪問權限信息等），某種程度而言類似一個存儲元信息的內存數據庫，所有客戶端要跟讀寫hdfs,首先訪問NameNode，讀取或寫入相關的元信息，然後根據元信息（包括路由信息）去和DateNode節點交互。後者承擔着真正的文件數據存儲能力，更多就是類似磁盤的功能，一般有多份副本，分別存儲在不同的DataNode節點上。從總體來看是典型的master-slave模式（NameNode是master, DataNode是slave），所以也存在該模式master單點故障的問題，爲了解決這個問題，hdfs引入了備份master，也就是secondary NameNode，以便在active NameNode出現故障時，能承擔起NameNode的職責。整個體系結構大致如下圖：
讀步驟：
寫步驟：
2. 目錄結構
NameNode數據持久化的目錄結構和文件如下：
├── current
│ ├── VERSION
│ ├──edits_0000000000000000001-0000000000000000007
│ ├──edits_0000000000000000008-0000000000000000015
│ ├──edits_0000000000000000016-0000000000000000022
│ ├── edits_0000000000000000023-0000000000000000029
│ ├──edits_0000000000000000030-0000000000000000030
│ ├──edits_0000000000000000031-0000000000000000031
│ ├──edits_inprogress_0000000000000000032
│ ├──fsimage_0000000000000000030
│ ├──fsimage_0000000000000000030.md5
│ ├──fsimage_0000000000000000031
│ ├──fsimage_0000000000000000031.md5
│ └── seen_txid
└── in_use.lock
in_use.lock是防止同臺主機啓動多份NameNode進程。
edits文件是增量命令操作記錄文件，類似Oracle的redo log
fsimage 文件是某個checkpoint瞬間的內存快照文件，另外對應一份md5的校驗文件
VERSION文件保存hdfs的一些版本信息和namespaceID，clusterID，blockpoolID，storageType等信息。
seen_txid 文件存儲着最新的edits_inprogress的id
DataNode數據持久化的目錄結構和文件如下：
├── current
│ ├──BP-1079595417-192.168.2.45-1412613236271
│ │ ├── current
│ │ │ ├── VERSION
│ │ │ ├── finalized
│ │ │ │ └── subdir0
│ │ │ │ └── subdir1
│ │ │ │ ├──blk_1073741825
│ │ │ │ └──blk_1073741825_1001.meta
│ │ │ │── lazyPersist
│ │ │ └── rbw
│ │ ├──dncp_block_verification.log.curr
│ │ ├──dncp_block_verification.log.prev
│ │ └── tmp
│ └── VERSION
└── in_use.lock
BP-1079595417-192.168.2.45-1412613236271 目錄名就是NameNode中VERSION保存的blockpoolID
Finalized/ rbw 存放的是真正的文件數據block文件如blk_1073741825，對應一份.meta文件，存儲blk_1073741825的checksum信息
dncp_block_verification.log 存放每個block最後修改後的checksum信息
in_use.lock 類似NameNode
3. 配置文件
核心配置文件有兩個：core-site.xml和hdfs-site.xml存放在conf目錄下
hdfs-site.xml：
dfs.namenode.http-address ：namenode的http服務端口
dfs.namenode.rpc-address.cs1.nn1：namenode 的rpc訪問端口
dfs.datanode.http.address：datanode的http服務端口
dfs.replication：默認備份數
dfs.datanode.data.dir：datanode的持久化目錄
dfs.namenode.name.dir：namenode持久化目錄
dfs.blocksize：block的最大大小
dfs.namenode.checkpoint.period：namenodecheckpoint快照（生成新的fsimage文件）的時間間隔
core-site.xml：
fs.defaultFS：active namenode的ip和端口
---由於xml 比較多，加上又沒親自進行安裝，所以對xml的配置內容大概瞭解如上
4. 進程說明
用jps察看，大概有以下六大主要進程：
（1）NameNode ：namenode服務進程
（2）DataNode：datanode 服務進程
（3）JournalNode：依賴於zookeeper，namenode的每條edit記錄都要發送給大部分的JournalNode集羣節點，以便secondary namenode從該集羣中讀取變更操作信息，保持active namenode和secondary namenode的數據一致性。要求節點數大於3並且爲奇數。
（4）DFSZKFailoverController：依賴於zookeeper,當所在節點的activenamenode進程出現錯誤時向zookeeper發送信息，secondary namenode所在節點的DFSZKFailoverController進程會讀取改信息，以便轉成新的activenamenode,和JournalNode進程一起實現hdfs的HA（高可用）功能。所以一般只在active namenode和secondary namenode主機節上啓動。
（5）NodeManager：NodeManager是運行在單個節點上的代理，它管理Hadoop集羣中單個計算節點，功能包括與ResourceManager保持通信，管理Container的生命週期、監控每個Container的資源使用(內存、CPU等）情況、追蹤節點健康狀況、管理日誌和不同應用程序用到的附屬服務等。
（6）ResourceManager：ResourceManager負責集羣中所有資源的統一管理和分配
--其實對NodeManager和ResourceManager進程的作用我也不是很理解，好像涉及到YARN概念和hadoop計算那塊。
5. 其他細節
hdfs系統自帶監控web服務功能，可以通過瀏覽器進行查看，如圖
namenode節點：
Datanode節點：
