Google 云计算原理

电子工业出版社刘鹏主编《云计算》教材配套课件 4

课程回顾

3

GFS 的容错措施有哪些？GFS 的容错措施有哪些？

GFS 的容错机制◦ Chunk Server 容错

每个 Chunk 有多个存储副本（通常是 3 个），分别存储于不通的服务器上

每个 Chunk 又划分为若干 Block （ 64KB ），每个 Block对应一个 32bit 的校验码，保证数据正确（若某个 Block 错误，则转移至其他 Chunk 副本）

◦ Master 容错（影子节点热备）三类元数据：命名空间（目录结构）、 Chunk 与文件名的映射以及 Chunk 副本的位置信息

前两类通过日志提供容错， Chunk 副本信息存储于 Chunk Server ， Master 出现故障时可恢复

5

1 、处理流程2 、分片方式1 、处理流程2 、分片方式

MapReduce 处理流程中各类文件的存储位置在哪里？

MapReduce 的容错方法？ MapReduce 的处理优化方法？

MapReduce 仅能对 GFS 之上的文件进行处理吗？

所有步骤均可控，可灵活处理各类分布式问题

除了排序，新增两道题目◦使用 MapReduce 实现倒排索引

输入： 100 个文本文档输出：倒排索引任务

实现算法，给出数据结构描述、执行过程描述等作业要求同“排序” 要求尽可能提高执行效率，节约网络 IO 带宽

除了排序，新增两道题目◦使用 MapReduce 实现快速查询

查询目标是存储在 BigTable 之中的网页数据，给定关键字，快速查询含有该内容的网页（假定没有倒排索引）

要求设计 BigTable 存储方式（表含有哪些列、无需关心数据如何取得）

设计快速查询的 MapReduce 处理方法作业要求同“排序”

分布式锁服务 Chubby

11

主要用于解决分布式一致性问题◦在一个分布式系统中，有一组的 Process ，它们需要确定一个 Value 。于是每个 Process 都提出了一个 Value ，一致性就是指只有其中的一个 Value 能够被选中作为最后确定的值，并且当这个值被选出来以后，所有的 Process都需要被通知到

粗粒度的分布式锁服务◦ Chubby 是 Google 为解决分布式一致性问题而设计的提供粗粒度锁服务的文件系统文件系统

◦其他分布式系统可以使用它对共享资源的访问进行同步

12

需要实现的特性◦高可用性◦高可靠性◦支持粗粒度的建议性锁服务◦支持小规模文件直接存储

不作考虑的特性◦高性能◦存储能力

13

客户端应用程序

Chubby程序库

. . .

客户端应用程序

Chubby程序库

客户端进程

主服务器

Chubby 单元的5个服务器

远程过程调用

14

文件系统中文件操作的权限有哪些？文件系统中文件操作的权限有哪些？

这些权限之间的互斥关系是怎样的？这些权限之间的互斥关系是怎样的？

Chubby 系统本质上就是一个分布式的、存储大量小文件的文件系统◦ Chubby 中的锁就是文件◦ 在 GFS 的例子中，创建文件就是进行“加锁”操作，创建文件成功的那个 server 其实就是抢占到了“锁”

◦用户通过打开、关闭和存取文件，获取共享锁或者独占锁；并且通过通信机制，向用户发送更新信息

16

1

2

3 4

5

6

7

8

旧的主服务器

新的主服务器

宽限期

旧的主服务器故障

选出新的主服务器

客户端

租约期M1

租约期M2

租约期M3

租约期C1

租约期C2

租约期C3

无主服务器

危险状态临界点安全状态临界点

KeepAlives

17

主节点选举独占锁共享锁数据存取应用

◦获取 GFS ChunkServer 信息◦元数据存储◦ ……

18

分布式数据表 BigTable

19

为什么需要设计 BigTable ？◦ Google 需要存储的数据种类繁多

网页，地图数据，邮件…… 如何使用统一的方式存储各类数据？

◦海量的服务请求如何快速地从海量信息中寻找需要的数据？

BigTable ：基于 GFS 和 Chubby 的分布式存储系统◦对数据进行结构化存储和管理◦ 与 GFS 的联系

20

数据存储可靠性高速数据检索与读取存储海量的记录（若干 TB ）可以保存记录的多个版本

21

与写操作相比，数据记录读操作占绝大多数工作负载

单个节点故障损坏是常见的磁盘是廉价的可以不提供标准接口

◦ Google既能控制数据库设计，又能进行应用系统设计

22

具有广泛的适应性◦支持 Google 系列产品的存储需求

具有很强的可扩展性◦根据需要随时加入或撤销服务器◦应对不断增多的访问请求

高可用性◦单个节点易损，但要确保几乎所有的情况下系统都可用

简单性◦简单的底层系统可减少系统出错概率，为上层开发带来便利

23

总体上，与关系数据库中的表类似

