大数据经典论文解读
徐文浩
bothub 创始人
13843 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 59 讲
大数据经典论文解读
15
15
1.0x
00:00/00:00
登录|注册

03 | The Google File System (一): Master的三个身份

你好,我是徐文浩。从今天开始,我们就正式地来一起解读和学习大数据领域中,一些经典的论文。这节课,我们就从“The Google File System”这篇论文开始。
这篇论文发表在 2003 年,现在来看,它算是一篇“老”论文了。然而在我第一次看到这篇论文的时候,它可代表着强大而神秘的黑科技。
在这篇论文发表之前,工业界的分布式系统最多也就是几十台服务器的 MPI 集群。而这篇 GFS 的论文一发表,一下子就拿出了一个运作在 1000 台服务器以上的分布式文件系统。并且这个文件系统,还会面临外部数百个并发访问的客户端,可以称得上是石破天惊。
当然,在 18 年后的今天,开源社区里的各种分布式系统,也都远比当初的 GFS 更加复杂、强大。回顾这篇 18 年前的论文,GFS 可以说是“技术上辉煌而工程上保守”。说 GFS 技术上辉煌,是因为 Google 通过廉价的 PC 级别的硬件,搭建出了可以处理整个互联网网页数据的系统。而说 GFS 工程上保守,则是因为 GFS 没有“发明”什么特别的黑科技,而是在工程上做了大量的取舍(trade-off)。

GFS 的设计决策

在我看来,GFS 定了三个非常重要的设计原则,这三个原则带来了很多和传统的分布式系统研究大相径庭的设计决策。但是这三个原则又带来了大量工程上的实用性,使得 GFS 的设计思路后续被 Hadoop 这样的系统快速借鉴并予以实现。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

