「后端分布式系列」前面关于 HDFS 的一些文章介绍了它的整体架构和一些关键部件的设计实现要点。

我们知道 HDFS 最早是根据 GFS(Google File System)的论文概念模型来设计实现的。

然后呢,我就去把 GFS 的原始论文找出来仔细看了遍,GFS 的整体架构图如下:

HDFS 参照了它所以大部分架构设计概念是类似的,比如 HDFS NameNode 相当于 GFS Master,HDFS DataNode 相当于 GFS chunkserver。

但还有些细节不同的地方,所以本文主要分析下不同的地方。

写入模型

HDFS 在考虑写入模型时做了一个简化,就是同一时刻只允许一个写入者或追加者。

在这个模型下同一个文件同一个时刻只允许一个客户端写入或追加。

而 GFS 则允许同一时刻多个客户端并发写入或追加同一文件。

允许并发写入带来了更复杂的一致性问题。

多个客户端并发写入时,它们之间的顺序是无法保证的,同一个客户端连续追加成功的多个记录也可能被打断。

这意味着一个客户端在连续写入文件数据时,它的数据最终在文件中的分布可能是不连续的。

所谓一致性就是,对同一个文件,所有的客户端看到的数据是一致的,不管它们是从哪个副本读取的。

如果允许多个客户端同时写一个文件,怎么保证写入数据在多个副本间一致?

我们前面讲 HDFS 时它只允许一个写入者按流水线方式写入多个副本,写入顺序一致,写入完成后数据将保持最终一致。

而对多个客户端而言,就必须让所有同时写入的客户端按同一种流水线方式去写入,才可能保证写入顺序一致。

这个写入流程我们下一节详细分析。

写入流程

GFS 使用租约机制来保障在跨多个副本的数据写入中保持顺序一致性。

GFS Master 将 chunk 租约发放给其中一个副本,这个副本我们就称为主副本,其他副本称为次副本。

由主副本来确定一个针对该 chunk 的写入顺序,次副本则遵守这个顺序,这样就保障了全局顺序一致性。

chunk 租约机制的设计主要是为了减轻 Master 的负担,由主副本所在的 chunkserver 来承担流水线顺序的安排。

如下图,我们详细描述下这个过程。

  1. 客户端请求 Master 询问哪个 chunkserver 持有租约以及其他副本的位置。

    如果没有 chunkserver 持有租约,说明该 chunk 最近没有写操作。

    Master 则选择将租约授权给其中一台 chunkserver。
  2. Master 返回客户端主副本和次副本的位置信息。

    客户端缓存这些信息以备将来使用。

    客户端以后不再需要联系 Master,除非主副本所在 chunkserver 不可用或返回租约过期了。
  3. 客户端选择最优的网络顺序推送数据,chunkserver 将数据先缓存在内部的 LRU 缓存中。

    GFS 中采用数据流和控制流分离的方法,从而能够基于网络拓扑结构更好地调度数据流的传输。
  4. 一旦所有的副本确认收到了数据,客户端将发送一个写请求控制命令到主副本。

    由主副本分配连续的序列号来确定最终的写入顺序。
  5. 主副本转发写请求到所有次副本,次副本按主副本安排的顺序执行写入操作。
  6. 次副本写完后向主副本应答确认操作完成。
  7. 最后主副本应答客户端,若任意副本写入过程中出现错误,将报告给客户端,由客户端发起重试。

GFS 和 HDFS 的写入流程都采用了流水线方式,但 HDFS 没有分离数据流和控制流。

HDFS 的数据流水线写入在网络上的传输顺序与最终写入文件的顺序一致。

而 GFS 数据在网络上的传输顺序与最终写入文件的顺序可能不一致。

GFS 在支持并发写入和优化网络数据传输方面做出了最佳的折衷。

总结

GFS 的论文发表于 2003 年,后来大部分的分布式文件系统设计实现或多或少都参考了 GFS 的设计思路。

而 HDFS 算是开源分布式文件系统中最完整实现了 GFS 论文中的概念模型。

但 HDFS 依然简化了 GFS 中关于并发写的思路,本文就两者的写入模型和过程做了一些对比说明,并希望引发一些思考。

参考

[1] Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. The Google File System

[2] Hadoop Documentation. HDFS Architecture.

[3] Robert Chansler, Hairong Kuang, Sanjay Radia, Konstantin Shvachko, and Suresh Srinivas. The Hadoop Distributed File System

[4] Tom White. Hadoop: The Definitive Guide. O’Reilly Media(2012-05), pp 94-96

[5] Yongjun Zhang. Understanding HDFS Recovery Processes

[6] Hairong
Kuang,
Konstantin
Shvachko,
Nicholas
Sze,
Sanjay
Radia,
 Robert
Chansler
, Yahoo!
HDFS
team
 Design Specification: Append/Hflush/Read
Design


[7] HDFSteam. Design Specification: HDFS Append and Truncates


下面是我的微信公众号 [瞬息之间],除了写技术的文章、还有产品的、行业和人生的思考,希望能和更多走在这条路上同行者交流,有兴趣可关注一下,谢谢。