Row Key Time Stamp

Column Contents

Column Anchor Column “mime”cnnsi.co

mmy.look.

ca

“com.cnn.www”

T9 CNN

T8 CNN.COM

T6 “<html>.. “

Text/html

T5 “<html>.. “

t3 “<html>.. “

24

关系数据库中的表是什么样的？有什么特征？

关系数据库中的表设计需要遵循什么原则？

关系数据库中的表是什么样的？有什么特征？

关系数据库中的表设计需要遵循什么原则？

行◦每行数据有一个可排序的关键字和任意列项◦字符串、整数、二进制串甚至可串行化的结构都可以作为行键

◦表按照行键的“逐字节排序”顺序对行进行有序化处理◦表内数据非常‘稀疏’，不同的行的列的数完全目可以大不相同

◦ URL 是较为常见的行键，存储时需要倒排统一地址域的网页连续存储，便于查找、分析和压缩

mp3.baidu.commp3.baidu.com/index.asp→com.baidu.mp3com.baidu.mp3/index.asp

mp3.baidu.commp3.baidu.com/index.asp→com.baidu.mp3com.baidu.mp3/index.asp

25

列◦特定含义的数据的集合，如图片、链接等◦可将多个列归并为一组，称为族（ family ）◦采用族 : 限定词的语法规则进行定义

fileattr:owning_group”, “fileattr:owning_user”, etc◦同一个族的数据被压缩在一起保存◦族是必须的，是 BigTable 中访问控制的基本单元

26

时间戳◦保存不同时期的数据，如“网页快照”

“A big table”◦表中的列可以不受限制地增长◦表中的数据几乎可以无限地增加

通过 (row, col, timestamp) 查询通过 (row, col, MOST_RECENT) 查询

通过 (row, col, timestamp) 查询通过 (row, col, MOST_RECENT) 查询

27

无数据校验◦每行都可存储任意数目的列

BigTable 不对列的最少数目进行约束◦任意类型的数据均可存储

BigTable将所有数据均看作为字符串◦数据的有效性校验由构建于其上的应用系统完成

一致性◦针对同一行的多个操作可以分组合并

不支持对多行进行修改的操作符

28

Row Key Time Stamp Column: Contents

Com.cnn.www T6 “<html>..”

T5 “<html>..”

T3 “<html>..”

Row Key Time Stamp Column: Anchor

Com.cnn.www T9 Anchor:cnnsi.com

CNN

T5 Anchor:my.look.ca

CNN.COM

Row Key Time Stamp Column: mime

Com.cnn.www T6 text/html

Row Key Time Stamp

Column Contents

Column Anchor Column “mime”cnnsi.co

mmy.look.

ca

“com.cnn.www”

T9 CNN

T8 CNN.COM

T6 “<html>.. “

Text/html

T5 “<html>.. “

t3 “<html>.. “

29

逻辑上的“表”被划分为若干子表（ Tablet ）◦每个 Tablet由多个 SSTable 文件组成◦ SSTable 文件存储在 GFS 之上

每个子表存储了 table 的一部分行◦元数据：起始行键、终止行键◦如果子表体积超过了阈值（如 200M ），则进行分割

30

Head node

Tablet server

GFS Chunkserver

SSTable SSTable SSTable

Tablet Tablet Tablet

Tablet server

GFS Chunkserver

SSTable

(replica)SSTable

SSTable


(replica)SSTable

Logical view:

Physicallayout:

SSTable

Chubby Server

31

为每个子表服务器分配子表，对外提供服务与 GFS垃圾回收进行交互，收回废弃的 SSTable探测子表服务器的故障与恢复负载均衡

有效缓解单点故障有效缓解单点故障

32

Tablet server

GFS Chunkserver



Tablet server

GFS Chunkserver

SSTable

(replica)SSTable

SSTable


(replica)SSTable

Logical view:

Physicallayout:

SSTable

Chubby ServerHead node

33

Chubby Server

Tablet server

GFS Chunkserver



Tablet server

GFS Chunkserver

SSTable

(replica)SSTable

SSTable


(replica)SSTable

Logical view:

Physicallayout:

SSTable

X

X X X X

Head node

34

Tablet server

GFS Chunkserver



(replica)SSTable

Logical view:

Physicallayout:

Tablet

(other tablet servers drafted to serve other “abandoned” tablets)

Backup copy of tablet made primary

Message sent to tablet server by head node

Extra replica of tablet created automatically by GFS

Chubby ServerHead node

35

任何对子表的写操作都会记录到一个存储在 GFS之上的 commit log 中◦每个子表服务器上所有子表变化对应于一个 commit log

新的数据存储到子表服务器的内存（ memtable）中

次压缩◦旧数据存储在 SSTable 中，而新数据存放在 memtable中

◦ 当 memtable体积超过一定阈值，将形成 SSTable ，并写入 GFS

