大資料存放區之Distributed File System（一）

標籤：大資料   hadoop   gfs   架構   資料   

1.Google檔案系統（GFS）
使用一堆廉價的商用電腦支撐大規模資料處理。

GFSClient： 應用程式的提供者

Master（主控伺服器）：管理節點，在邏輯上只有一個（還有一台“影子伺服器“，在主控伺服器失效時提供中繼資料，但並不是完整的熱備伺服器），儲存系統的中繼資料，負責整個檔案系統的管理。

Chunk Server（資料庫伺服器）：負責具體的儲存工作，資料以檔案的形式儲存在Chunk Server上；相應GFS用戶端的讀寫請求。

整體架構：

讀取資料的流程：

應用開發人員提交讀資料請求： 讀取檔案file，從某個位置P開始，讀出大小為L的資料。

GFS系統收到這種請求後，在內部做轉換，因為Chunk大小固定，所以從位置P和大小L可以推算出要讀的資料位元於file的第幾個chunk，即請求被轉換為<檔案file，Chunk序號>的形式。

隨後，GFS系統將這個請求發送給主控伺服器，因為主控伺服器儲存了一些管理資訊，通過主控伺服器可以知道要讀的資料在哪台Chunk伺服器上，同時把Chunk序號轉化為系統內唯一的Chunk編號，把這兩個資訊傳回到GFS用戶端。

GFS和相應的Chunk伺服器建立聯絡，發送要讀取的Chunk編號和讀取範圍，Chunk伺服器接到請求後把請求資料發送給GFS用戶端。

採用這種主從結構的優劣：

好處：管理相對簡單

壞處：很多服務要求都經過主控伺服器，容易成為整個系統的瓶頸；可能存在單點失效問題。

PS：要做資料冗餘，每個Chunk多個備份在不同的Chunk伺服器上。

寫資料的流程：GFS系統必須把這個寫操作應用到Chunk的所有備份，為了方便管理，GFS從多個相互備份的Chunk中選出一個主備份，其他的作為次級備份，由主備份決定次級備份的資料寫入順序。
GFS用戶端首先和主控伺服器通訊，獲知哪些Chunk伺服器儲存了要寫入的Chunk，包括主備份和其他的次級備份的地址資料，然後GFS用戶端將要寫入的資料推送給所有的備份Chunk，備份Chunk首先將這些待寫入的資料放在緩衝中，然後通知GFS用戶端是否接受成功，如果所有的備份都接受資料成功，GFS用戶端通知主備份可執行寫入操作，主備份將自己緩衝的資料寫入Chunk，通知次級備份按照指定順序寫入資料，次級備份寫完後回覆主備份寫入成功，主備份才會通知GFS用戶端這次寫操作成功完成。如果待寫入的資料跨Chunk或者需要多個Chunk才能容納，用戶端自動將其分解為多個寫操作。

Colossus Google下一代GFSDistributed File System，幾個改進如下：將單一主控伺服器改造為多主控伺服器構成的叢集，將所有管理資料進行資料分區後分配到不同的主控伺服器上。Chunk資料的多個備份雖然增加了系統可用性，但是付出了更多的儲存成本，一種常見的折中方案是採用糾刪碼演算法。Colossus的用戶端可以根據需求指定資料存放地點。
PS：

糾刪碼演算法的基本原理如下：  

給定n個資料區塊d1, d2,..., dn，n和一個正整數m， RS根據n個資料區塊產生m個校正塊， c1, c2,..., cm。  對於任意的n和m，  從n個未經處理資料塊和m 個校正塊中任取n塊就能解碼出未經處理資料， 即RS最多容忍m個資料區塊或者校正塊同時丟失（糾刪碼只能容忍資料丟失，無法容忍資料篡改，糾刪碼正是得名與此）。 

關於糾刪碼的更多細節可以參考：http://blog.sina.com.cn/s/blog_3fe961ae0102vpxu.html

