【云駐共創】小白速看之HDFS分布式文件系統和ZooKeeper

前言

本章主要講解大數據分布式存儲系統HDFS和解決分布式應用中經常遇到的一些數據管理問題的Zookeeper分布式服務框架。通過本章的學習，為后續組件學習打好基礎。

大數據平臺主要提供的是存儲和計算能力。大數據的存儲主要是由HDFS、HBase以及Hive等等組件來提供的，大數據平臺的計算能力主要是由mapreduce、spark、Flink等等組件去提供的。其中大數據平臺的計算場景的主要有批處理計算場景、流處理計算場景、實時響應查詢的計算場景以及圖計算場景。

zookeeper是大數據平臺分布式一致性協調了服務組件，它為HDFS提供一種高可靠性的支撐服務。因此我們這一章把HDFS和zookeeper放在一起來進行講解。

一、HDFS概述及應用場景

首先我們理解一下文件系統的含義。為了方便大家理解，我們把新華字典與文件系統進行了類比，其中新華字典中有目錄、檢字表，還有難檢字的索引，對應的就是文件系統的文件名以及元數據(Metadata)。新華字典的字典正文就是對于文件系統的數據塊，文件系統它主要是為了方便文件的查找以及管理，接下來我們對HDFS進行概述。

Hadoop分布式文件系統（ HDFS)是一種旨在在商品硬件上運行的分布式文件系統。商品硬件就是我們一般所說的商用服務器。商用服務器相對于以前的小型機，它的價格更加低廉。

HDFS具有高度的容錯能力，旨在部署在低成本硬件上。

HDFS提供對應用程序數據的高吞吐量訪問，并且適用于具有大數據集的應用程序

HDFS放寬了一些POSIX要求，以實現對文件系統數據的流式訪問。

HDFS最初是作為Apache Nutch Web搜索引擎項目的基礎結構而構建的。

HDFS是Apache Hadoop Core項目的一部分。

HDFS和MapReduce是Hadoop最早的兩個組件。

HDFS主要是用來存儲網站數據，還有交通電子眼的數據，還有氣象數據、傳感器采集的數據。HDFS也不是萬能的，有一些場景它并不適合，比如說需要實時響應的一些應用場景，HDFS就不太適合。HDFS并不適合存儲大量的小文件，因為每一個文件的元數據大概是150kb，如果說一百萬個小文件大概有300M。那么如果說一個小文件，它的元數據是非常巨大的，HDFS只采用單個節點來存儲元數據，因此HDFS不適用于存儲大量的小數據。HDFS也不適用于多用戶寫的場景以及隨機寫的場景，因為HDFS的數據是追加到文件的末尾，不支持在文件的任何一個地方進行寫入。

二、HDFS相關概念

集群的結構，集群就是一些計算機我們通過網絡連接起來就形成了一個集群。分布式文件系統的把文件分布式存儲在了這樣一個多節點的網絡中，成千上萬的計算機節點構成計算機集群。分布式文件系統所采用的計算機集群都是用普通的硬件所構成的，大大的降低了硬件上的開銷。

HDFS的基本的系統架構我們從這個圖中可以看到，它主要包括客戶端、NameNode和DataNode。對于客戶端，它主要包含了HDFS的一些接口，它用來訪問HDFS上的文件。對于NameNode，它存儲的是文件名以及元數據，還有就是文件與數據塊的對應關系。對于DataNode，它是用來存儲數據的節點。我們在HDFS的系統中可以有多個client、多個data node，但是對于提供服務，name node只能有一個。接下來我們介紹HDFS文件的基本存儲單位block塊，一個文件可以分成很多塊，默認的一個塊的大小是128M，我們以塊為存儲單位，大數據HDFS文件系統的塊的大小遠遠大于普通的文件系統，可以起到最小化尋址開銷的作用，提高了讀取的吞吐量。

HDFS默認—個塊128MB，一個文件被分成多個塊，以塊作為存儲單位。塊的大小遠遠大于普通文件系統，可以最小化尋址開銷。

抽象的塊概念可以帶來以下幾個明顯的好處:

支持大規模文件存儲

簡化系統設計

適合數據備份

