探索谷歌文件系统GFS：大数据存储与高性能设计

需积分: 8 17 浏览量更新于2024-07-09 收藏 329KB PDF 举报

"13、GFS.pdf论文深入探讨了谷歌开发的大数据分布式存储系统——Google File System（GFS）。该系统是谷歌针对其大规模数据密集型应用设计的，旨在提供在廉价商用硬件上的高可用性和高性能。与早期的分布式文件系统相比，GFS的设计思路源于对Google内部工作负载的观察以及当时和预期的技术环境，这些都标志着与传统设计原则的显著差异。 GFS的主要目标是实现数据的高可靠性，即使在硬件故障频繁的情况下也能确保服务的连续性。它通过将大量数据分布在成千上万台机器的数千个磁盘上，实现了极高的存储容量。这个系统广泛应用于Google内部，不仅支撑着服务产生的海量数据生成和处理，还服务于需要大型数据集的研究和开发工作。截至当时，最大的集群已能提供数百TB的存储空间，跨越数千台机器，显示了其强大的扩展性和性能。设计上，GFS挑战了传统的文件系统假设，例如单一命名空间、全局一致性以及对单点故障的依赖。它采用了多副本机制来保证数据冗余，即使某个节点或磁盘发生故障，其他副本仍然可以提供服务。同时，为了支持大规模并发读写，GFS采用了分块存储和异步复制策略，允许数据在多个节点之间快速地进行分布式操作。此外，GFS还强调了对客户端性能的优化，通过预分配和缓存策略减少了I/O延迟，提高了系统的整体响应速度。它的设计也考虑到了数据的一致性模型，尽管不是强一致性，但在许多实际场景下，这种模型能够满足Google对于数据处理的需求。总结来说，GFS作为大数据时代的关键基础设施，其设计理念和实践对后来的分布式存储系统产生了深远影响，尤其是Hadoop HDFS（Hadoop Distributed File System）等开源项目。这篇论文详细阐述了GFS如何在成本效益和性能之间取得平衡，展示了在现代云计算环境中，如何通过创新设计应对大规模数据管理的挑战。"

Legend:

Data messages

Control messages

Application

(file name, chunk index)

(chunk handle,

chunk locations)

GFS master

File namespace

/foo/bar

Instructions to chunkserver

Chunkserver state

GFS chunkserverGFS chunkserver

(chunk handle, byte range)

chunk data

chunk 2ef0

Linux file system Linux file system

GFS client

Figure 1: GFS Architecture

and replication decisions using global knowledge. However,

we must minimize its involvement in reads and writes so

that it does not become a bottleneck. Clients never read

and write ﬁle data through the master. Instead, a client asks

the master which chunkservers it should contact. It caches

this information for a limited time and interacts with the

chunkservers directly for many subsequent operations.

Let us explain the interactions for a simple read with refer-

ence to Figure 1. First, using the ﬁxed chunk size, the client

translates the ﬁle name and byte oﬀset speciﬁed by the ap-

plication into a chunk index within the ﬁle. Then, it sends

the master a request containing the ﬁle name and chunk

index. The master replies with the corresponding chunk

handle and locations of the replicas. The client caches this

information using the ﬁle name and chunk index as the key.

The client then sends a request to one of the replicas,

most likely the closest one. The request speciﬁes the chunk

handle and a byte range within that chunk. Further reads

of the same chunk require no more client-master interaction

until the cached information expires or the ﬁle is reopened.

In fact, the client typically asks for multiple chunks in the

same request and the master can also include the informa-

tion for chunks immediately following those requested. This

extra information sidesteps several future client-master in-

teractions at practically no extra cost.

2.5 Chunk Size

Chunk size is one of the key design parameters. We have

chosen 64 MB, which is much larger than typical ﬁle sys-

tem block sizes. Each chunk replica is stored as a plain

Linux ﬁle on a chunkserver and is extended only as needed.

Lazy space allocation avoids wasting space due to internal

fragmentation, perhaps the greatest objection against such

a large chunk size.

A large chunk size oﬀers several important advantages.

First, it reduces clients’ need to interact with the master

because reads and writes on the same chunk require only

one initial request to the master for chunk location informa-

tion. The reduction is especially signiﬁcant for our work-

loads because applications mostly read and write large ﬁles

sequentially. Even for small random reads, the client can

comfortably cache all the chunk location information for a

multi-TB working set. Second, since on a large chunk, a

client is more likely to perform many operations on a given

chunk, it can reduce network overhead by keeping a persis-

tent TCP connection to the chunkserver over an extended

period of time. Third, it reduces the size of the metadata

stored on the master. This allows us to keep the metadata

in memory, which in turn brings other advantages that we

will discuss in Section 2.6.1.

On the other hand, a large chunk size, even with lazy space

allocation, has its disadvantages. A small ﬁle consists of a

small number of chunks, perhaps just one. The chunkservers

storing those chunks may become hot spots if many clients

are accessing the same ﬁle. In practice, hot spots have not

been a major issue because our applications mostly read

large multi-chunk ﬁles sequentially.

However, hot spots did develop when GFS was ﬁrst used

by a batch-queue system: an executable was written to GFS

as a single-chunk ﬁle and then started on hundreds of ma-

chines at the same time. The few chunkservers storing this

executable were overloaded by hundreds of simultaneous re-

quests. We ﬁxed this problem by storing such executables

with a higher replication factor and by making the batch-

queue system stagger application start times. A potential

long-term solution is to allow clients to read data from other

clients in such situations.

2.6 Metadata

The master stores three major types of metadata: the ﬁle

and chunk namespaces, the mapping from ﬁles to chunks,

and the locations of each chunk’s replicas. All metadata is

kept in the master’s memory. The ﬁrst two types (names-

paces and ﬁle-to-chunk mapping) are also kept persistent by

logging mutations to an operation log stored on the mas-

ter’s local disk and replicated on remote machines. Using

a log allows us to update the master state simply, reliably,

and without risking inconsistencies in the event of a master

crash. The master does not store chunk location informa-

tion persistently. Instead, it asks each chunkserver about its

chunks at master startup and whenever a chunkserver joins

the cluster.

2.6.1 In-Memory Data Structures

Since metadata is stored in memory, master operations are

fast. Furthermore, it is easy and eﬃcient for the master to

periodically scan through its entire state in the background.

This periodic scanning is used to implement chunk garbage

collection, re-replication in the presence of chunkserver fail-

ures, and chunk migration to balance load and disk space

剩余14页未读，继续阅读

BayMaxFly

粉丝: 1
资源: 5

探索谷歌文件系统GFS：大数据存储与高性能设计

Google三篇论文-GFS英文版.pdf

GFS论文中英文版.rar

Linux集群文件系统GFS的研究应用.pdf

地基探测与NCEP GFS模式预报云量在ARM SGP站点对比.pdf

分布式系统领域经典论文翻译集.pdf

论文研究-一种双线性快速模糊增强图像边界检测最新算法.pdf

carbonite06.pdf

Hadoop题库.pdf

Google File System.pdf

Hadoop集群搭建.pdf

最新资源