文档章节

Google File System(GFS)整理

BeGit
 BeGit
发布于 2017/02/06 10:37
字数 2840
阅读 258
收藏 0
GFS

 

1.服务器的各种不稳定性是个问题。

2.文件过小去管理,尺寸是个问题。

3.不断增加的海量数据加内存性能不合适的问题。

4.多客户端并行追加,提供了API和灵活性。

二.设计概述

1.随机大量小规模读取文件,可以把操作做一个排序,然后批量的执行要强于前后的来回移动。多进程并发的读写文件。或消费时读取。很多时候更突出高速率大批量处理数据(吞吐量效率,像火车站人流似的)。

2.结构对多客户端,实现多路结果合并,同时对同个文件追加。文件追加和快照对分布式应用是非常重要的。

三.架构

1.可以为不同的命名空间指定设定不同的设定级别。是一个Master控制管理一堆chunk信息,并探测地址和他们的通信调度等。

2.注意客户端只是从Master获得元数据,所有的数据操作都是由客户端和chunk服务器直接交互的。

3.客户端和chunk都不缓存数据,chunk以本地文件的方式保存,linux的文件系统会把经常访问的数据缓存再内存中。

4.Master单一节点,可以根据名称和偏移量定位文件chunk集合位置,避免客户端和chunk通信时频繁和Master交互。

5.Chunk尺寸,减少网络通信,对同个块多次操作,较大的减少元数据量。问题是某些chunk可能变成热点,比较好的解决方法是把客户端的数据也能作为服务数据提供上传。

二.元数据

1.元数据,chunk空间,关系,在那里,会保存在Master一个变更日志信息,也能传递,但不会永远保存在内存中,有新机器加入时会轮询chunk服务器中他们存储的chunk信息。

2.内存数据结构

chunk信息保存在master中,当发生chunk失效,垃圾收集可以及时的复制数据和收集垃圾,虽然把chunk保存在master的内存中,但是会受到系统承载能力的限制。绝大多数chunk都是满的。master增加有限的费用就能增加更到的chunk容量,提高简洁,高效,灵活。

3.chunk位置信息

master先保存chunk位置信息,然后会不断轮询chunk服务器,心跳检测,还是chunk服务自己最知道自己情况,所以没有在master中维护一个全局的信息。

4.操作日志

只有保证元数据变更历史及记录,而且是在元数据变更持久化之后日志文件被复制到别的机器之后才对客户端所见。而且有B-tree空间的功能和checkpoint功能,checkpoint足够小,恢复的时候也足够快。

5.一致性模型

a.region(一致),region&可以看到写入(已定义),如果是未定义的region,应用程序没必要再去细分。

b.顺序一致性,chunk版本号。

c.master会定时和chunk服务器握手,checksum是否损坏,如果有就会立刻用好的副本进行复制。一般检测窗口时间是几分钟。

6.程序的实现

a.典型的是顺序写入后的追加操作,有一些验证。

b.writers/reader都有一些checksum验证有效性。记录I/O功能包含在程序共享库中,也适用其他文件接口实现。

7.系统交互原则是最小化所有操作和master的操作

a.lease机制会以主chunk接受到的操作序列进行分派的方式,然后将其他二级副本返回的信息传递给client端,判断是操作是否成功,能保证一致性。lease就是master会租用一个primaryReplica作其他副本的代理。

b.数据流主要是线性的管道推送方式,避免拓扑推送时候均衡带宽。

c.原子的记录追加时用到了多生产/单消费的模式,避免竞争。不是每个chunk都有相同的字节,只会保证至少一次原子的事物性。这个原子性能保证region是一致性的。

d.快照,在找租约chunk前有个与master交互的过程就是快照的机会。如果发现有快照指向的chunk,那么再请求写数据时会创建个新的chunk直接写入。

8.master节点的操作,名称空间,如快照操作取消租约,名称空间的region上的锁保证正确顺序,虽然GFS有名称空间绝对路径对应的锁,但不可列出所有文件。暂时先了解文件父目录只有读取锁,可以防止被修改。锁是惰性所,在一个层级有排序,委会一个全局的一致性。