采用塊的概念可以帶來以下幾個方面的好處。第一個方面是支持大規模文件的存儲。我們一個文件也分為了若干個數據塊，那這些塊又可以分散存儲在若干個節點上，因此我們存儲文件的大小不受限于單個節點的存儲容量。第二個方面是它可以簡化系統的設計。因為我們一個塊的大小是固定的，很容易去計算出來一個節點到底可以存儲了多少個塊。其次我們可以很方便地計算出了文件的大小，適合數據的備份，因為我們的文件可以劃分成若干個數據塊，這些塊可以分散的存儲在多個節點上。并且可以進行冗余存儲。采用冗余存儲的方式，當發生了部分數據丟失了，我們很容易進行恢復。

接下來我們介紹HDFS的兩個主要的組件，namenode和datanode。namenode負責了管理namespace，包含兩個最重要的數據結構，fsimage和EditLog。fsimage維護了文件系統數以及文件數中的文件以及文件名的元數據。另外EditLog記錄了所有針對于文件的修改、刪除以及重命名一些操作。namenode記錄了數據塊與datanode的對應關系。datanode它主要負責了文件的存儲和讀取，并且datanode會根據namenode和客戶端的調度對文件進行檢索或者是存儲。另外namenode將自己的數據塊存儲于Linux操作系統的文件系統中。

三、HDFS體系架構

hdfs包含名稱節點、數據節點，在hdfs的分布式文件系統中，名稱節點只有一個，數據節點可以有多個。除此之外還有客戶端，客戶端包含了hdfs的一些api，我們利用客戶端可以去給名稱節點發送文件名或者是數據塊號查詢他想去查詢的數據塊，名稱節點中它記錄了數據塊存儲在哪些數據節點之上，然后就通知相應的數據節點，讓客戶端從數據節點上讀取數據，也就是讀取這些數據。這就是個HDFS體系結構。

HDFS命名空間管理

接下來我們看看HDFS命名空間管理。HDFS的命名空間它包含目錄、文件和塊。HDFS使用的是傳統的分析文件體系，我們以前的方式是直接用斜杠，我們就可以來訪問到相應的文件。用戶可以像使用普通文件系統一樣可以很方便的對文件進行創建、刪除以及重命名文件。HDFS采用name node維護文件系統的名稱，對文件系統的名稱空間、過期屬性的任何更改都有namenode的記錄。有兩種的數據結構，一個fsimage，一個是EditLog，主要是用來記錄客戶端對原文件的修改。

接下來我們介紹HDFS通訊協議，HDFS通信協議主要都是基于tcp/ip協議的。客戶端通過一個可配置的端口向名稱節點主動發起TCP連接，并使用客戶端協議與名稱節點進行交互。名稱節點和數據節點之間則使用數據節點協議進行交互，客戶端與數據節點的交互是通過RPC ( Remote Procedure Call)來實現的。在設計上，名稱節點不會主動發起RPc，而是響應來自客戶端和數據節點的RPC請求。

現在我們看看客戶端，客戶端是用戶操作HDFS最常用的方式，HDFS在部署時都提供了客戶端；HDFS客戶端是一個庫，包含HDFS文件系統接口，這些接口隱藏了HDFS實現中的復雜性；嚴格來說，客戶端并不算是HDFS的一部分；客戶端可以支持打開、讀取、寫入等常見的操作，并且提供了類似Shell的命令行訪問HDFS中的數據；HDFS也提供了Java APl，作為應用程序訪問文件系統的客戶端編程接口。因為HDFS它是用架構開發的，JAVA api是它的原生api，我們采用JAVA API去寫的程序就會有很高的效率。

在HDFS 1.0中，它是采用了單名稱節點的，HDFS只設置唯—一個名稱節點，這樣做雖然大大簡化了系統設計，但也帶來了一些明顯的局限性，具體如下:

命名空間的限制:名稱節點是保存在內存中的，因此，名稱節點能夠容納的對象（文件、塊)的個數會受到內存空間大小的限制。

性能的瓶頸:整個分布式文件系統的吞吐量，受限于單個名稱節點的吞吐量。

隔離問題:由于集群中只有一個名稱節點，只有一個命名空間，因此，無法對不同應用程序進行隔離。

