分布式文件系統(tǒng)

分布式文件系統(tǒng)Google文件系統(tǒng)GFS系統(tǒng)架構(gòu)容錯機制系統(tǒng)管理技術Google業(yè)務全球最大搜索引擎、GoogleMaps、GoogleEarth、Gmail、YouTube等數(shù)據(jù)量巨大，且面向全球用戶提供實時服務

Google云計算平臺技術架構(gòu)文件存儲，GoogleDistributedFileSystem，GFS并行數(shù)據(jù)處理MapReduce分布式鎖Chubby分布式結(jié)構(gòu)化數(shù)據(jù)表BigTable分布式存儲系統(tǒng)Megastore分布式監(jiān)控系統(tǒng)Dapper

秘密武器：云計算平臺！GFS設計動機Google需要一個支持海量存儲的文件系統(tǒng)購置昂貴的分布式文件系統(tǒng)與硬件？為什么不使用當時現(xiàn)存的文件系統(tǒng)？Google所面臨的問題與眾不同

不同的工作負載，不同的設計優(yōu)先級（廉價、不可靠的硬件）需要設計與Google應用和負載相符的文件系統(tǒng)是否可以在一堆廉價且不可靠的硬件上構(gòu)建可靠的分布式文件系統(tǒng)？GFS設計背景Google的應用負載和技術環(huán)境集群中的節(jié)點失效是一種常態(tài)，而不是一種異常。按照傳統(tǒng)標準，文件都是非常巨大的，通常以G字節(jié)計。大部分文件都是只會在文件尾新增加數(shù)據(jù)，而少見修改已有數(shù)據(jù)的。應用程序和文件系統(tǒng)API的協(xié)同設計提高了整個系統(tǒng)的靈活性。

5GFS設計背景設計預期持續(xù)監(jiān)視、錯誤檢測、容錯處理、自動恢復對大文件有效管理同時支持小型文件文件超大文件的順序?qū)懭搿㈦S機小規(guī)模的寫入大量的操作為在文件后追加數(shù)據(jù)，幾乎沒有隨機寫入，寫完后只讀，且讀取方式基本上只有大規(guī)模順序讀和小規(guī)模隨機讀支持多路合并模式進行操作高性能的穩(wěn)定帶寬的網(wǎng)絡要比低延時更加重要接口常見操作create、delete、open、close、read、write特殊操作snapshot、recordappend(原子操作)6GFS將容錯的任務交給文件系統(tǒng)完成，利用軟件的方法解決系統(tǒng)可靠性問題，使存儲的成本成倍下降。GFS將服務器故障視為正?，F(xiàn)象，并采用多種方法，從多個角度，使用不同的容錯措施，確保數(shù)據(jù)存儲的安全、保證提供不間斷的數(shù)據(jù)存儲服務

GFS架構(gòu)是怎樣的？系統(tǒng)架構(gòu)Client（客戶端）：應用程序的訪問接口

Master（主服務器）：管理節(jié)點，在邏輯上只有一個，保存系統(tǒng)的元數(shù)據(jù)，負責整個文件系統(tǒng)的管理ChunkServer（數(shù)據(jù)塊服務器）：負責具體的存儲工作。數(shù)據(jù)以文件的形式存儲在ChunkServer上實現(xiàn)機制客戶端首先訪問Master節(jié)點，獲取交互的ChunkServer信息，然后訪問這些ChunkServer，完成數(shù)據(jù)存取工作。這種設計方法實現(xiàn)了控制流和數(shù)據(jù)流的分離。Client與Master之間只有控制流，而無數(shù)據(jù)流，極大地降低了Master的負載。Client與ChunkServer之間直接傳輸數(shù)據(jù)流，同時由于文件被分成多個Chunk進行分布式存儲，Client可以同時訪問多個ChunkServer，從而使得整個系統(tǒng)的I/O高度并行，系統(tǒng)整體性能得到提高。

GFS特點有哪些？GFS特點采用中心服務器模式可以方便地增加ChunkServerMaster掌握系統(tǒng)內(nèi)所有ChunkServer的情況，方便進行負載均衡不存在元數(shù)據(jù)的一致性問題不緩存數(shù)據(jù)

