大資料儲存之分散式檔案系統（一）
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
糾刪碼演算法的基本原理如下：
給定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中的大規模分散式檔案系統，在整個架構上與GFS大致相同，更簡化，比如同一時刻只允許一個客戶端對檔案進行追加寫操作。它具有以下幾個特點：
1）適合儲存非常大的檔案
2）適合流式資料讀取，即適合“只寫一次，讀多次”的資料處理模式
3）適合部署在廉價的機器上
但HDFS不適合以下場景（任何東西都要分兩面看，只有適合自己業務的技術才是真正的好技術）：
1）不適合儲存大量的小檔案，因為受Namenode記憶體大小限制
2）不適合實時資料讀取，高吞吐量和實時性是相悖的，HDFS選擇前者
3）不適合需要經常修改資料的場景
整體架構
由NameNode，DataNode，Secondary NameNode以及客戶端組成。 NameNode （ 負責管理整個分散式檔案系統的元資料，包括檔案目錄樹結構、檔案到資料塊的對映關係、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同時故障。