集群的可用性:一旦這個唯一的名稱節點發生故障，會導致整個集群變得不可用。

四、關鍵特性介紹

首先我們來看HDFS的高可用性。高可用性它的縮寫是HA(Highly Available)。高可用性是Hadoop2.0發展出來了一個新特性，因為對于Hadoop1.0來說，它只有一個名稱節點，如果這個名稱節點一旦崩潰了，整個集群將處于不可用。我們說HDFS1.0即使一個名稱節點不可用之后，我們可以采用手工的方式，把集群先停下，然后把相應的備份文件，比如說fsimage和EditLog拷貝到namenode上，我們重新啟動，但是它會停用一段時間。在2.0中，我們對這個問題進行了改進。設計了兩個名稱節點，一個稱為了active NameNode，一個稱為stand NameNode。一般我們稱active NameNode它是主節點，stand NameNode稱為二備份節點。通常情況下在集群運行的某個時刻，只有一個主節點提供服務。這個備用節點它是用來備份元數據信息的。我們為了去保證在集群中始終有一個提供服務的主名稱節點。因此我們需要采用Zookeeper監控名稱節點的心跳。當發現這個主名稱節點崩潰的時候呢，就會來起用這個備用名稱節點。備用名稱這里它需要去存儲相應的原數據信息。

那么這個元數據信息是怎么去存儲的呢？涉及到兩個層次，第一個層次是需要對Editlog，對元數據的一些更新操作信息，它需要去存儲，它采用的是共享存儲機制。同時在內存中維護了數據塊與文件之間的對應關系，它記錄了哪些數據塊在哪些在datanode里面。因此我們在集群運行的期間，datanode需要不斷地通過心跳把自身的數據塊、數據信息發送給兩個namenode，兩個namenode都需要實時的去維護，文件跟數據塊以及數據塊在哪個data node之間的一個對應關系。

NameNode 基于內存存儲文件元數據、目錄結構、文件 block 的映射等信息，為了保障其可靠性，需要對其進行持久化。日志文件的方式 和 內存 Dump 都有其相應的優勢與劣勢，因此 HDFS 也使用了混合的方式。HDFS 同樣也同時使用了這兩種方式，其 日志記錄?方式被稱為 EditsLog，其內存 Dump 方式被稱為 FsImage。因為 EditsLog 和 FsImage 也存在 日志記錄 和 內存 Dump 的固有的缺點，因此兩種方式都使用，來彌補對方的缺點。

由于滾動更新 FsImage 文件，也是比較耗時耗力的原因，HDFS 給 NameNode 提供了一個秘書，即 Secondary NameNode。Secondary NameNode 并非是第二個 NameNode，因為它不存儲元數據，它的作用是完成 FsImage 和 EditsLog 的合并。通常 Secondary NameNode 和 NameNode 不在同一主機。Secondary NameNode 通過 http get 方式獲取 NameNode 主機上的 FsImage 和 EditsLog，合并后通過 http post 方式提交給 NameNode，從而生成新的 FsImage 文件。

當 Secondary NameNode 將 EditsLog 拉取以后，NameNode 會將將新的日志記錄到新的 EditsLog 中。

HDFS?聯邦架構主要用于構建數據湖中的大型Hadoop集群，該集群具有以下特點：

1、文件數量非常多：數據湖中文件數達到數億甚至更多。

2、單一集群規模大：數據湖的Hadoop集群規模達到數百臺甚至更多。

3、各業務場景需要隔離：數據湖多種業務場景共同部署在一個物理集群，各業務之間要求互不影響。

聯邦架構與單組Namenode架構相比，主要是Namespace被拆分成了多個獨立的部分，分別由獨立的Namenode進行管理。為了水平擴展Namenode，HDFS聯邦架構使用了多個獨立的Namenode/Namespace。這些Namenode之間是聯合的，也就是說，他們之間相互獨立且不需要互相協調，各自分工，管理自己的區域。分布式的Datanode被用作通用的數據塊存儲設備。每個Datanode要向集群中所有的Namenode注冊，且周期性地向所有Namenode發送心跳和塊報告，并執行來自所有Namenode的命令。