關於資料可靠性：對冷資料進行編碼冗餘，對熱資料進行副本冗餘。（前者減少儲存成本，後者減少計算成本，應該很好理解）

2.HDFS
是Hadoop中的大規模Distributed File System，在整個架構上與GFS大致相同，更簡化，比如同一時刻只允許一個用戶端對檔案進行追加寫操作。

它具有以下幾個特點：

1）適合儲存非常大的檔案

2）適合流式資料讀取，即適合“唯寫一次，讀多次”的資料處理模式

3）適合部署在廉價的機器上

但HDFS不適合以下情境（任何東西都要分兩面看，只有適合自己業務的技術才是真正的好技術）：

1）不適合儲存大量的小檔案，因為受Namenode記憶體大小限制

2）不適合即時資料讀取，高輸送量和即時性是相悖的，HDFS選擇前者

3）不適合需要經常修改資料的情境

整體架構

由NameNode，DataNode，Secondary NameNode以及用戶端組成。
NameNode（負責管理整個Distributed File System的中繼資料，包括檔案分類樹結構、檔案到資料區塊的映射關係、Block副本及其儲存位置等各種管理資料。這些資料儲存在記憶體中。還負責DataNode的狀態監控，通過心跳來傳遞管理資訊和資料資訊。
Secondary NameNode

職責並非是NameNode的熱備機，而是定期從NameNode拉取fsimage（記憶體命名空間中繼資料在外存的鏡像檔案））和editlog檔案（各種中繼資料操作的write-ahead-log檔案，在體現到記憶體資料變化前先把操作記錄到此檔案防止資料丟失)並對這兩個檔案進行合并，形成新的fsimage檔案並傳回給NameNode，以減輕NameNode的工作壓力。
DataNode
類似於GFS的Chunk伺服器，負責資料區塊的實際儲存和讀寫。
用戶端
與GFS用戶端類似，HDFS用戶端和NameNode聯絡擷取所需讀/寫檔案的中繼資料，實際的資料讀寫都是和DataNode直接通訊完成的。
HA方案主控伺服器由Active NameNode和Standby NameNode一主一從兩台伺服器構成，ANN是當前響應用戶端請求的伺服器，SNN是冷備份或者熱備份機。為了使SNN成為熱備份機，SNN的所有中繼資料需要與ANN中繼資料保持一致。通過以下兩點來保證這一要求：1.使用第三方共用儲存來儲存目錄檔案等命名空間中繼資料。本質是把NN的單點失效問題轉換成第三方儲存的單點失效問題，但是第三方儲存內建很強的冗餘和容錯機制，所以可靠性較強。2.所有DataNode同時把心跳資訊發送給ANN和SNN。
加入獨立於NN之外的故障切換控制器，在ANN故障時，選舉SNN為主控伺服器。在Hadoop系統剛剛啟動時，兩台都是SNN，通過選舉使得某台成為ANN。由此要加入隔離措施防止腦裂現象（即同時有多個活躍的主控伺服器）：1）同一時刻上只有一個NN能夠寫入第三方共用儲存
2）只有一個NN發出與管理資料副本有關的刪除命令3）同一時刻是有一個NN能夠對用戶端請求發出正確相應
解決方案：
QJM：利用Paxos協議，在2F+1GE JournalNode中儲存NN的editlog，每次寫入操作如果有F台伺服器返回成功即可認為成功寫入。最多可以容忍F個Journal Node同時故障。
NameNode聯盟核心思想：把一個大的命名空間切割為若干子命名空間，每個子命名空間由單獨的NN負責管理，NN之間獨立，所有DataNode被共用。DataNode和子命名空間之間由資料區塊管理層建立映射關係，資料區塊管理層由若干資料區塊池構成。每個資料區塊唯一屬於某個固定的資料區塊池，一個子命名空間可以對應多個資料區塊池。
ps：HDFS看的雲裡霧裡，以後研究Hadoop的時候再好好回顧吧。

著作權聲明：本文為博主原創文章，未經博主允許不得轉載。

大資料存放區之Distributed File System（一）