前言：Google大數據處理的3篇核心論文
《The Google File System》：http://research.google.com/archive/gfs.html
《MapReduce: Simplified Data Processing on Large Clusters 》：http://research.google.com/archive/mapreduce.html
《Bigtable: A Distributed Storage System for Structured Data》：http://research.google.com/archive/bigtable.html
GFS（Google文件系統）作爲一個分佈式文件系統，爲Google提供基礎的海量數據存儲服務。雖然GFS並沒有開源，但Google在其04年發表的論文《The Google File System》裏面做了詳細的介紹，很多設計思路都很有學習的價值。由於論文很長，這裏對這篇論文做個學習筆記，總結一下。
-----------------------------------------------------------------------------------------------------------------------------------
一、簡介
重新審視傳統文件系統在設計上的折忠選擇，衍生了GFS不同的設計思路：
*、組件/機器失效是常態，而不是意外事件（容錯性）
*、處理的文件巨大（大數據）
*、絕大多數文件寫操作都是尾部追加數據，而不是隨機寫（讀寫模型）
*、應用程序和文件系統API協同設計，簡化對GFS的要求（靈活性）
二、設計概述
1、架構：
* GFS Master（即NameNode）：單獨節點，管理GFS所有元數據（如名字空間、訪問控制權限等）
* GFS ChunkServer（即DataNode）：數據存儲節點，文件被分割爲固定大小的Chunk，每個Chunk被唯一標識，默認情況下，Chunk存儲爲3個副本。
* GFS Client：實現GFS的API接口函數（不是POSIX標準，因爲API只需在用戶空間調用）
2、單一的Master節點
* 單一的Master簡化了設計，使架構能變得簡單
* 缺點是有可能成爲系統瓶頸，故需減少對Master的讀寫 => Client只詢問Master相關文件的元數據信息，後面的具體讀寫操作均在ChunkServer上
* Master一般會返回離Client最近的文件副本（減少網絡IO）
3、Chunk的大小選擇
* 是一個關鍵的設計參數，默認爲64MB。每個Chunk都以普通Linux文件存儲在ChunkServer上
* 較大Chunk尺寸的優點：1 減少Client和Master通訊。2、減少Master存儲元數據的大小 3 Client對一個Chunk能進行多次操作，減少網絡IO。
* 較大Chunk尺寸的缺點：小文件會存儲爲一個Chunk，多個Client同時對單個小文件多次操作時，存放這個Chunk的ChunkServer會成爲熱點
4、元數據
* 均存儲於Master服務器的內存中（性能優勢），缺點爲受限於內存的大小=>一些可能的壓縮，如文件名等
* 主要有3類：1、命名空間。2、文件和Chunk的映射關係（文件包含哪些Chunk）。3、每個Chunk副本的存放信息
* 命名空間及文件和Chunk的映射關係，均以記錄變更日誌的方式落地爲系統日誌文件，並複製到遠程Master備機上。
* Chunk副本的位置信息爲Master週期性向各個ChunkServer輪詢獲得 => 沒有落地，避免了ChunkServer變更時的Master和ChunkServer的數據同步問題
* 操作日誌記錄了關鍵元數據變更歷史，對Master的容災非常重要，故只有在元數據變更持久化到日誌後，纔會對Client可見。爲了避免操作日誌過長，GFS定期會對當前操作日誌做一次Checkpoint，以壓縮B+樹形式存儲爲一個CheckPoint文件。
* 故Master的恢復只需最新的CheckPoint文件和後續的操作日誌。
5、一致性模型
* 命名空間修改爲原子性的，由Master的命名空間鎖保障
三、系統交互
* 設計原則：最小化所有操作和Master的交互
1、租約（lease）機制和數據變更順序
* 租約機制：Master確定一個Chunk副本爲主Chunk，給其建立租約，然後主Chunk對更改操作序列化，所有Chunk副本遵循這個序列執行更改操作
* 使用租約機制來保障數據多個副本變更（寫/修改操作）順序的一致性，租約序列由主Chunk產生，最小化Master管理負擔
2、數據流
* GFS將數據流和控制流分離，數據流順序沿着一個ChunkServer鏈推送，目的是爲了充分利用機器帶寬，最小化推送時延
* 基於TCP連接的，管道式數據推送方式。1MB數據理想狀態下80ms左右能分發出去
* 每臺ChunkServer會選取裏離自己最近的機器做目標推送，Google的網絡拓撲較簡單，通過IP地址就可計算出節點“距離”
3、原子的記錄追加
* GFS提供一種具有原子性的數據追加操作：記錄追加。即Client只需指定要寫入數據（而不用指定偏移值），GFS就保證至少有一次原子的寫入操作執行成功，並返回偏移值的Client
* 記錄追加的引入是爲了在分佈式應用中，減少很多Client並行對同份數據寫入的同步機制開銷
4、快照
* Client快照請求的理解：對一個文件或者目錄樹做一次拷貝
* GFS使用copy-on-write技術來實現快照：收到快照請求時，Master並沒有立即對指定Chunk拷貝，而只拷貝其元數據並對指定Chunk的引用計數增1。等到Client需要修改指定Chunk時，再在本地複製，並卻保新Chunk擁有租約
四、Master節點操作
1、命名空間管理和鎖
* 名字空間的組織：全路徑和元數據映射關係的查找表，利用前綴壓縮，高效存儲在內存中
* 名字空間樹型結構每個節點都有一個讀寫鎖，每個操作開始前都需獲得路徑上所有的讀寫鎖
- 鎖策略的設計與實現
* 避免死鎖方法：鎖的獲取依據全局一致的順序，先按名字空間層次排序，同一層次按字典序排序
2、Chunk副本的位置
* Chunk副本的位置選擇策略兩大目標：1 提高數據可靠性 2 提高網絡帶寬利用率
* 一個簡單有效的策略：多個機架分佈存儲Chunk副本
- 可靠性：預防整個機架損壞
- 帶寬利用率：尤其對Chunk讀操作，有效利用多個機架的整合帶寬(同個機架內機器間會帶寬競爭)
3、Chunk的創建，重新複製，重新負載均衡
* 創建：3個位置選擇因素，1 平衡硬盤利用率 2 限制每個ChunkServer"近期"創建Chunk個數 3 分佈在多機架間
* 重新複製：當Chunk有效副本數小於設置值，Master對Chunk副本重新複製
* 重新負載均衡：Master會週期性對Chunk副本重新負載均衡
4、垃圾回收機制
* 垃圾回收機制：GFS文件刪除時並不立即釋放物理空間，而是採用惰性策略，在週期性的常規垃圾掃描纔回收物理空間。
* 優點：1 系統設計更簡單 2 批量執行，節省開銷 3 可靠性和容錯性（防誤刪等）
* 缺點：存儲的開銷，阻礙用戶調優存儲空間使用
* 實現細節：Client提交文件刪除操作，Master將刪除操作記錄到日誌，並將對應文件名改爲包含刪除時間戳的隱藏文件名（改名字，並沒有回收物理空間）。Master週期性對名字空間做常規垃圾掃描，會在名字空間中刪除3天前（可設置）的隱藏文件及元數據。ChunkServer在與Master的心跳信息中，得知哪些Chunk的元數據不存在了，便可實際回收其物理空間
5、過期失效的Chunk副本檢測
* Chunk副本失效的原因：ChunkServer出錯或失效，導致Chunk副本因錯失一些修改操作而失效
* 通過版本號標識：只要Master給Chunk簽訂新租約（修改操作），就會增加Chunk的版本號，如果ChunkServer出錯或失效，其上面的Chunk副本的版本號就不會增加，不是最高版本號的Chunk副本就會被認爲是失效的
* 在垃圾回收機制中會刪除所有過期失效的Chunk副本
五、容錯和診斷
* 高可用性的體現，如何處理頻繁發生的組件失效
1、高可用性
* 遵循的2個簡單策略：1 快速恢復 2 複製
* 快速恢復：Master或ChunkServer關閉（正常/異常），都被設計在數秒內可恢復狀態並重啓。Client和其他服務器發現請求超時，會重連重啓的Server
* Chunk的複製：當ChunkServer關閉或Chksum校驗出損壞的Chunk副本，Master都會通過複製已有Chunk副本來保障副本個數
* Master的複製：CheckPoint文件+操作日誌完成Master的恢復。此外，GFS還有些“影子”Master，在Master宕機時提供GFS的只讀訪問
2、數據完整性
* 每個ChunkServer獨立維護Checksum來校驗自己副本的完整性，每個Chunk塊都對應一個32位的Checksum。
* 當Checksum校驗到數據損壞，ChunkServer會做2件事：1 返回給Client錯誤信息，讓Client操作其他Chunk副本 2 通知Master，請求Chunk副本複製
* 讀操作的Checksum：只取Chunk小部分額外相關數據進行校驗，對齊在Chunk塊的邊界上
* 記錄追加操作的Checksum：只增量更新最後一個不完整Chunk塊的Checksum
* 寫操作的Checksum：先讀取和校驗被寫操作覆蓋的第一個和最後一個Chunk塊，寫操作完成後再重新計算和寫入Chunksum
* 當ChunkServer空閒時，其會週期性掃描不活動的Chunk塊，檢驗數據完整性
3、診斷工具
* 詳細的、深入細節的診斷日誌，記錄GFS關鍵性事件，在問題隔離、調試及性能分析都有巨大的幫助
* RPC日誌記錄了網絡上所有請求和響應的詳細記錄，方便重現GFS的消息交互來診斷問題
* 日誌對系統性能影響很小，因爲其寫入方式爲順序的、異步的。最近的日誌保存在內存中，用於更新系統的在線監控
六、度量
1、小規模基準測試
* 機器部署：1臺Master，2臺Master複製節點，16臺ChunkServer， 16臺Client（均爲PIII 1.4GHz CPU，2GB內存，2個80G/5400rpm硬盤，100Mbps全雙工以太網，GFS集羣和Client集羣各接入一個交換機，2個交換機用1GMbps線路連接），測試結果如下圖所示：
* 讀操作： N個Client同時從GFS同步讀取數據。
- 當N=16時，整體讀取速度爲94MB/s，理論極限爲125MB/s（1Gbps線路），爲理論極限值的75%。
- 當N增大時，單Client的讀取效率下降（N=5爲80%，N=16爲75%），原因爲Client增多時，同時讀單個ChunkServer的機率也增加
* 寫操作：N個Client同時向GFS寫入數據。
- 當N=16時，整體寫入速度爲35MB/s，理論極限爲67MB/s（要寫入到16個ChunkServer中的3個副本，每個ChunkServer網卡12.5MB/s，故12.5*16/3=67MB/s），約爲理論極限的50%
- 當N增大時，單Client的讀取效率基本持平（均約爲50%）。在實際應用中，並沒有成爲主要問題
* 記錄追加操作：N個Client同時追加數據到一個文件。
- 性能受限於保存文件最後一個Chunk塊的ChunkServer的帶寬，與N大小無關。在實際應用中，ChunkServer的網絡擁塞也不是一個嚴重問題
2、實際應用中的集羣
* Google內部使用的2個具有代表性的集羣（04年）：
- 集羣A：用於內部開發和研究，典型任務爲讀取數MB/TB數據，轉化或分析後，結果寫回集羣
- 集羣B：用於處理當前生產數據，很少人工干預，持續生產和處理TB級別的數據集
* 存儲相關的集羣特性：
- 集羣B的“Dead files”比例更高（“Dead files”指物理存儲空間還沒回收的被刪除文件，或者舊版本文件），是因爲集羣B的文件更大Chunk塊數更多造成的
- ChunkServer總共保存十多GB左右元數據，主要爲Chunk塊的Checksum，此外還有Chunk塊版本號等
- Master保存幾十MB元數據（Master的內存並不會成爲系統瓶頸），每個文件約100字節，主要爲以前綴壓縮存儲的文件名，此外還有權限列表，Chunk映射關係等
- Master和ChunkServer均單機只有約有50~100MB元數據，保證了恢復服務器是非常快速的
* 讀寫速率相關的集羣特徵：