數據副本機制在haddoop1.0的時候就一直存在，數據副本是分布式系統解決數據丟失異常的唯一手段。另一類副本是服務副本，數個節點提供相同的服務，這種服務一般并不依賴節點的本地存儲，其所需數據一般來自其他存儲節點。

假如說我們的客戶端提交了要存儲一個數據塊，那么這個數據塊它是怎么存放的啊？如果說客戶端在某個機架上的某個機器的服務器上，這時候它就會在所相應的這個服務器節點上去存儲一個數據塊block。如果說我們這個客戶端不在這個機架上，在集群的外部，那我們就會在某個資源最豐富(存儲資源)機架尋找一個節點，把相應的數據塊存到這個節點上。然后它的第二個塊是怎么樣去存儲的？他會來找其他的一個機架的很多個服務器，就會相應的在上面去找一個數據節點，然后把數據塊傳出來這個數據節點上。對于第三個副本我們一般情況下就會找到跟第一個副本所在的同一個機架，然后把第三個副本放到另外一個block上。如果說還有多的副本，因為我們這個副本是可以去設置的，我們通常情況下對偽分布式的模式只有一個副本。對于這種真實的集群環境下，我們可以設兩個、三個、四個，當然也不是越多越好。根據實際情況，我們一般默認是三個副本，如果說有多余三個副本，他就會來去隨機的去可以算出一個值，然后讓你存隨機存儲到某一個節點上。

HDFS數據完整性保障

HDFS主要目的是保證存儲數據完整性，對于各組件的失效，做了可靠性處理。重建失效數據盤的副本數據

DataNode向NameNode周期上報失敗時，NameNode發起副本重建動作以恢復丟失副本。集群數據均衡

HDFS架構設計了數據均衡機制，此機制保證數據在各個DataNode上分布是平均的。

元數據可靠性保證

采用日志機制操作元數據，同時元數據存放在主備NameNode上。

快照機制實現了文件系統常見的快照機制，保證數據誤操作時，能及時恢復。

安全模式

HDFS提供獨有安全模式機制，在數據節點故障，硬盤故障時，能防止故障擴散。

HDFS架構其他關鍵設計要點說明

空間回收機制:

支持回收站機制，以及副本數的動態設置機制。

數據組織:

數據存儲以數據塊為單位,存儲在操作系統的HDFS文件系統上。

訪問方式:

提供JAVA API，HTTP方式，SHELL方式訪問HDFS數據。

例如：hdfs dfs -cat /emp/words/

HDFS3.0 HDFS新特性總結

支持HDFS中的糾刪碼Erasure Encoding

基于HDFS路由器的聯合

支持多個NameNode

DataNode內部添加了負載均衡Disk Balancer

在HDFS中，把連續的數據分成很多的小部分稱為條帶化單元，對于原始數據單元的每個條帶單元，都會計算并存儲一定數量的奇偶檢驗單元，計算的過程稱為編碼，可以通過基于剩余數據和奇偶校驗單元的解碼計算來恢復任何條帶化單元上的錯誤。

五、HDFS的數據讀寫流程

HDFS數據讀寫流程：

首先我們看hdfs文件系統是怎么樣去寫入數據的。首先HDFS客戶端，提出創建文件這個請求，我們通常要用到HDFS它提供的一個叫Distributed FileSystem類，我們可以認為呢\是接口，然后把這個創建文件這樣一個請求發送給namenode接收到這個請求之后是吧解釋這個請求之后，然后就反饋給客戶端，客戶端這時候緊接著就寫入數據，寫入數據它依據的是FSData OutputStream這個接口。它前面通過namenode獲取到在哪些datanode上可以去寫入數據塊。寫入的時候，首先找到第一個DataNode寫入第一個副本，這個數據副本只需要寫入到大概百分之四十左右的時候，那么他就回來把這個寫入操作，相應的傳遞給另外一個DateNode，這個類似于流水線操作，然后傳給這個DataNode。對DataNode同樣寫到百分之四十左右的時候，就把寫入第三個副本的信息發送給了另外一個datanode同樣進行寫。那么當寫完之后，就回來反饋，反饋這個已經正確的數據包。再反饋回去給客戶端，客戶端這時候就會關閉文件來寫操作，最后這個寫操作完成。