9.副本的位置,除了防丢失,主要还有考虑带宽的利用率。

a.创建chunk时,首先选择低磁盘利用率。

b.希望限制最近chunk操作的次数。

c.复制chunk有游下级别,如丢失的多的,活跃高的,影响流程的 。

d.复制时也会均衡网络间带宽,机架,原chunk操作次数等的限制。

e.最后master还会逐步的根据带宽利用率和复制因子平衡磁盘的使用情况。

10.副本的删除,是会标记一个隐藏的删除时间戳,等待master扫描时进行判断,同步元数据。master和chunk心跳检测时,判断哪些chunk已经不再元数据中,chunk就可以统一执行删除。

不同的目录可以设定文件的删除策略。过期失效的副本检测会用版本号的方式判断那些是有效并保证一致性。

11.容错和诊断,硬盘网络机器的故障不可避免,如何处理?2个策略,快速回复和复制。

a.快速恢复,毫秒级回复机器状态。

b.chunk,复制因子保证chunk数量和验证和链路层网络层不相关错误验证,因为系统主要是只读和追加操作。

c.master操作保存到本机地址和备份节点,如果master失效,几乎可以立刻恢复机器状态,客户端甚至可以指向又GFS外部新启动的master进程。

d.master有个影子服务器,功能和master主服务器类似,提供状态变更小的或不敏感状态变化信息的chunk读取操作。定期通过master副本log保持状态,只有更新操作时会和master通信更新自己的状态。

12.数据完整性

a.因为磁盘可能坏道等原因可能导致数据保存了未必正确或有可能丢失,如何检查正确性,跨区是不实际的,每个chunk都在内存和硬盘维护一个自己的checksum和日志信息。

b.读取操作前,会在要读取的范围内检查checksum,如果有错误会通知请求端和master端,请求端会从别的chunk请求数据,master会负责修复损坏的副本,就绪后会删除副本。同时checksum是很有效率的,是很小的一部分,同时不需要I/O操作。checksum更新只同步最后增加的那个块信息是频率较高的操作。

c.写前会检查起始块和最后一块,如果不检测,那么新写入的checksum可能会覆盖之前损坏的数据。

d.checksum会在chunk服务器空闲的时候检测那些chunk是否损坏,提早通知master修复或避免欺骗master副本数量。

13.诊断工具

a.日志的记录是有必要的,它带来的好处远大于系统的消耗,近期的信息放在内存中可以提供持续不断在线的监控行为。

三.度量

1.理想的读取测试时,当多个客户同时读取同一个chunk服务器的几率增加时,可能导致整体读取效率的下降。

2.写入的时候由于网络协议栈和管道的方式不相适应,加上可能多个客户机对同个chunk进行写入,导致写入的延迟和降低。

3.记录追加受限于最后一个chunk服务器的带宽。

四.实际中的集群

1.存储的文件多chunk数量就比较多。

2.元数据会保存在master和chunk服务器上,所以恢复速度都比较快,只用数秒时间就可读取,master的元数据不会成为GFS的瓶颈。

3.读写速率,读是频繁且有效率的。这也是有效利用资源的一种方式。

4.master负载一般都可以200-500以上,结构用二分法优化后速率达到每秒数千次。

5.可以在服务器失效时快速的恢复副本。据测试的环境看速度在450m/s的速度。

五.工作符合分析

1.我们可以把一个操作分成几个详细的RPC请求,通过分析日志判断和分析集群运行情况。

2.有些涉及到的小文件的读取,因为随机seek也会导致工作的负荷。

3.追加的操作一般要大于写的操作。

4.集群的工作负荷主要还是findlocation,然后是release等。

六.经验

1.GFS生产系统是严格受控的,有一些架构来防止用户间干扰,也是渐渐完善的过程。还有一点是由于linux内核和硬盘驱动的问题可能导致数据被破坏,所以用checksum来检查可能协议不匹配的问题。

