pb double类型文件读取_谷歌Colossus文件系统的设计经验

最新推荐文章于 2024-04-29 14:43:36 发布

weixin_39631951

最新推荐文章于 2024-04-29 14:43:36 发布

阅读量188

点赞数

文章标签： pb double类型文件读取

本文链接：https://blog.youkuaiyun.com/weixin_39631951/article/details/111664893

版权

本文介绍了谷歌从早期的GFS文件系统到Colossus的演变过程，强调了Colossus在解决扩展性、存储效率和元数据管理上的改进。Colossus通过引入D服务器取代GFS的chunk server，利用Bigtable存储元数据，实现了更大规模、更快的速度和可预测的延迟。此外，文章还讨论了存储成本、磁盘利用率和I/O优化策略，以确保集群的高效运行。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Colossus，巨人，谷歌第二代GFS文件系统。与GFS相比，Colossus相关的文章和信息却零星稀少。2017年，谷歌首席工程师 Denis Serenyi 在 PDSW 2017 (第二届国际并行数据系统研讨会)上分享《From GFS to Colossus : Cluster-Level Storage @ Google》，透露了Colossus设计的深层思考。以下是我的翻译和解读。

从 GFS 到 Colossus：谷歌的集群存储，如何使用Colossus提高存储效率。 Colossus汲取了GFS的经验教训，正如在《Storage Architecture and Challenge》中所提及的GFS的不足。

基础知识:

谷歌的第一个集群级文件系统(2001)
为具有大文件的批处理应用程序设计
同时管理metadata和chunk的单一主程序
为了可靠性，chunk通常被复制3份

GFS教训:

扩展到大约50M文件，10个P
大量大文件增加了上游应用程序的复杂性
不适用于对延迟敏感的应用程序
扩展限制增加了管理开销

而Colossus则专注于存储效率的提升以及各种扩展功能。

谷歌数据中心内部示意图。

你怎么使用PB级的空闲磁盘空间?

在紧急磁盘空间不足的情况下

典型的集群:

成千上万的机器
PB级别分布式HDD
可选的TB级本地SSD
10 GB/S的对分带宽

第1部分：从GFS到Colossus的迁移

GFS架构问题

GFS master

master节点机器不够大，不能容纳更大的文件系统
metadata操作的单一瓶颈节点
可以容错，但不是高可用

可预测的性能

没有延迟保证

GFSv2的一些明显目标

更大!
更快!
可预测的尾部延迟
用Colossus取代GFS master节点
用D服务器取代GFS 的chunk server

注意：D(Disk的缩写)服务器，它相当于在Borg上运行的GFS Chunkserver。D构成了最低的存储层，并被设计为惟一可以直接读写存储在物理磁盘上的文件的应用程序，物理磁盘被连接到D所运行的机器上。在GFS中， master节点记录文件系统元数据，Chunkserver管理原始数据chunk的读写。与此类似，D服务器管理对原始数据的访问，而Colossus服务器管理哪些数据被映射到哪个D服务器上。Colossus客户端与Colossus对话，以确定从哪个D服务器读取/写入数据，然后直接与D服务器对话，以执行读取/写入操作。如下图所示。