【正文】 七、通訊協(xié)議 所有的 HDFS 通訊協(xié)議都是建立在 TCP/IP 協(xié)議之上。在同一個(gè)目錄中創(chuàng)建所有的本地文件并不是最優(yōu)的選擇，這是因?yàn)楸镜匚募到y(tǒng)可能無(wú)法高效地在單個(gè)目錄中支持大量的文件。它把每個(gè) HDFS 數(shù)據(jù)塊存儲(chǔ)在本地文件系統(tǒng)的一個(gè)單獨(dú)的文件中。在當(dāng)前實(shí)現(xiàn)中，檢查點(diǎn)只發(fā)生在 Namenode 啟動(dòng)時(shí)，在不久的將來(lái)將實(shí)現(xiàn)支持周期性的檢查點(diǎn)。當(dāng) Namenode 啟動(dòng)時(shí)，它從硬盤中讀取Editlog 和 FsImage，將所有 Editlog 中的事務(wù)作用在內(nèi)存中的 FsImage 上，并將這個(gè)新版本的 FsImage 從內(nèi)存中保存到本地磁盤上，然后刪除舊的 Editlog，因?yàn)檫@個(gè)舊的 Editlog 的事務(wù)都已經(jīng)作用在 FsImage 上了。 Namenode 在內(nèi)存中保存著整個(gè)文件系統(tǒng)的名字空間和文件數(shù)據(jù)塊映射(Blockmap)的映像。 Namenode 在本地操作系統(tǒng)的文件系統(tǒng)中存儲(chǔ)這個(gè) Editlog。對(duì)于任何對(duì)文件系統(tǒng)元數(shù)據(jù)產(chǎn)生修改的操作， Namenode 都會(huì)使用一種稱為 EditLog 的事務(wù)日志記錄下來(lái)。接下來(lái)它會(huì)確定還有哪些數(shù)據(jù)塊的副本沒(méi)有達(dá)到指定數(shù)目，并將這些數(shù)據(jù)塊復(fù)制到其他Datanode 上。每個(gè)數(shù)據(jù)塊都有一個(gè)指定的最小副本數(shù)。 Namenode 從所有的 Datanode 接收心跳信號(hào)和塊狀 態(tài)報(bào)告。 安全模式 Namenode 啟動(dòng)后會(huì)進(jìn)入一個(gè)稱為安全模式的特殊狀態(tài)。如果在讀取程序的同一個(gè)機(jī)架上有一個(gè)副本，那么就讀取該副本。 當(dāng)前，這里介紹的默認(rèn)副本存放策略正在開(kāi)發(fā)的過(guò)程中。在這種策略下，副本并不是均勻分布在不同的機(jī)架上。機(jī)架的錯(cuò)誤遠(yuǎn)遠(yuǎn)比節(jié)點(diǎn)的錯(cuò)誤少，所以這個(gè)策略不會(huì)影響到數(shù)據(jù)的可靠性和可用性。 在大多數(shù)情況下，副本系數(shù)是 3， HDFS 的存放策 略是將一個(gè)副本存放在本地機(jī)架的節(jié)點(diǎn)上，一個(gè)副本放在同一機(jī)架的另一個(gè)節(jié)點(diǎn)上，最后一個(gè)副本放在不同機(jī)架的節(jié)點(diǎn)上。這種策略設(shè)置可以將副本均勻分布在集群中，有利于當(dāng)組件失效情況下的負(fù)載均衡。一個(gè)簡(jiǎn)單但沒(méi)有優(yōu)化的策略就是將副本存放在不同的機(jī)架上。在大多數(shù)情況下，同一個(gè)機(jī)架內(nèi)的兩臺(tái)機(jī)器間的帶寬會(huì)比不同機(jī)架的兩臺(tái)機(jī)器間的帶寬大。實(shí)現(xiàn)這個(gè)策略的短期目標(biāo)是驗(yàn)證它在生產(chǎn)環(huán)境下的有效性，觀察它的行為，為實(shí)現(xiàn)更先進(jìn)的策略打下測(cè)試和研究的基礎(chǔ)。 HDFS 采用一種稱為機(jī)架感知 (rackaware)的策略來(lái)改進(jìn)數(shù)據(jù)的可靠性、可用性和網(wǎng)絡(luò)帶寬的利用率。優(yōu)化的副本存放策略是 HDFS 區(qū)分于其他大部分分布式文件系統(tǒng)的重要特性。塊狀態(tài)報(bào)告包含了一個(gè)該 Datanode 上所有數(shù)據(jù)塊的列表。 Namenode 全權(quán)管理數(shù)據(jù)塊的復(fù)制，它周期性地從集群中的每個(gè) Datanode 接收心跳信號(hào)和塊狀態(tài)報(bào)告 (Blockreport)。副本系數(shù)可以在文件創(chuàng)建的時(shí)候指定，也可以在之后改變。每個(gè)文件的數(shù)據(jù)塊大小和副本系數(shù)都是可配置的。它將每個(gè)文件存儲(chǔ)成一系列的數(shù)據(jù)塊，除了最后一個(gè)，所有的數(shù)據(jù)塊都是同樣大小的。文件副本的數(shù)目稱為文件的副本系數(shù)，這個(gè)信息也是由 Namenode 保存的。 Namenode 負(fù)責(zé)維護(hù)文件系統(tǒng)的名字空間，任何對(duì)文件系統(tǒng)名字空間或?qū)傩缘男薷亩紝⒈?Namenode 記錄下來(lái)。當(dāng)前， HDFS 不支持用戶磁盤配額和訪問(wèn)權(quán)限控制，也不支持硬鏈接和軟鏈接。用戶或者應(yīng)用程序可以創(chuàng)建目錄，然后將文件保存在這些目錄里。 Namenode 是所有 HDFS元數(shù)據(jù)的仲裁者和管理者，這樣，用戶數(shù)據(jù)永遠(yuǎn)不會(huì)流過(guò) Namenode。這種架構(gòu)并不排斥在一臺(tái)機(jī)器上運(yùn)行多個(gè) Datanode，只不過(guò)這樣的情況比較少見(jiàn)。由于采用了可移植性極強(qiáng)的 Java 語(yǔ)言，使得 HDFS 可以部署到多種類型的機(jī)器上。這些機(jī)器一般運(yùn)行著 GNU/Linux操作系統(tǒng) (OS)。在 Namenode 的統(tǒng)一調(diào)度下進(jìn)行數(shù)據(jù)塊的創(chuàng)建、刪除和復(fù)制。它也負(fù)責(zé)確定數(shù)據(jù)塊到具體 Datanode節(jié)點(diǎn)的 映射。從內(nèi)部看，一個(gè)文件其實(shí)被分成一個(gè)或多個(gè)數(shù)據(jù)塊，這些塊存儲(chǔ)在一組 Datanode 上。集群中的 Datanode 一般是一個(gè)節(jié)點(diǎn)一個(gè)，負(fù)責(zé)管理它所在節(jié)點(diǎn)上的存儲(chǔ)。一個(gè) HDFS 集群是 由一個(gè) Namenode 和一定數(shù)目的 Datanodes 組成。這種特性方便了 HDFS 作為大規(guī)模數(shù)據(jù)應(yīng)用平臺(tái)的推廣。 HDFS 為應(yīng)用提供了將它們自己移動(dòng)到數(shù)據(jù)附近的接口。因?yàn)檫@樣就能降低網(wǎng)絡(luò)阻塞的影響，提高系統(tǒng)數(shù)據(jù)的吞吐量。目前還有計(jì)劃在將來(lái)擴(kuò)充這個(gè)模型，使之支持文件的附加寫(xiě)操作。這一假設(shè)簡(jiǎn)化了數(shù)據(jù)一致性問(wèn)題，并且使高吞吐量的數(shù)據(jù)訪問(wèn)成為可能。 簡(jiǎn)單的一致性模型 HDFS 應(yīng)用需要一個(gè)“一次寫(xiě)入多次讀取”的文件訪問(wèn)模型。它應(yīng)該能提供整體上高的數(shù)據(jù)傳輸帶寬，能在一個(gè)集群里擴(kuò)展到數(shù)百個(gè)節(jié)點(diǎn)。 HDFS 上的一個(gè)典型文件大小一般都在 G 字節(jié)至 T 字節(jié)。為了提高數(shù)據(jù)的吞吐量，在一些關(guān)鍵方面對(duì) POSIX的語(yǔ)義做了一些修改。比之?dāng)?shù)據(jù)訪問(wèn)的低延遲問(wèn)題，更關(guān)鍵的在于數(shù)據(jù)訪問(wèn)的高吞吐量。 流式數(shù)據(jù)訪問(wèn) 運(yùn)行在 HDFS 上的應(yīng)用和普通的應(yīng)用不同，需要流式訪問(wèn)它們的數(shù)據(jù)集。我們面對(duì)的現(xiàn)實(shí)是構(gòu)成系統(tǒng)的組件數(shù)目是巨大的，而且任一組件都有可能失效，這意味著總是有一部分 HDFS 的組件是不工 作的。這個(gè)項(xiàng)目的地址是 二、前提和設(shè)計(jì)目標(biāo) 硬件錯(cuò)誤 硬件錯(cuò)誤是常態(tài)而不是異常。 HDFS 在最開(kāi)始是作為 Apache Nutch 搜索引擎項(xiàng)目的基礎(chǔ)架構(gòu)而開(kāi)發(fā)的。 HDFS 能提供高吞吐量的數(shù)據(jù)訪問(wèn)，非常適合大規(guī)模數(shù)據(jù)集上的應(yīng)用。但同時(shí)，它和其他的分布式文件系統(tǒng)的區(qū)別也是很明顯的。 this policy does not impact data reliability and availability guarantees. However, it does reduce the aggregate work bandwidth used when reading data since a block is placed in only two unique racks rather than three. With this policy, the replicas of a file do not evenly distribute across the racks. One third of replicas are on one node, two thirds of replicas are on one rack, and the other third are evenly distributed across the remaining racks. This policy improves write performance without promising data reliability or read performance. The current, default replica placement policy described here is a work in progress. Replica Selection To minimize global bandwidth consumption and read latency, HDFS tries to satisfy a read request from a replica that is closest to the reader. If there exists a replica on the same rack as the reader node, then that replica is preferred to satisfy the read request. If angg/ HDFS cluster spans multiple data centers, then a replica that is resident in the local data center is preferred over any remote replica. Safemode On startup, the NameNode enters a special state called Safemode. Replication of data blocks does not occur when the NameNode is in the Safemode state. The NameNode receives Heartbeat and Blockreport messages from the DataNodes. A Blockreport contains the list of data blocks that a DataNode is hosting. Each block has a specified minimum number of replicas. A block is considered safely replicated when the minimum number of replicas of that data block has checked in with the NameNode. After a configurable percentage of safely replicated data blocks checks in with the NameNode (plus an additional 30 seconds), the NameNode exits the Safemode state. It then determines the list of data blocks (if any) that still have fewer than the specified number of replicas. The NameNode then replicates these blocks to other DataNodes. The Persistence of File System Metadata The HDFS namespace is stored by the NameNode. The NameNode uses a transaction log called the EditLog to persistently record every change that occurs to file system metadata. For example, creating a new file in HDFS causes the NameNode to insert a record into the EditLog indicating this. Similarly, changing the replication factor of a file causes a new record to be inserted into the EditLog. The NameNode uses a file in its local host OS file system to store the EditLog. The entire file system namespace, including the mapping of blocks to files and file system properties, is stored in a file called the FsImage. The FsImage is stored as a file in the NameNode’s local file system too. The NameNode keeps an image of the entire file system namespace and file Blockmap in memory. This key metadata item is designed to be pact, such that a NameNode with 4 GB of RAM is plenty to support a huge number of files and directories. When the NameNode starts up, it reads the FsImage and EditLog from disk, applies all the transactions from the EditLog to the inmemory representation of the FsImage, and flushes out this new version into a new FsImage on disk. It can then truncate the old EditLog because its transactions have been applied to the persistent FsImage. This process is called a checkpoint. In the current implementation, a checkpoint only occurs when the NameNode starts up. Work is in progress to support periodic checkpointing in the near future.