◦每个 tablet 对应多个 SSTable

37

tablet 含有多个 SSTable导致查询效率低合并压缩操作读取多个 SSTable ，创建一个新的

SSTable 来保持其中的最新数据◦旧的 SSTable删除◦如果合并压缩操作完成后， tablet 只包含一个 SSTable ，那么该操作也称为主压缩

SSTable

SSTable

内存表

SSTable内存表

内存表

次压缩

次压缩

.

.

.

.

.

.

.

.

SSTable

SSTable合并压缩

.

.

.

.

SSTable

主压缩

38

内存表

写操作

读操作

子表日志

内存

GFS

SSTable文件

39

新的故障◦子表服务器内存中的 memtable丢失

恢复方法◦按照 tablet将该服务器对应的日志分片◦为每个失效 tablet 分配新的子表服务器◦新子表服务器读取对应的分段 commit log ，并按照日志修改 tablet

◦删除 commit log 中已实施的内容◦重新对外提供服务

40

局部性群组 (Locality Group)◦根据需要，将原本不存储在一起的数据，以列族为单位存储至单独的子表

◦如用户对网站排名、语言等分析信息感兴趣，那么可以将这些列族放至单独的子表，减少无用信息读取，改善存取效率

布隆过滤器 (Bloom Filter)◦什么是布隆过滤器？判断某个元素是否隶属于集合◦优点：误判概率低，其存储空间仅为 Hash 表的 1/8 至

1/4◦用于判断列键是否位于 SSTable 中，快速确定某个列键的位置

41

Bigtable 主服务器

Bigtable 客户端

Bigtable 客户端程序库

Bigtable子表服务器 Bigtable 子表服务器 Bigtable 子表服务器

处理数据处理数据处理数据

Google WorkQueue GFS Chubby

执行Open()操作

负责故障处理及监控保存子表数据及日志负责元数据存储及主服务器的选择

执行元数据操作及负载平衡

42

Google 云计算架构中 GFS 、 MapReduce 和BigTable 中是否存在集群节点复用的情况？

如何复用？节点复用的好处有哪些？ Google 云计算架构的设计对你有哪些启发？有哪些收获？

Google App Engine

44

Google App Engine 是隶属于 PaaS 类型的云服务◦一个计算环境，支持 Python 和 Java语言◦可使用 Google 的基础服务，如 BigTable 和 GFS 等◦用户仅需提供应用代码，无需服务器维护◦应用程序可根据访问量和数据存储需要的增长轻松进行扩展请求

应用服务器应用服务器应用服务器

应用管理节点

静态文件

前端

前端

前端

45

特性◦动态网络服务功能，能够完全支持常用的网络技术◦具有持久存储的空间，可支持查询、分类等基本操作◦具有自主平衡网络和系统的负载、自动进行扩展的功能◦可对用户的身份进行验证，并且支持使用 Google账户发送邮件

◦具有一个功能完整的本地开发环境，开发人员可以在自身的计算机上模拟 Google App Engine环境

46

沙盒◦一个虚拟环境◦将开发者开发的应用程序隔离在自身的安全可靠的环境中，该环境和网络服务器的硬件、系统以及物理位置完全无关

◦仅提供开发人员对基础操作系统的有限访问权限◦可以对开发人员进行更多的限制

只能通过网址抓取 API和邮件服务 API 访问其他计算机其他计算机只能通过 HTTP 或 HTTPS 与沙盒应用交互应用程序无法对平台文件系统进行写入操作，只能读取代码文件

应用程序必须使用平台的 Data Store 来存储应用程序运行期间持续存在的数据

……通过隔离来保证平台和其他开发者的安全通过隔离来保证平台和其他开发者的安全

47

图像操作 API◦开发人员可通过该 API 对 JPEG 和 PNG图像进行缩放、裁剪、旋转和翻转等操作

邮件 API◦为开发人员开发的应用程序提供电子邮件发送服务

Memcache API◦高性能的内存键值缓存，用户可使用应用程序访问该缓存◦可提高应用程序的性能并减少数据库的负载

网址抓取 API◦可以使用 HTTP 或 HTTPS 等网址来对数据进行检索

48

用户 API◦使应用程序与 Google帐号集成，支持 Google帐号身份认证

数据库 API◦为用户提供查询引擎和事务存储服务

49

print 'Content-Type: text/plain'print ''print 'Hello, world!'

print 'Content-Type: text/plain'print ''print 'Hello, world!'

50

Google 云计算小结

51

GoogleGoogle云计算应用云计算应用MapReduMapRedu

cece BigTableBigTable

GFSGFS

ChubChubbyby

Google 云计算应用类型

53

欢迎访问

中国云计算网站 http://www.chinacloud.cn

欢迎使用

《云计算》教材电子工业出版社刘鹏主编

本讲到此结束

Google 云计算原理

Documents

Transcript of Google 云计算原理