文件操作大部分是流式讀寫，不存在大量重復讀寫，使用Cache對性能提高不大ChunkServer上數(shù)據(jù)存取使用本地文件系統(tǒng)，若讀取頻繁，系統(tǒng)具有Cache從可行性看，Cache與實際數(shù)據(jù)的一致性維護也極其復雜在用戶態(tài)下實現(xiàn)

利用POSIX編程接口存取數(shù)據(jù)降低了實現(xiàn)難度，提高通用性

POSIX接口提供功能更豐富

用戶態(tài)下有多種調(diào)試工具

Master和ChunkServer都以進程方式運行，單個進程不影響整個操作系統(tǒng)

GFS和操作系統(tǒng)運行在不同的空間，兩者耦合性降低只提供專用接口降低實現(xiàn)的難度對應用提供一些特殊支持降低復雜度

GFSArchitectureClientClient代碼包含了google文件系統(tǒng)的API，并且會和master和

chunkserver進行通信。client和master通信—交互元數(shù)據(jù)信息client會緩存從master獲取的元數(shù)據(jù)信息，以便對同一塊

的操作不在通過client-master交互。client和chunkserver通信—交互文件數(shù)據(jù)client所有的數(shù)據(jù)相關的通信是直接和chunkserver進行，

但是不會緩存文件數(shù)據(jù)。11GFSArchitectureReadoperateClient讀取數(shù)據(jù)的操作順序：client把應用要讀取的文件名和偏移量，根據(jù)固定的chunk大小，轉(zhuǎn)換成為文件的chunkindex。向master發(fā)送這個包含了文件名和chunkindex的請求。master返回相關的chunkhandle以及對應的位置，client緩存這些信息。client就向最近的對應位置的chunkserver發(fā)起請求，請求包含chunkhandle以及一個在這個chunk內(nèi)需要讀取得字節(jié)區(qū)間。chunkserver返回給client要讀取的chunkdata。12GFSArchitectureMaster負責管理所有的文件系統(tǒng)的元數(shù)據(jù)文件和chunk的namespace訪問控制信息文件到chunk的映射關系當前chunk的位置等等Master控制系統(tǒng)級別的活動chunk的分配管理孤點chunk的垃圾回收機制chunk在chunkserver之間的移動Master用心跳信息周期地跟每個chunkserver通信，給他們以指示并收集他們的狀態(tài)單一Master設計必須減小master的讀/寫操作，以避免它成為集群瓶頸。Master13GFSArchitectureMaster保存三種類型的數(shù)據(jù)：文件和chunk的namespace文件到chunks的映射關系每個chunk副本的位置所有的元數(shù)據(jù)都是保存在Master的內(nèi)存里。前兩個由在master本地硬盤的記錄所有變化信息的operationlog來持久化保存的，這個記錄也會在遠端機器上保存副本。Master并不持久化保存chunk位置信息，啟動地時候以及chunkserver加入集群的時候，向每一個chunkserver詢問他的chunk信息。Metadata14GFSArchitectureOperationlog保存了關鍵的元數(shù)據(jù)變化歷史記錄,它是GFS的核心。同時作為邏輯時間基線，定義了并行操作的順序。為了Operationlog的可靠性，保證寫log原子性。我們把這個文件保存在多個不同的主機上，并且只有當刷新這個相關的操作記錄到本地和遠程磁盤之后，才會給客戶端操作應答。master通過自己的operationlog回滾自身文件系統(tǒng)狀態(tài)。

為了減少啟動時間，我們必須盡量減少操作日志的大小，采用checkpoint操作。master的恢復時候，只需要最新的checkpoint以及后續(xù)的log文件。Operationlog15GFS

