以HDFS為例，介紹分散式檔案系統。

檔案系統

檔案系統的功能

• 檔案的按名存取（基本功能）
• 檔案目錄的建立和維護（用於實現上述基本功能）
• 實現邏輯檔案到物理檔案的轉換（核心內容）
• 檔案儲存空間的分配和管理
• 資料保密、保護和共享
• 提供一組使用者使用的操作

檔案

• 檔案是由檔名字標識的一組資訊的集合
• 各作業系統的檔案命名規則略有不同
• 實現按名存取的檔案系統的優點
  • 將使用者從複雜的物理儲存地址管理中解放出來
  • 可方便地對檔案提供各種安全、保密和保護措施
  • 實現檔案的共享（同名共享、異名共享）
• 如何實現**“按名存取”？**
  • 當用戶要求存取某個檔案時，系統查詢目錄檔案，獲得對應的檔案目錄
  • 在檔案目錄中，根據使用者給定的檔名尋找到對應該檔案的檔案控制塊（檔案目錄項）
  • 通過檔案控制塊所記錄的該檔案的相關資訊（如檔案資訊存放的相對位置或檔案資訊首塊的物理位置）依次存取該檔案的內容。

檔案目錄

• 概念
  • **檔案目錄：**建立和維護的關於系統的所有檔案的清單
  • **檔案控制塊：**每個目錄項對應一個檔案的資訊描述
  • **目錄檔案：**目錄資訊也以檔案的形式存放
• 檔案控制塊的基本內容
  • 檔案存取控制資訊：如檔名、使用者名稱、檔案主存取許可權等
  • 檔案結構資訊：檔案邏輯結構、檔案的物理結構等
  • 檔案使用資訊：已開啟該檔案的程序數、檔案的修改
    情況等
  • 檔案管理資訊：檔案建立日期、檔案訪問日期等

檔案的物理結構

• 順序檔案，連續儲存
• 連結檔案
• 索引檔案

分散式檔案系統

體系架構

• 主節點進行管理，從節點儲存資料
  • 
• 檔案切分成塊，分散儲存在從節點上

檔案訪問

• 單機多程序訪問同一檔案

  • 讀寫鎖

• 不同機器上程序訪問同一檔案

  • 加鎖效率太低，Hadoop使用一種immutable file

備份與一致性

1. 客服端備份 Client -server DFS
   • 在客戶端進行備份，將更改過的檔案傳到server，改變時client和server不一致
2. 伺服器端備份 Cluster-based DFS

HDFS

設計目標

• 假設硬體的異常比軟體的異常更加常見
• 應用程式關注的是吞吐量，而不是響應時間。
• 檔案僅支援追加，而不允許修改。
• 計算和儲存採用就近原則，把程式碼放在遠端計算，不搬運資料

資料塊

• 對於Hadoop來說，都是處理的大檔案
• 檔案由資料塊集合組成
  • 通常每塊的大小為64MB
  • 每個資料塊在本地檔案系統已單獨的檔案進行儲存（Linux檔案系統）
• 與作業系統中檔案block的區別
  • 作業系統的block是讀取的物理單元
    • 目的是節省I/O
    • block總是一樣大
  • 而在HDFS中是為了切大檔案
    • 若最後一塊小於64M，則保持原有大小

體系結構

• NameNode
  • 每個叢集只有一個
  • 負責檔案系統元資料操作、資料塊的複製和定位
• SecondaryNameNode
  • 用於NameNode的備份節點
• DataNode
  • 叢集中每個節點一個數據節點
  • 負責資料塊的儲存
  • 為客戶端提供實際檔案資料

NameNode

• 作用
  • 管理節點、接收使用者的操作請求
• 核心資料檔案包括
  • 元資料
    • 儲存在記憶體中
  • 映象檔案fsimage: 維護檔案系統樹以及檔案樹中所有的檔案/目錄的元資料（包括檔案中塊所在的資料節點的位置資訊）
  • 操作日誌檔案EditLog：記錄所有針對檔案的建立、刪除、重新命名等操作

SecondaryNameNode

• 執行過程：
  • 定期從NameNode上下載fsimage,edits。二者合併，生成新的fsimage在本地儲存，並寫回NameNode
  • 是“檢查點”，不是“熱備份”
    • 並不能保證實時都一樣
• 若直接操作image，代價很高，總是先更改日誌（記錄操作）

DataNode

• 作用
  • 提供檔案的儲存
• 檔案塊（block）：最基本的儲存單位，一個Linux檔案
  • HDFS預設Block大小是64MB，
  • 以一個256MB檔案，共有256/64=4個Block
• 不同於普通檔案系統的是，HDFS中，如果一個檔案小於一個數據塊的大小，並不佔用整個資料塊儲存空間
• 資料備份：預設是三個
• 因此，NamNode處理控制流，告訴客戶存在哪裡；而DataNode處理資料流，客戶端直接與其進行傳輸。

檔案訪問

檔案寫入HDFS

可以並行寫入不同節點

資料存放策略

目標：負載均衡，快速訪問，支援容錯

• 第一個副本：放置在上傳檔案的資料節點；如果是叢集外提交，則隨機挑選一臺磁碟不太滿、CPU不太忙的節點(快速寫入)
• 第二個副本：放置在與第一個副本不同的機架rack的節點上(減少跨rack的網路流量)
• 第三個副本：與第一個副本相同機架的其他節點上(應對交換機故障)
• 更多副本：隨機節點

從HDFS讀取檔案

從各個資料節點上傳資料塊，可以並行

資料讀取策略

• 當客戶端讀取資料時，從NameNode獲得資料塊不同副本的存放位置列表，列表中包含了副本所在的資料節點
• 可以呼叫API來確定客戶端和這些資料節點所屬的機架ID
• 最近者優先原則：當發現某個資料塊副本對應的機架ID和客戶端對應的機架ID相同時，就優先選擇該副本讀取資料，如果沒有發現，就隨機選擇一個副本讀取資料

檔案訪問模型

• 一次寫入多次讀取
  • 一個檔案經過建立、寫入和關閉後就不得改變檔案中的內容
  • 僅容許追加append（）
    • 直接對檔案增加一個block
  • 對於單檔案，不支援併發寫，只支援併發讀
    • append同一個檔案只允許同時執行一個操作
  • 修改內容需刪除，重新寫入
• 好處：避免讀寫衝突、無需檔案鎖

備份與一致性

• 一個檔案有若干備份
• 備份之間是否可能存在不一致？
  • 寫入成功的備份之間是強一致的
• 一次寫入多次讀取

容錯機制

DataNode故障

• “宕機”，節點上面的所有資料都會被標記為“不可讀”
  • 資料塊自動複製到剩餘的節點上以保證滿足備份因子
  • 由NameNode監控
• 定期檢查備份因子

NameNode故障

• 根據SecondaryNameNode中的FsImage和Editlog資料進行恢復

HDFS功能

• HDFS適合做什麼
  • 大檔案儲存
  • 流式資料訪問
• HDFS不適合做什麼
  • 大量小檔案
  • 隨機讀取
  • 延遲讀取