分散式文件系統設計與實現

忙著開發軟體，最近一直沒什麼時間寫作。

今天我們談一下關於分散式文件系統。

分散式文件系統在一直在存儲領域擁有舉足輕重的地位，涉及知識也比較多。

主流分散式系統設計，主要分為三個方向：

[1] 分散式存儲系統

[2] 分散式計算系統

[3] 分散式管理系統

今天我們談中我們比較熟悉的設計與實現。

談到分散式文件系統，目前大家比較熟悉的GFS(Google File System)或者GFS開源實現HDFS。

目前在國內已經家喻戶曉，稍微大一點的公司都在使用HDFS，可以說HDFS是大數據系統的基石。

Hadoop 3.1版本發布，增加對各種雲端存儲系統的支持，設計很有意思，以後內容會介紹。

非結構化數據存儲

GFS是開發出來存儲Google海量的日誌數據，網頁，文檔等文本信息，並且對其進行批處理，比如：配合 mapreduce 為文檔建立倒排索引，計算網頁 PageRank。

設計初衷，為了支持更大規模數據處理和很高的合計吞吐量，擁有很強的擴展性，可容納那麼大了的非結構化數據。

因為數據分散式存儲，需要大量取數據計算，必須支持很強的容錯性，設計之初貼近實際生產，組合一堆普通機器形成集群，提供強大的存儲能力，大量機器配合工作，系統故障和硬體故障被認為是常態。

GFS很好地解決了，大文件，大規模順序數據追加寫，提供很高的合計吞吐量。

GFS，HDFS一類的分散式文件系統，非常適合數據一旦寫入，文件很少修改的場景。這樣的設計導致幾乎無法支持隨機訪問（random access）操作，面對低延遲、實時性要求高的場景不適合。

GFS分散式文件系統，並非標準的Posix標準實現，GFS主要提供快照和記錄追加操作，多路結果合併。

GFS架構

使用Master->Slave設計，元數據信息主要由Master管理，這樣的設計大大降低系統的實現難度。

為防止Master壓力過大，限制了數據存儲大量，GFS中數據存儲單元使用Chunk表示，Chunk支持64M。

Master節點掌握整個集群數據存儲核心數據，集群擴展能力受限於master節點內存，比如：大量小文件導致元數據信息爆滿。

分散式文件系統多副本，可支持容錯的讀取數據，根據負載情況，最近副本取數據。

因為集群支持容錯，故障自動恢復，所以整個集群可以擴展到很大規模，在傳統MPI、MPP中無法支持很大規模。

而今天我們也看到MPP和支持超大規模分散式文件系統融合的案例，使得MPP計算層可擴展到更大規模。

熱點數據

分散式文件系統，熱點數據，導致系統局部過載而出現嚴重故障？

在分散式非結構化數據存儲中，是非常常見的，比如我們某個公共庫文件或程序，為使用方便和容錯，大家把它存儲在HDFS，它被切塊存儲於100個節點的集群某3個機器中，由於大量業務系統或者程序隨機載入引用，導致某3個機器壓力特別大，看到監控系統飄紅。

我們可以通過增加副本數量，來讓更多副本能提供訪問服務，解決問題。

早期使用MapReduce/Spark系統，為縮短計算時間，默認3副本，我們提高到6，9個，增加數據本地化計算的幾率。

元數據

集群擴展Slave受限於Master節點內容，元數據信息都存在Master，並且常駐內存，大量小文件也會造成Master性能下降。

操作日誌

操作日誌的作用

[1] 持久化存儲metadata

[2] 存儲完整的操作命令，保障最終的操作順序

元數據信息的變更，全都是通過日誌記錄來實現的，通過日誌複製到多個節點，保障可靠性，即使主節點損壞，也可恢復其他節點為主節點，繼續提供服務。日誌可復現任何一個時間點的操作行為，保障系統數據。

Check point

當operation log達到一定大小時，GFS master會做checkpoint，相當於把內存的B-Tree格式的信息dump到磁碟中。當master需要重啟時，可以讀最近一次的checkpoint，然後replay它之後的operation log，加快恢復的時間。

做checkpoint的時候，GFS master會先切換到新的operation log，然後開新線程做checkpoint，所以，對新來的請求是基本是不會有影響的。

狀態數據，底層主要使用高度壓縮的B-Tree存儲。

快照

使用copy-on-writer實現，基本上不會對現有數據讀取有影響。

只讀數據存儲

[1] 適合追加方式的寫入和讀取操作

[2] 很少有隨機寫入操作

目前HDFS，GFS主要用來存儲海量的離線數據，提供海量非結構化數據存儲場景。

如果需要支持隨機寫、更新、刪除數據，就選其他系統，比如：Kudu

冗餘解決方案

容錯考慮需要，有三倍冗餘，目前主要有Erasure Codes實現，奇偶校驗方法，可以縮小大量存儲佔用。

小結

[1] 沒有在文件系層面提供任何的Cache機制，訪問順序讀取載入大量文件，Cache支持意義不大

[2] 單個應用執行時機會不會重複讀取數據

[3] GFS/HDFS適合流式讀取一個大型數據集

[4] 在大型數據集中隨機seek到某個位置，之後每次讀取少量數據，提升效率。

[5] GFS/HDFS設計預期是使用大量的不可靠節點組件集群，因此，災難冗餘是此類系統設計的核心。

[6] 存儲固定大小的Chunk，容易重新均衡數據。

[7] 原子記錄追加，保障系統數據一致性。

[8] 中心Master設計，讓複雜的分散式系統實現簡單化，不用考慮數據一致性，元數據同步問題。

GFS/HDFS設計初衷，保障有大量並發讀寫操作時，能夠提供很高的合計吞吐量。

通過分離控制流(Master)和數據流(Chunk client)來實現，所以我們經常提起的Edge節點會對整個系統性能有很大的影響。

Master節點負載過高，通過Chunk租約將控制權交給主副本(主Chunk)，將Master壓力降到最低。

目前類似GFS的開源實現，主流選擇HDFS，而且HDFS在實現上，彌補很多GFS中的不足。我也沒看到有可替代HDFS的系統，因為有HDFS造就今天繁榮的Hadoop生態系統，數據分析引擎、數據存儲引擎百花齊放。

軟體系統的設計與實現是為解決現實問題而出現，設計上會有很多權衡，不同的權衡造就不同的系統，各自有擅長的場景。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！