Architecture在GFS下，每一個文件都拆成固定大小的chunk(塊)。每一個塊都由master根據(jù)塊創(chuàng)建的時間產(chǎn)生一個全局唯一的以后不會改變的64位的chunkhandle標志。chunkservers在本地磁盤上用Linux文件系統(tǒng)保存這些塊，并且根據(jù)chunkhandle和字節(jié)區(qū)間，通過Linux文件系統(tǒng)讀寫這些塊的數(shù)據(jù)。出于可靠性的考慮，每一個塊都會在不同的chunkserver上保存?zhèn)浞?。缺省情況下，我們保存3個備份。Chunkserver16GFSArchitectureChunksize是設計的關鍵參數(shù)(64M)。采用很大的chunksize優(yōu)點：它減少了客戶端和master的交互。減少網(wǎng)絡管理量。減少了元數(shù)據(jù)在master上的大小。采用很大的chunksize缺點：小型文件包含較少數(shù)目的chunk，也許只有一個chunk。保存這些文件的chunkserver就會在大量客戶端訪問的時候就會成為焦點，導致系統(tǒng)局部過載。Chunksizeize17GFS讀Applications通過GFSclient向GFS提交一個讀請求，Client會將文件名（filename）和chunkindex（通過程序指定的字節(jié)偏移和固定的chunksize可以計算出chunk的偏移，發(fā)送給GFSMasterMaster通過filename在namespace中找到相應的metadata，metadata中包含有文件對應chunk的chunkhandle和所在在的chunkserver的位置client緩存Master回復的metadata。Client直接去找chunkserver數(shù)據(jù)，請求信息包含了chunkhandle和byterange。chunkserver返回具體的數(shù)據(jù)。client不必再和master交互了，直接向chunkserver要數(shù)據(jù)，除非client上緩存的metadata過期了，或者文件被重新打開了。2015/10/17GFS寫一是單個client順序?qū)懚嵌嗫蛻舳说牟⑿袑戇@里的寫指都是追加操作一致性Lease租約Checkpoint時間戳Checksum校驗2015/10/17GFSWrite

客戶端向Master請求chunk每個副本所在的ChunkServer，其中PrimaryChunkServer持有修改Lease。如果沒有ChunkServer持有Lease，說明該chunk最近沒有寫操作，Master會創(chuàng)議一個任務，按照一定的策略將chunk的Lease授權(quán)給個中一臺chunkServer。

Master返回客戶端Primary和其它ChunkServer的位置信息，客戶端將緩存這些信息供以后使用。如果不出現(xiàn)故障，客戶端以后讀寫該chunk都不需要再次請求Master。

客戶端將要追加的記錄發(fā)送到每個副本。每個ChunkServer會在內(nèi)部的LRU構(gòu)造中緩存這些數(shù)據(jù)。GFS中采用數(shù)據(jù)流和控制流星散的方法，從而能夠基于收集拓撲布局更好地調(diào)劑數(shù)據(jù)流的傳輸。當所有副本都確認收到了數(shù)據(jù)，客戶端倡議一個寫要求控制號令給Primary。因為Primary可能收到多個客戶端對同一個chunk的并發(fā)追加操作，Primary將確定這些操作的挨次并寫入當?shù)?；Primary把寫請求提交給所有的Secondary副本。每一個Secondary會按照Primary確定的遞次執(zhí)行寫操作；Secondary副本成功完成后應對Primary；

Primary應答客戶端，如果有副本發(fā)生錯誤，將出現(xiàn)Primary寫成功但是某些Secondary不成功的情況，客戶端將重試。2015/10/17GFSArchitecture文件名字空間的改變（比如，文件的創(chuàng)建）是原子操作。他們是由master來專門處理的。名字空間的鎖定保證了操作的原子性以及正確性。如果不論從哪個副本上讀，所有的客戶都看到同樣的數(shù)據(jù)，那么文件的這個區(qū)域就是一致的。如果文件的區(qū)域是一致的并且用戶可以看到修改操作所寫的數(shù)據(jù)，那么它就是已定義的。

Consistencymodel21GFSArchitecture數(shù)據(jù)更改可能是寫一個記錄或是一個記錄增加（writes/recordappends）寫操作會把數(shù)據(jù)寫在應用程序指定的偏移位置。記錄增加會導致數(shù)據(jù)（記錄）增加，這個增加即使是在并發(fā)操作中也至少是一個原子操作。GFS可以在這些記錄之間增加填充，或者僅僅是記錄的重復。這些確定區(qū)間之間的填充或者記錄的重復是不一致的，并且通常是因為用戶記錄數(shù)據(jù)量比較小造成的。一系列成功的改動之后，改動后的文件區(qū)是確保確定的對所有的數(shù)據(jù)副本，按照相同順序?qū)hunk進行提交數(shù)據(jù)的改動來保證這樣的一致性。采用chunk的版本號碼控制，來檢查是否有過期的chunk改動，這種通常發(fā)生在chunkserver宕機的情況下。過期的副本將不參加到改動或者提交給master，讓master通知客戶端這個副本chunk的位置。