首先我們發送一個打開文件的請求，接下來我們要從上去獲取打開文件Distributed FileSystem的元數據信息，就是說需要在DataNode上去獲取它所需要的這個block。好，再就是讀取請求是通過FSData IuputStream進行封裝，緊接著就會找到相應的來DataNode去讀取它所需要的block，block最后關閉樞紐，關閉了文件系統。

六、ZooKeeper概述與體系架構

Zookeeper稱為動物園管理員，ZooKeeper 分布式服務框架主要是用來解決分布式應用中經常遇到的一些數據管理問題提供分布式、高可用性的協調服務能力。安全模式下ZooKeeper依賴于Kerberos和LdapServer進行安全認證，非安全模式則不依賴于Kerberos與LdapServer。ZooKeeper作為底層組件廣泛被上層組件使用并依賴，如Kafka，HDFS，HBase，Storm等。

Zookeeper維護一個類似文件系統的樹狀數據結構，這種特性使得?Zookeeper?不能用于存放大量的數據，每個節點的存放數據上限為1M。每個子目錄項如 NameService 都被稱作為?znode(目錄節點)。

Zookeeper服務架構 --模型

ZooKeeper集群由一組Server節點組成，這一組Server節點中只存在一個Leader的節點，其他節點都為Follower。

啟動時選舉出leader。

ZooKeeper使用自定義的原子消息協議，保證了整個系統中的節點數據的一致性。Leader節點在接收到數據變更請求后，先寫磁盤再寫內存。

Zookeeper服務架構 --容災能力

ZooKeeper能夠完成選舉即能夠正常對外提供服務。ZooKeeper選舉時，當某一個實例獲得了半數以上的票數時，則變為leader。

對于n個實例的服務，n可能為奇數或偶數。

n為奇數時，假定n= 2x +1，則成為leader的節占少種得x+1票，容災能力為x。

n為偶數時，假定n= 2x +2，則成為leader的節點需要獲得x+2票(大于一半)，容災能力為x。

ZooKeeper關鍵特性

最終一致性:無論哪個server，對外展示的均是同一個視圖。

實時性:保證客戶端將在一個時間間隔范圍內獲得服務器的更新信息，或者服務器失效的信息。

可靠性:一條消息被一個server接收，它將被所有server接受。

等待無關性:慢的或者失效的client不會干預快速的client的請求，使得每個client都能有效的等待。

原子性:更新只能成功或者失敗，沒有中間狀態。

順序一致性:客戶端所發送的更新會按照它們被發送的順序進行應用。

ZooKeeper讀特性

由ZooKeeper的一致性可知，客戶端無論連接哪個server，獲取的均是同一個視圖。所以，讀操作可以在客戶端與任意節點間完成。

ZooKeeper客戶端常用命令使用

調用ZooKeeper客戶端，執行命令:zkCli.sh -server 172.16.0.1:24002

創建節點: create /node

列出節點子節點:ls /node

創建節點數據: set /node data

獲取節點數據: get /node

刪除節點:delete /node

刪除節點及所有子節點: deleteall /node

總結

分布式文件系統是大數據時代解決大規模數據存儲問題的有效解決方案，HDFS開源實現了GFS，可以利用由廉價硬件構成的計算機集群實現海量數據的分布式存儲。

HDFS具有兼容廉價的硬件設備、流數據讀寫、大數據集、簡單的文件模型、強大的跨平臺兼容性等特點。但是,也要注意到，HDFS也有自身的局限性，比如不適合低延遲數據訪問、無法高效存儲大量小文件和不支持多用戶寫入及任意修改文件等。

塊是HDFS核心的概念，一個大的文件會被拆分成很多個塊。HDFS采用抽象的塊概念，具有支持大規模文件存儲、簡化系統設計、適合數據備份等優點。

ZooKeeper分布式服務框架主要是用來解決分布式應用中經常遇到的一些數據管理問題，提供分布式、高可用性的協調服務能力。

本文整理自華為云社區【內容共創系列】活動。

查看活動詳情：https://bbs.huaweicloud.com/blogs/314887

相關任務詳情：HDFS分布式文件系統和ZooKeeper

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。