GFS(Google文件系统)是一篇经典的分布式系统论文,强调了工程上的“简单”设计原则。该系统采用单Master架构,但Master实际上具有三种不同的身份,包括目录服务、同步复制的主节点以及异步复制的主节点。GFS根据硬件特性进行设计取舍,重视顺序读写的性能,并采用流水线式的数据传输来减少数据在网络上的传输。此外,GFS放宽了数据一致性的选择,对随机写入和追加写入的一致性没有严格保障,而是将这些任务交给了客户端。在工程实践中,GFS通过一系列工程手段提高了系统的可用性和可恢复性,包括Checkpoints和操作日志、Backup Master、外部的监控程序,以及只读的影子 Master。这些工程保障措施使得GFS在故障下具有快速恢复能力和高可用性。文章还提到了GFS的客户端缓存机制以及Master重启时重新获取chunk存放在哪些chunkserver上的元数据的问题。总的来说,GFS的设计思路为后续分布式系统的设计和实现提供了宝贵的经验和启示。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《大数据经典论文解读》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(34)

  • 最新
  • 精选
  • 在路上
    徐老师好,MIT 6.824的GFS那一讲的讲解框架是介绍分布式存储系统的矛盾、GFS的特点、内部结构和读写操作,一般介绍HDFS的书籍也是类似的流程。不过老师从简单性、考虑硬件性能、结合业务特点三个角度来谈GFS让我有了新的启发。在老师的鼓励下,今天我试着读了《The Google File System》的一部分,花了四个小时读完了INTRODUCTION和DESIGN OVERVIEW,体会到了一点论文的精辟,希望自己能坚持下去。 回到老师的问题,GFS client会缓存chunk对应的chunkserver地址,直到缓存信息过期或者文件重新打开。这种机制是否会读到过时的数据呢?论文中是这样说的,Since clients cache chunk locations, they may read from a stale replica before that information is refreshed ... as most of our files are append-only, a stale replica usually retures a premature end of chunk rather than outdated data. 也就是说,只会读不到最新的数据,不会读到过时的数据。 论文中的2.6.2 Chunk Locations讨论了chunk location的管理机制,chunkserver启动时上报chunk location information,之后再周期性上报。之所以这么设计,主要考虑两个原因。第一,消除master和chunkserver的同步问题,第二,chunkserver真正管理了chunk,对于chunk location拥有最终的话语权。

    作者回复: 赞👍你真的很棒!

    2021-09-26
    3
    39
  • 1. 为了减少master的压力,所以要缓存master上的元数据信息。应该会造成读过期数据,因为写入不可变,但支持追加写,对于追加写入的chunk的元数据,怎么同步到客户端缓存按照GFS简单性的原则怕是不想做了。 2. 每个chunkserver会上报自己拥有哪些chunk。原因的话,chunkserver必然有这个信息,如果master还持久化的话,突然冒出个数据一致性的问题得考虑,数据链路上也会更复杂。

    作者回复: 👍和论文里的说法基本一样。

    2021-09-24
    14
  • pedro
    mit6.824在讲GFS的时候说,GFS并没有什么理论创新,但是它一下子搞了1000多台机器的集群,对其它论文而言完全是降维打击,然后它就被会议接收了。

    作者回复: 是这样的,打个不一定恰当的比方,就像大家都在搞核理论的时候,Google炸了一枚核弹说核物理就是这样的。

    2021-09-24
    2
    13
  • webmin
    1. GFS客户端会在读取数据时,把文件其余块的元数据缓存在本地,因为是追加写已写入成功的元数据短期不会变化,再者从空间局部性的原理出发,读部分块后,大概率会要接下来读这个文件余下块,所以提前装载元数据也算是一种优化预测吧; 2. master重启后,会让chunkserver上报自己管理的chunk的meta信息,这样做可以我想是考虑到了在master关闭期间chunkserver本身会发生一些变化,比如chunkserver的主备发生切换或者因为运维需要调整了chunkserver的IP地址等吧。

    作者回复: 👍

    2021-09-26
    9
  • Geek_74dea9
    chunk的位置信息并不会持久化,而是在master启动的时候, 让chunk server汇报给master

    作者回复: 回答正确,相信你一定仔细去看了论文。

    2021-09-27
    5
  • 推推。
    想问一下 master 如何更新 chunk server的状态和数据呢 如果有 chunk server failed了 如何建立一个新的trunk server 呢

    作者回复: 这部分可以读一下论文 4.3 部分,master和chunkserver之间有心跳 集群并不会“创建”新的trunk server,而是有新的硬件加入到trunk server,master可以根据策略去做rebalance。 如果有硬件下线,master也不关心如何恢复,他只会利用剩下的硬件来确保3份replica来保持可用性。

    2021-09-28
    2
    3
  • 潇湘夜雨
    想请问下,看gfs三驾马车等论文需要啥前置知识吗,我正在学大数据相关技术与框架,对分布式不是很了解,看论文有点摸不着头脑

    作者回复: 潇湘夜雨同学, 你好,从我自己读论文的经验来看。读GFS,MapReduce和BigTable的论文,对于背景知识的要求不高。也比较容易读懂。 对于没有太多实际分布式系统经验的同学来说,主要的学习挑战,会在后续的Chubby,Spanner这些论文中。不过我会在里面补充足够的基础知识,让大家能够读懂这些看起来有些复杂的论文。

    2021-09-26
    1
  • 不加y
    数据写入过程没有描述,老师数据写入的整体流程是什么样的?比如数据是三副本,三个副本的数据都写成功,才算是写成功吗?

    作者回复: 往后看05

    2023-03-28归属地:广东
  • 海滨
    1. 客户端应该会缓存请求过的文件对应的chunk sever的元数据信息,这部分数据占用大小很小非常适合缓存,缓存之后可以减少对master server的压力。 缓存的数据是可能过时的,我觉得主要分2种情况,一种是文件chunk对应的chunk sever变了,这个时候文件chunk一旦请求不到重新向master重新请求更新就可以了;还有一种情况数据更新了,比如文件对应的chunk数变多了,这种情况应该在chunk sever有相关机制来校验这种情况吧。 2. 还没有读过论文,我猜测应该是chunk sever主动上报的方式来使master重新拿到这个数据的吧

    作者回复: 👍

    2021-10-02
  • 融冰
    1. 客户端会缓存文件和 chunkserver 的映射,这个缓存会在时效结束或者文件被重新打开的时候失效 2. chunk 存放在什么 chunkserver 这个由 chunkserver 自己维护,master 重启的时候会跟所有 chunkserver 获取对应存储的 chunk

    作者回复: 👍

    2021-10-01
    2
收起评论
显示
设置
留言
34
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部