后端分布式系列:分布式存储-HDFS 与 GFS 的设计差异的更多相关文章

  1. HDFS 与 GFS 的设计差异

    后端分布式系列」前面关于 HDFS 的一些文章介绍了它的整体架构和一些关键部件的设计实现要点. 我们知道 HDFS 最早是根据 GFS(Google File System)的论文概念模型来设计实现的 ...

  2. 后端分布式系列:分布式存储-HDFS NameNode 设计实现解析

    接前文 分布式存储-HDFS 架构解析,我们总体分析了 HDFS 架构的主要构成组件包括:NameNode.DataNode 和 Client.本文首先进一步解析 HDFS NameNode 的设计和 ...

  3. 后端分布式系列:分布式存储-HDFS 架构解析

    本文以 Hadoop 提供的分布式文件系统(HDFS)为例来进一步展开解析分布式存储服务架构设计的要点. 架构目标 任何一种软件框架或服务都是为了解决特定问题而产生的.还记得我们在 <分布式存储 ...

  4. 后端分布式系列:分布式存储-HDFS 异常处理与恢复

    在前面的文章 <HDFS DataNode 设计实现解析>中我们对文件操作进行了描述,但并未展开讲述其中涉及的异常错误处理与恢复机制.本文将深入探讨 HDFS 文件操作涉及的错误处理与恢复 ...

  5. 后端分布式系列:分布式存储-MySQL 数据库事务与复制

    好久没有写技术文章了,因为一直在思考 「后端分布式」这个系列到底怎么写才合适.最近基本想清楚了,「后端分布式」包括「分布式存储」和 「分布式计算」两大类.结合实际工作中碰到的问题,以寻找答案的方式来剖 ...

  6. 后端分布式系列:分布式存储-HDFS DataNode 设计实现解析

    前文分析了 NameNode,本文进一步解析 DataNode 的设计和实现要点. 文件存储 DataNode 正如其名是负责存储文件数据的节点.HDFS 中文件的存储方式是将文件按块(block)切 ...

  7. 后端分布式系列:分布式存储-HDFS Client 设计实现解析

    前面对 HDFS NameNode 和 DataNode 的架构设计实现要点做了介绍,本文对 HDFS 最后一个主要构成组件 Client 做进一步解析. 流式读取 HDFS Client 为客户端应 ...

  8. 分布式文件系统比较出名的有HDFS  和 GFS

    分布式文件系统比较出名的有HDFS  和 GFS,其中HDFS比较简单一点.本文是一篇描述非常简洁易懂的漫画形式讲解HDFS的原理.比一般PPT要通俗易懂很多.不难得的学习资料. 1.三个部分: 客户 ...

  9. 分布式文件管理系统HDFS

    Hadoop 分布式文件管理系统HDFS可以部署在廉价硬件之上,能够高容错. 可靠地存储海量数据(可以达到TB甚至PB级),它还可以和Yam中的MapReduce 编程模型很好地结合,为应用程序提供高 ...

随机推荐

  1. bzoj1767[Ceoi2009]harbingers 斜率优化dp

    1767: [Ceoi2009]harbingers Time Limit: 10 Sec  Memory Limit: 64 MBSubmit: 421  Solved: 112[Submit][S ...

  2. 服务器使用nginx做代理,通过HttpServletRequest获取请求用户真实IP地址

    首先,在nginx配置中添加如下配置 server { listen ; server_name www.wenki.info; #要访问的域名 charset utf8; location / { ...

  3. 本地缓存,Redis缓存,数据库DB查询(结合代码分析)

    问题背景 为什么要使用缓存?本地缓存/Redis缓存/数据库查询优先级? 一.为什么要使用缓存 原因:CPU的速度远远高于磁盘IO的速度问题:很多信息存在数据库当中的,每次查询数据库就是一次IO操作所 ...

  4. 华科机考:N阶楼梯上楼

    时间限制:1秒空间限制:32768K 题目描述 N阶楼梯上楼问题:一次可以走两阶或一阶,问有多少种上楼方式.(要求采用非递归) 输入描述: 输入包括一个整数N,(1<=N<90). 输出描 ...

  5. Linux学习之CentOS(十二)----磁盘管理之 认识ext文件系统(转)

    认识ext文件系统 硬盘组成与分割 文件系统特性 Linux 的 EXT2 文件系统(inode) 与目录树的关系 EXT2/EXT3 文件的存取与日志式文件系统的功能 Linux 文件系统的运行 挂 ...

  6. 初识Redis系列之四:.net使用Redis存储数据

    首先Redis在Windows上的安装前面的文章已经介绍过,这里不介绍了,直奔主题, 直接来看看.net怎么使用Redis 首先需要引用redis相关的dll,两个途径,意识网上下载编译好的dll : ...

  7. .9-浅析express源码之请求处理流程(2)

    上节漏了几个地方没有讲. 1.process_params 2.trim_prefix 3.done 分别是动态路由,深层路由与最终回调. 这节就只讲这三个地方,案例还是express-generat ...

  8. ArrayList源码和多线程安全问题分析

    1.ArrayList源码和多线程安全问题分析 在分析ArrayList线程安全问题之前,我们线对此类的源码进行分析,找出可能出现线程安全问题的地方,然后代码进行验证和分析. 1.1 数据结构 Arr ...

  9. Hibernate异常之cascade

    org.hibernate.MappingException: Unsupported cascade style: delete-option at org.hibernate.engine.spi ...

  10. Node.js 工具模块

    在 Node.js 模块库中有很多好用的模块.接下来我们为大家介绍几种常用模块的使用: 序号 模块名 & 描述 1 OS 模块 提供基本的系统操作函数. 2 Path 模块提供了处理和转换文件 ...