【Hadoop系列】HDFS

Hadoop的前世此生

什麼是大數據

各行各業都會產生大量的數據，好比社交網站的意見觀點，電商平臺人們瀏覽網頁停留的時間，交通運輸天天產生的數據等等。這些數據大多不是結構化的，通常來講都是半結構化或者非結構化的

在之前，咱們的處理能力達不到，因此不少數據要麼沒有存起來，要麼沒有利用起來。而如今數據愈來愈集中在雲端的服務器上，而且計算能力已經今非昔比了，咱們徹底有能力對大數據進行存儲和分析。

因此所謂的大數據指的就是，原有的計算能力沒法處理的大批量的數據，而大數據技術研究的是如何快速有效的處理這些結構化、半結構化數據的技術。

處理大數據的架構

下圖是傳統的集中式架構

它的主要問題在於擴展性不強並且數據庫將成爲很大的瓶頸。

因此谷歌提出了

• MapReduce算法

• BigTable

• GFS

合稱「三劍客」。

那麼相對於傳統的架構，有什麼樣的變化呢？

• 首先它可使用大量的x86服務器，而不是使用性能強健的大型機來完成計算，也就是Scale-out的

• 另外它使用軟件方案來保證硬件故障容錯

  咱們知道x86服務器的穩定性不如小型機，存在必定的故障的可能，可是小型機實在太貴了。咱們徹底可讓x86服務器組成集羣，而後使用上層軟件來保障總體的硬件故障容錯。

• 簡化並行分佈式計算，不須要再控制節點的同步和數據的交換。

Hadoop模仿Google的實現方式，最終演變成一系列的開源項目。

總結一下：

大數據既是一個概念又是一門技術，它是以Hadoop和Spark爲表明的大數據基礎框架，能夠實現數據分析、挖掘、預測。

Hadoop

上面說到Hadoop是一種分佈式計算解決方案，含有若干組件，其中最著名的當屬

• HDFS分佈式文件系統：存儲海量數據

  存儲技術是大數據的基礎，由於對於大量的數據，咱們但願能找的一種比較廉價的方式來保存咱們的數據，那麼分佈式文件系統當屬首選。

• MapReduce編程模型：

  並行處理框架，實現任務分解和調度

因此Hadoop的優點在於：

• 高擴展性，也就是能夠經過增長節點來活動性能提高，好比說性能不夠了，就懟新的服務器上去。

• 低成本，能夠基於便宜的x86服務器

• 成熟的生態圈，裏面有大量的工具集可使用

下面分別介紹一下HDFS和MapReduce

HDFS

在【大話存儲II】學習筆記（15章），文件級集羣系統中咱們介紹了分佈式集羣的基本概念。

分佈式文件系統能夠等價於非共享存儲集羣文件系統，也就是說同一個文件系統下的文件是存放在不一樣的節點裏面，並且Sharing-nothing

那麼分佈式文件系統應該解決

• 統一的命名空間，也就是對外顯現同一個文件目錄。

  這樣用戶不用管數據是如何存放的，分佈式文件系統已經幫它解決存放的問題了，用戶用起來就像使用本地文件同樣簡單。

• 緩存一致，由於數據都緩存在各自的節點，不存在不緩存不一致的狀況。

• 分佈式鎖，也就是多個鏈接併發訪問的時候，如何控制文件的數據會出現不一致的狀況。

若要理解HDFS，咱們須要知道以下的基本概念。

基本概念

分佈式設計

HDFS這樣的架構，很是相似於【大話存儲II】學習筆記（15章），塊級集羣存儲系統中的XIV，固然XIV是提供塊存儲的，不過XIV也利用了文件系統的思想，對每一個塊像一個文件同樣。

HDFS的基本存儲和操做單位是數據塊， 默認大小64MB，通常設置爲128M。爲何要這麼設計呢？由於一個文件會比較大，爲了分佈式存放，能夠分紅若干小塊。那麼最好就切成相同大小，好比說64MB。

並且爲了保證數據塊不丟失，對每一個數據塊會保存3副本，分佈在兩個機架的三個節點中。 其中兩份在同一個機架，一份在另外一個機架。

好比下圖中兩個A數據塊放在機架1，另外一份副本放到了機架2 。

角色

在【大話存儲II】學習筆記（15章），文件級集羣系統咱們介紹過，分佈式文件系統有對稱和非對稱的兩種。

對稱集羣中全部節點的地位相同，互相維護通訊連接進行數據同步，也正由於如此，不適合擴展。

而HDFS採用的是非對稱集羣，因此有Master和Slave兩種角色。

Master就是HDFS中的NameNode，它的做用是 存放元數據，管理文件系統的命名空間。也就是一個註冊中心，其餘的Slave都要到它這邊註冊。

Master和Slave組成集羣之後，能夠自服務，也能夠對外提供服務。

它會記錄兩種信息：

• 文件與數據塊的映射關係

• 數據塊與服務器的對應關係，也就是每一個塊存放的節點的信息

Slave則是DataNode，它的主要做用就是存放數據塊，是具體的執行者。

當塊存儲信息改變了之後，DataNode會向NameNode主動更新信息

另外，在這種主從架構裏面，NameNode的地位很超然，很是的重要，一旦他掛了則整個系統就宕了。

因此從HDFS 2x就能夠爲NameNode配置HA了。

以下圖所示，出現了一個Secondary NameNode。

二級NameNode按期同步元數據鏡像文件和修改日誌，當NameNode發生故障時，備胎轉正。

HDFS的讀與寫

寫

下面咱們來看一下寫流程。

• 客戶端向NameNode發出請求，表示本身要發送文件了，而後NameNode會返回如今空餘存儲的信息

• 而後客戶端將文件分塊，

• 接着，客戶端將數據塊1以及相應的元數據信息發給DataNode1

• 而後開啓流水線複製，將數據同步給另外的節點

• 寫完了之後，DataNode才返回更新信息，最後NameNode向客戶端返回成功。

讀文件

下圖展現了HDFS的讀流程

• 首先客戶端向NameNode發起讀請求，將路徑+文件名發過去

• NameNode返回元數據，告訴客戶端能夠從哪些地方取

• 而後由客戶端本身向DataNode讀取數據

HDFS的特色

瞭解了HDFS的架構以及讀寫流程之後，咱們能夠總結一下HDFS的特色。

本質上HDFS就是一個分佈式文件系統，它

• 經過三副本機制進行冗餘，相似於的分佈式的RAID10

• 它的寫比較的複雜，須要複製2份，還要同步各類信息，並且修改也比較麻煩，只能刪除之後再寫。因此比較適合於一次寫入，屢次讀取的場景，如今的OLAP就比較契合

• 由於每次寫或者讀都須要向NameNode發起請求，因此NameNode是整個系統的瓶頸，因此若是是小文件的話，NameNode壓力很是大。

也就是說HDFS適合於批量讀，這樣吞吐量高，由於能夠併發讀嘛。

可是不支持多用戶寫相同的文件，由於沒有加鎖。

也就是不適合交互應用以及那些實時性要求高的地方。