Consistencymodel22GFS刪除一個文件刪除時，Master節(jié)點象對待其它修改操作一樣，立刻把刪除操作以日志的方式記錄下來。Master節(jié)點并不馬上回收資源，而是把文件名改為一個包含刪除時間戳的、隱藏的名字。當Master節(jié)點對文件系統(tǒng)命名空間做常規(guī)掃描的時候，它會刪除所有三天前的隱藏文件。直到文件被真正刪除，它們?nèi)耘f可以用新的特殊的名字讀取，也可以通過把隱藏文件改名為正常顯示的文件名的方式“反刪除”。當隱藏文件被從名稱空間中刪除，Master服務器內(nèi)存中保存的這個文件的相關元數(shù)據(jù)才會被刪除。2015/10/17Google文件系統(tǒng)GFS系統(tǒng)架構(gòu)容錯機制系統(tǒng)管理技術Master容錯

MasterNameSpace，文件系統(tǒng)目錄結(jié)構(gòu)

Chunk與文件名的映射Chunk副本的位置信息(默認有三個副本)

NameSpace，文件系統(tǒng)目錄結(jié)構(gòu)

Chunk與文件名的映射Chunk副本的位置信息Master單個Master，對于前兩種元數(shù)據(jù)，GFS通過操作日志來提供容錯功能

第三種元數(shù)據(jù)信息保存在各個ChunkServer上，Master故障時，磁盤恢復

GFS還提供了Master遠程的實時備份,防止Master徹底死機的情況ChunkServer容錯

采用副本方式實現(xiàn)ChunkServer容錯每一個Chunk有多個存儲副本（默認為三個），分布存儲在不同的ChunkServer上用戶態(tài)的GFS不會影響ChunkServer的穩(wěn)定性副本的分布策略需要考慮多種因素，如網(wǎng)絡的拓撲、機架的分布、磁盤的利用率等對于每一個Chunk，必須將所有的副本全部寫入成功，才視為成功寫入GFS中的每一個文件被劃分成多個Chunk，Chunk的默認大小是64MBChunkServer存儲的是Chunk的副本，副本以文件的形式進行存儲每個Chunk又劃分為若干Block（64KB），每個Block對應一個32bit的校驗碼，保證數(shù)據(jù)正確（若某個Block錯誤，則轉(zhuǎn)移至其他Chunk副本）盡管一份數(shù)據(jù)需要存儲三份，好像磁盤空間的利用率不高，但綜合比較多種因素，加之磁盤的成本不斷下降，采用副本無疑是最簡單、最可靠、最有效，而且實現(xiàn)的難度也最小的一種方法。Simple,andgoodenough!Google文件系統(tǒng)GFS系統(tǒng)架構(gòu)容錯機制系統(tǒng)管理技術大規(guī)模集群安裝技術故障檢測技術

節(jié)點動態(tài)加入技術

節(jié)能技術

新的ChunkServer加入時，只需裸機加入，大大減少GFS維護工作量

GFS構(gòu)建在不可靠廉價計算機之上的文件系統(tǒng)，由于節(jié)點數(shù)目眾多，故障發(fā)生十分頻繁

Google采用了多種機制降低服務器能耗，如采用蓄電池代替昂貴的UPS系統(tǒng)管理技術GFS集群中通常有非常多的節(jié)點，需要相應的技術支撐

小結(jié)簡單的，就是最好的！思考GFS有什么問題嗎？提綱Hadoop簡介Hadoop分布式文件系統(tǒng)HDFSHDFS使用HDFS2015/10/17Hadoop簡介

Hadoop——Apache開源組織的一個分布式計算框架，可以在大量廉價的硬件設備組成的集群上運行應用程序，為應用程序提供了一組穩(wěn)定可靠的接口，旨在構(gòu)建一個具有高可靠性和良好擴展性的分布式系統(tǒng)

Hadoop云計算系統(tǒng)Google云計算系統(tǒng)HadoopHDFSGoogleGFSHadoopMapReduceGoogleMapReduceHadoopHBaseGoogleBigtableHadoopZooKeeperGoogleChubbyHadoopPigGoogleSawzallHadoop云計算系統(tǒng)與Google云計算系統(tǒng)

Hadoop簡介開源項目Lucene：Java開發(fā)的開源高性能全文檢索工具包