2.可能有文件所主网络线程的情况,linux开源的好处就是比较好的理解和探索系统行为,甚至可以联合解决。

七.相关工作

1.与位置无关的命名空间,复制方式,流式读取或seek少量读取,master集群管控方式的简洁以及master状态保存的灾难冗余。

八.结束语


1.持续监控 复制关键数据 快速自动恢复 控制流和数据流分离 大量并发读写操作提供高吞吐量。

2.分布式操作日志,全局均衡等。

 

 

 

 

© 著作权归作者所有

上一篇: Google MapReduce整理
下一篇: Google Bigtable整理
BeGit
粉丝 20
博文 93
码字总数 71312
作品 0
顺义
后端工程师
私信 提问
读gfs2官方文档

reading link: https://access.redhat.com/documentation/en-US/RedHatEnterpriseLinux/7/html/GlobalFileSystem2/ch-overview-GFS2.html#s1-ov-newfeatures-GFS2 特点 Red Hat does not sup......

认真即可
2015/12/07
302
0
google大数据三大论文-中文版-英文版

今天查找分布式计算的有关资料,发现Google的三大核心技术MapReduce、GFS和BigTable的论文都已经被翻译成高质量的中文,更巧的是,这三篇中译版的原发地都是CSDN的Blog。其中最新的一篇是张凌...

chenhao_asd
2018/04/24
0
0
分布式数据库--Hypertable

Hypertable是一个开源、高性能、可伸缩的数据库,它采用与Google的Bigtable相似的模型。在过去数年中,Google为在PC集群 上运行的可伸缩计算基础设施设计建造了三个关键部分。第一个关键的基...

匿名
2009/01/21
22.6K
0
『Big data technologies』关于各类大数据技术概念的简介(翻译自Quora)

原文 I'll try to give a very crude overview of how the pieces fit in together, because the details span multiple books. Please forgive me for some oversimplifications. MapReduce......

灰大羊
2016/07/18
51
0
Hypertable 0.9.6.5 发布,分布式数据库

Hypertable 0.9.6.5 是一个 bugfix 版本。 Hypertable是一个开源、高性能、可伸缩的数据库,它采用与Google的Bigtable相似的模型。在过去数年中,Google为在 PC集群 上运行的可伸缩计算基础设...

oschina
2012/10/24
1K
0

没有更多内容

加载失败,请刷新页面

加载更多

只需一步,在Spring Boot中统一Restful API返回值格式与统一处理异常

统一返回值 在前后端分离大行其道的今天,有一个统一的返回值格式不仅能使我们的接口看起来更漂亮,而且还可以使前端可以统一处理很多东西,避免很多问题的产生。 比较通用的返回值格式如下:...

晓月寒丶
今天
58
0
区块链应用到供应链上的好处和实际案例

区块链可以解决供应链中的很多问题,例如记录以及追踪产品。那么使用区块链应用到各产品供应链上到底有什么好处?猎头悬赏平台解优人才网小编给大家做个简单的分享: 使用区块链的最突出的优...

猎头悬赏平台
今天
27
0
全世界到底有多少软件开发人员?

埃文斯数据公司(Evans Data Corporation) 2019 最新的统计数据(原文)显示,2018 年全球共有 2300 万软件开发人员,预计到 2019 年底这个数字将达到 2640万,到 2023 年达到 2770万。 而来自...

红薯
今天
61
0
Go 语言基础—— 通道(channel)

通过通信来共享内存(Java是通过共享内存来通信的) 定义 func service() string {time.Sleep(time.Millisecond * 50)return "Done"}func AsyncService() chan string {retCh := mak......

刘一草
今天
57
0
Apache Flink 零基础入门(一):基础概念解析

Apache Flink 的定义、架构及原理 Apache Flink 是一个分布式大数据处理引擎,可对有限数据流和无限数据流进行有状态或无状态的计算,能够部署在各种集群环境,对各种规模大小的数据进行快速...

Vincent-Duan
今天
50
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部