經袁哥建議以及自身對大數據將的理解，本月的學習側重點放在Hadoop兩大核心之一—HDFS分佈式存儲上。經過之前對HDFS的初步瞭解和今天一天的學習內容的整理，向您展示今天的學習成果，即對HDFS的原理、歷史、以及優缺點和改進的學習和理解。
對於HDFS的學習，我的學習路線是：爲什麼需要分佈式存儲HDFS、HDFS它解決了什麼樣的問題或場景、HDFS的讀寫原理。
- 爲什麼需要分佈式存儲HDFS、HDFS它解決什麼問題
不知道哪位牛叉的人說過“需求是技術之母”，所以HDFS的出現也是這樣，我理解到HDFS作爲文件系統與傳統的文件系統相比，解決了很多傳統文件系統在應用上很多痛點，文件系統即：文件管理軟件、文件、存儲文件的結構。寫到這裏，突然感覺，要寫HDFS之前的的歷史太多了。。。首先，HDFS並不是分佈式存儲大家庭的先祖，而是繼谷歌推出三大文章，其中DFS的克隆且開源版。我還瞭解到，HDFS時Hadoop的默認存儲方式，爲什麼是默認，因爲Hadoop下還有其他的文件存儲系統，比如：亞馬孫的一個文件系統（什麼名字忘記了）。其次，從分佈式存儲的歷史角度來看，傳統的單機磁盤存儲，並不能滿足日益增長的數據量以及支撐龐大的文件。打個比方，在90年的時候，當時一個磁盤1G左右，讀盤能力大概在4.5/s左右，可見讀寫的整盤要5min中，後面到11年磁盤發展到1T了，讀的能力都在100m/s,但是需要100min時間，可想而知，現如今數據量都能達到PB的現在，且不說存儲海量數據的磁盤造價，就讀取時間這塊，不知要花費多長的時間。
所以，HDFS的到來，恰是解決了上述痛點。當然，HDFS的牛逼地方不僅僅如此。
以下我想節選和引入Hadoop官方文檔中一些假設和前提來引入HDFS概念（由於內容太多，我只列出一些我理解的部分）：
硬件錯誤
硬件錯誤是常態而不是異常。意思就說，HDFS可能由成百上千的服務器所構成，每個服務器上存儲着文件系統的部分數據。我們面對的現實是構成系統的組件數目是巨大的，而且任一組件都有可能失效，這意味着總是有一部分HDFS的組件是不工作的。因此錯誤檢測和快速、自動恢復是HDFS最核心的架構目標。
流式數據訪問
運行在HDFS上的應用和普通的應用不同，需要流式訪問它們的數據集。HDFS的設計中更多的考慮到了數據批處理，而不是用戶交互處理。比之數據訪問的低延遲問題，更關鍵的在於數據訪問的高吞吐量。
簡單的一致性模型
HDFS應用需要一個“一次寫入多次讀取”的文件訪問模型。一個文件經過創建、寫入和關閉之後就不需要改變。這一假設簡化了數據一致性問題，並且使高吞吐量的數據訪問成爲可能。Map/Reduce應用或者網絡爬蟲應用都非常適合這個模型。目前還有計劃在將來擴充這個模型，使之支持文件的附加寫操作。
“移動計算比移動數據更划算”。一個應用請求的計算，離它操作的數據越近就越高效，在數據達到海量級別的時候更是如此。因爲這樣就能降低網絡阻塞的影響，提高系統數據的吞吐量。將計算移動到數據附近，比之將數據移動到應用所在顯然更好。HDFS爲應用提供了將它們自己移動到數據附近的接口。
以上四點，我覺得今天當我把它們看完，並努力的消化過程中，我好像對HDFS概念豁然瞭解很多。。。這四種假設和前提不就是HDFS的強大之處麼。首先是硬件錯誤，想像下，原本的存儲海量的昂貴的單機磁盤萬一壞了，是不是很麻煩服務也會終止，但是HDFS分佈式存儲方案即是將文件切成默認的64M的數據塊block,(至於爲什麼是64M,其實是很有學問的，，由於字數問題我就不展開了)放在很多存儲節點上，對分佈式硬盤的要求很低，壞了就更換多簡單。還有當業務拓展時，只需購買些低廉的磁盤就行了。HDFS還用冗餘（複製集）的方式，做好更換備份工作。其次就是流式訪問，這裏感覺不是很懂，可能受前面學習的流處理和實時處理框架的概念影響。。。HDFS的缺點就不是做不了低延遲的麼，怎麼還支持流式訪問，這一點可能找時間向哥爲我解答下。後面的簡單一致性很好理解，就是“一次寫入，多次讀取”設計理念讓HDFS的一致性很好維護。但這也恰恰是HDFS的不足吧。最後是“移動計算比移動數據更划算”。這一塊，我想結合MapReduce去理解可能會更好些。
- HDFS的讀寫原理
先放一張給官方的圖，HDFS的分佈式存儲原理，其實是主從架構（master/slave）主：Namenode，從：Datanoda。
首先講下Namenode，Namenode我理解扮演爲個管理者，存儲着元數據，元數據其實就是數據的數據，比如說，name，replicas以及文件和block的映射表。當客戶端做讀取時候先向Namenode尋址，然後拿到文件的數據塊地址，直接到對應的Datanode節點去找，拿到之後再做拼接。這裏有個很重要的地方就是，集羣中只有一個Namenode（存儲的簡化高效設計）當Namenode壞了呢，整個系統都無法提供服務，所以HDFS有兩個避免這種情況的方法：
1、備份所有的元數據信息。我們可以配置HDFS同時向多個文件系統寫這些元數據信息，這個寫是同步。用的配置策略是本地寫一份。
2、另外就是運行一個Secondary NameNode。它的作用其實是週期性的將namespace image和edit log合併，產生新的image，防止edit log變的非常大。同時會保留一份合併後的image文件。這樣當Namenode掛掉後，我們可以從這個保留的image文件進行恢復。但SecondaryNameNode的操作較Namenode還是有一定延遲的，所以這種方式還是會丟一些數據。（上面的namespace image和edit log我理解就是元數據壓縮一種方式）。
很明顯，上面的兩種都有很大的缺陷，好像現在Hadoop版本據我所知是採用類似於“雙機熱備”概念去解決。備用並一直運行另一個NameNode節點，共享兩個元數據信息。
其次，說下Datanode,它是作爲HDFS真正數據存儲的地方。存放各種文件切出的數據塊。也是直接與客戶端去做數據交換。還要定期的將本地block列表發送到Namenode。
今天學習的資料如下：《HDFS入門介紹》、 《HDFS簡單入門》、《HDFS原理技術》、《Hadoop權威指南》，，，還有很多微信公衆號，和百度CSDN搜索的零散知識點。
寫到這裏，關於HDFS在腦海中感覺冒出來的東西很多，實在無法一一列舉我的學習成果。希望袁哥可以理解，之後的學習整理，我儘量的做到整理條理清晰。消化消化再消化。
明天學習計劃
Hadoop的另一大核心分佈式計算：MapReduce