開源項目Nutch：第一個開源的Web搜索引擎

Hadoop

Hadoop簡介Hadoop項目組成

（1）HadoopCommon（2）Avro（3）Chukwa（4）HBase（5）HDFS（6）Hive（7）MapReduce（8）Pig（9）ZooKeeper

Hadoop優(yōu)點

（1）可擴展（2）經(jīng)濟（3）可靠（4）高效提綱Hadoop簡介Hadoop分布式文件系統(tǒng)HDFSHDFS使用設計前提與目標

設計前提與目標硬件錯誤是常態(tài)而不是異常流式數(shù)據(jù)訪問

超大規(guī)模數(shù)據(jù)集

簡單一致性模型

移動計算比移動數(shù)據(jù)更簡單

異構(gòu)軟硬件平臺間的可移植性

體系結(jié)構(gòu)HDFS主從結(jié)構(gòu)體系NameNode：主控制服務器，負責維護文件系統(tǒng)的命名空間（Namespace）并協(xié)調(diào)客戶端對文件的訪問，記錄命名空間內(nèi)的任何改動或命名空間本身的屬性改動DataNode：負責它們所在的物理節(jié)點上的存儲管理保障可靠性的措施

1．冗余備份每個文件存儲成一系列數(shù)據(jù)塊（Block），默認塊大小為64MB（可配置）。為了容錯，文件的所有數(shù)據(jù)塊都會有副本（副本數(shù)量即復制因子，可配置）2．副本存放采用機架感知（Rack-aware）的策略來改進數(shù)據(jù)的可靠性、可用性和網(wǎng)絡帶寬的利用率

復制因子為3時數(shù)據(jù)塊分布情況

保障可靠性的措施

3.心跳檢測NameNode周期性地從集群中的每個DataNode接受心跳包和塊報告，收到心跳包說明該DataNode工作正常4.安全模式系統(tǒng)啟動時，NameNode會進入一個安全模式。此時不會出現(xiàn)數(shù)據(jù)塊的寫操作5.數(shù)據(jù)完整性檢測

HDFS客戶端軟件實現(xiàn)了對HDFS文件內(nèi)容的校驗和（Checksum）檢查保障可靠性的措施

6.空間回收

文件被用戶或應用程序刪除時，先把它移動到/trash目錄里；只要還在這個目錄里，文件就可以被迅速恢復7.元數(shù)據(jù)磁盤失效NameNode可以配置為支持維護映像文件和事務日志的多個副本，任何對映像文件或事務日志的修改，都將同步到它們的副本上8.快照

快照支持存儲某個時間的數(shù)據(jù)復制，當HDFS數(shù)據(jù)損壞時，可以回滾到過去一個已知正確的時間點。HDFS目前還不支持快照功能提升性能的措施

提升性能措施副本選擇HDFS會盡量使用離程序最近的副本來滿足用戶請求，這樣可以減少總帶寬消耗和讀延時

負載均衡HDFS的架構(gòu)支持數(shù)據(jù)均衡策略

客戶端緩存HDFS客戶端先把數(shù)據(jù)緩存到本地的一個臨時文件，程序的寫操作透明地重定向到這個臨時文件流水線復制DataNode從前一個節(jié)點接收數(shù)據(jù)的同時，即時把數(shù)據(jù)傳給后面的節(jié)點，這就是流水線復制訪問接口

HadoopAPI（1）org.apache.hadoop.conf（2）org.apache.hadoop.dfs（3）org.apache.hadoop.fs（4）org.apache.hadoop.io（5）org.apache.hadoop.ipc（6）org.apache.hadoop.mapred（7）org.apache.hadoop.metrics（8）org.apache.hadoop.record（9）org.apache.hadoop.tools（10）org.apache.hadoop.util瀏覽器接口典型HDFS安裝會配置一個Web服務器開放自己的命名空間，其TCP端口可配；默認配置下http://namenode-name:50070這個頁面列出了集群里的所有DataNode和集群的基本狀態(tài)

提綱Hadoop簡介Hadoop分布式文件系統(tǒng)HDFSHDFS使用Overview2015/10/17Writing

Data2015/10/17Writing

Data2015/10/17Writing

Data2015/10/17Reading

Data2015/10/17Fault2015/10/17Fault2