当前课程知识点:大数据系统基础 >  3.文件存储 >  授课视频 >  Video

返回《大数据系统基础》慕课在线视频课程列表

Video在线视频

Video

下一节:Video

返回《大数据系统基础》慕课在线视频列表

Video课程教案、知识点、字幕

这一节我们再考虑一下

Google文件系统当中的

可靠性的问题

那么可靠性的问题

跟我们前面分析的性能问题一样

我们也分成两个角度

去看这个问题

一个是

块服务器的一个可靠性问题

看看块服务器

会出现错误的时候

那么整个系统该怎么办

第二个是

我们需要考虑主服务器

就是master服务器

出现的可靠性的问题

显而易见

这个master服务器可靠性问题

会更加严重一点

因为它一旦出现错误的时候

整个系统可能就不能访问了

那么我们先去解决一下

块服务器的一个可靠性的问题

那么块服务器的可靠性问题的话

我们就考虑一个

非常简单的一个场景

就是这个块服务器

出现整个服务器的宕机

或者整个服务器全部坏掉了

那么当然也有可能就是说

比如说我们是

四五千台服务器的情况下面

不太可能只出现

一台服务器的错误

那么同时可能会出现几十台

比如说

我踢掉一个机架的一个电源

那么整个机架将近40多台服务器

全部就会下线

在这种情况下面

这种可靠性我们怎么进行处理

那么在这里面的话

我们可以先假设

有一个人会帮助我们做这个事情

那么这个人

就是这个master服务器

那么在整个集群里面

我们可以通过master服务器

来处理整个块服务器

可能会出现的一个

出错的一个问题

那么对于master服务器来讲的话

这个集成当中

我可以通过一些集群的一些监控

去看一下某一台服务器

是不是还在线

那么所有的信息

可以汇报给master服务器

那么master服务器相对来说

去监控整个集群来说

也是非常方便的

因为这个时候

不需要实时地监控

可能需要隔个几分钟去监控一次

所以总的数据量也不是很大

当master服务器

发现某一台

块数据服务器不在线的时候

那么这个时候

我需要做的工作是什么工作呢

那实际上就是说

我需要把数据的副本

因为我们知道

原来的数据副本是三个副本

那么在某一台服务器

或者几台服务器掉线的时候

那么可能这个是数据块1

那么它整个数据块

某一个副本可能就下线了

那么这个时候副本下线的时候

我们就需要从两个副本

重新恢复成三个副本

那么这个时候对于master来说

它可以扫描整个集群系统

那么它可以统计

哪个数据块可能会出现错误

因为所有的数据

都是在它的内存当中

它在内存当中扫描一遍

比对一下

整个在系统当中

还有的数据块

这样的话我就知道哪几个数据块

丢了某一个副本

那么它就可以启动

副本恢复的过程

那副本恢复就很简单

那么无非就是告诉两个结点

比如说这是A这个结点

另外一个B这个结点

那么就可以把这个数据

从A这个结点复制到B这个结点

这样的话

整个Chunk1就可以恢复成

3个副本

那么这是这么一个过程

那么我们可以算一下这个过程

比如说我掉了一个

服务器掉线了

那么我需要恢复它的数据

大概需要多长时间

那么我们假设

我们现在这个服务器能力

会比较差一点

可能这个服务器

每台服务器存了2个T的数据

那么我们看一下

恢复2个T的数据

大概需要多长时间

在这种情况下面

大家想一下

看看我第一个计算过程是不是对

那么对于2T来说

比如说我们就是在一个磁盘上面

我恢复它的数据的话

那实际上一个磁盘

如果我顺序读写的话

我们假设能够达到200M

这是非常理想的一个数据情况了

那么200M每秒

那么在这里面的话

我们看看需要恢复多长时间

那么2乘以1024 这个是G

再乘以1024

这儿多M

拿再除以200M每秒

那么这是5

这儿MM约了

这儿除一下算5吧

所以是10K

大概是1万秒左右

1万秒的话

可能超过将近2个多小时

大于2个多小时

那么如果你恢复这2个T的数据

需要2个小时的话

这个时间是非常慢的

对不对

那么大家考虑一下

这个计算过程是不是正确的

好 那实际上呢

这个是不正确的

为什么呢

我们看一下

我们有一个Chunk是c1

我们有另外一个Chunk

我们找一台服务器吧

比如说我要坏掉的一个服务器

这台服务器上面

有Chunk1 有Chunk2 对不对

那么在另外一台服务器上面

它可能也有Chunk1 对吧

那么还有一台服务器

它也有Chunk1

那么在这样的情况下

我们再找两台服务器

这台服务器有Chunk2

另外一台服务器有Chunk2

那我看一下

我恢复数据的过程是什么样子的

那么我恢复数据的过程

实际上是

让这个Chunk1从这台机器

比如说这台机器还叫A吧

恢复到B那儿去

对吧 那Chunk2再恢复的时候呢

实际上我是找了另外一台机器D

那么从这台机器恢复到D上面去

那么在这种条件下面

大家可以看到

Chun1和Chunk2的恢复

它是并行进行的 对不对

如果我能够保证

这台坏掉的服务器上面

所有的Chunk

都能够并行恢复的话

那么实际上

我们刚刚算的恢复过程

是一个串行恢复的过程

那么我们都是通过

并行恢复过程的话

那么大概需要多长时间

如果是用千兆以太网的话

实际上这是64MB

除以1K的Bps

那这个可能就不到1秒钟时间

就能恢复了

所以呢

从并行恢复的角度来说

而且有master的帮助

用整个监控系统的帮助

整个系统

块服务器出现错误的时候

能够在很短的时间内

就可以恢复整个数据块

所需要的一个副本的一个数目

好 那么这是对于块服务器

出现可靠性问题的一个处理

好 那么一个更严重的问题

当然可能也就是想到

这个会比较头疼

就是

主服务器的可靠性的一个问题

那master服务器的话

因为它保存的所有的数据

第一点它都保存在内存里面

那么在这种情况下的话

在内存里面的数据一旦掉电

所有数据就丢了

这个肯定是不行的

所以呢 在master服务器里面

第一个需要处理的手段就是

我不光在内存里面

保存我的数据

我要把所有的在原数据

这方面的操作

那读的操作我不管

读的操作因为不影响

整个原数据的一个内容

那对于写操作来说

我都按照日志的方式

保存到硬盘当中去

那么至于

为什么要按照日志的方式

我们在之前的内容已经讲过了

这样的话

能够充分利用磁盘的带宽

拿到日志之后呢

可以很快地将日志放到硬盘里面

这样的话

我在恢复的时候怎么办呢

我在恢复的时候

就是要在硬盘里面

把所有的日志在内存里面

再重新再做一遍就行了

这样的话

可以保证说我这个内存数据丢了

我这个硬盘数据

可以重新恢复过来

好 这是它现在做的第一件事情

关于主服务器可靠性的问题

那么在这里面

大家可能会看到有一个问题

就是如果我都是从0

第0号操作开始

一直恢复到我们现在可能是

第100万次的一个操作

那这个时候

整个过程会非常地长

那这时候怎么办呢

所以一般在原数据服务器里面

它会定期地做整个文件系统的

一个原数据的一个Mapshort

这是整个原数据

Mapter内存的一个内容

那么会定期地会刷到硬盘里面

这样的话

我在日志上面

那么这一部分数据

它可能反映的是

日志到这个时间的时间点

那么今后到这个时间点为止

这是最新的内存的数据

所以我在恢复的时候呢

我只需要把这一部分数据

在硬盘中的一部分数据

加上在硬盘上的这部分数据

那么这就构成了一个最新的

内存里面的原数据

这样的话

能够加快日志恢复的一个过程

那么这也是在

master服务器上做的一些工作

好 那么这是通过日志操作

能够在硬盘上

快速地恢复原数据

那么也有的同学可能会问

三个服务器

它不光内存会出错

它硬盘也会出错

在这种情况下

那数据就会丢掉了

那在这个时候怎么办呢

那么在这个时候呢

在Google文件系统里面

它用了影子服务器的方法

那么什么叫影子服务器呢

这是我的主服务器master

那在这主服务器的旁边呢

还有另外一台服务器

它那个服务器叫做Shadow

就是master的一个影子

那master上面所有做的操作

都要把操作发给影子服务器

那么影子服务器

也按照我刚才说的方法

包括记日志

包括在内存里面的操作

再操作一遍

这样的话就能够保证

在master服务器出现错误的时候

影子服务器

迅速地可以提供servers

向外提供服务

那么可以在几秒钟的时间内

让这个master的服务器的

坏掉的情况

让外界所不知道

这样的话

也能够提高这个系统的可靠性

那么也有同学会问

这个master服务器

和shadow服务器

都有可能出现错误

并且只有两台服务器

那在这个时候该怎么办

那么当然呢

有人也可以说

我可以做shadow的shadow

但是做shadow的shadow的话

这样会造成整个系统非常的复杂

那么在Google文件系统里面

它就没有必要做这件事情了

那么它会把这些

比如说我们刚才已经说过了

在硬盘上面它会有日志

和它的某一个时间点的

内存的进项

它会把这两部分数据

保存在硬盘上

所以它可以多保存几个副本

比如说我在整个集群里面

保存大概四到五个副本

这样的话

如果你四到五个副本

全部坏掉了

那你的运气也太差了

所以相对来说

保存四到五个副本的话

我仍然可以在硬盘上

把整个数据给它恢复过来

那这个时候恢复过程

就Shadow服务器

恢复主服务器的过程就不太一样

那么Shadow服务器

恢复主服务器可以几秒钟完成

那这个时候我需要安装一些

新的机器

或者挑一些新的机器

从硬盘上把整个原数据

从读出来重新在内存里面构造

那么这个时间可能会需要几分钟

需要花一定的时间才能够做到

那么毕竟通过这种方式的话

毕竟两台服务器

一个master 一个shadow

坏掉的概率还是非常小的

那么即使坏掉的话

我也有后备的手段

去做这种工作

那么这些手段

包括日志 包括shadow服务器

包括将服务器

大数据系统基础课程列表:

1. 绪论

-授课视频

--什么是大数据

--大数据典型应用

--大数据的特点

--大数据技术体系

--大数据生态系统

--大数据技术挑战

--课程内容

-1. 绪论--Quiz 1

2.云计算

-授课视频

--2.1大数据和云计算关系概述

--2.2并行化理念

--2.3规模经济理念

--2.4从仓库规模计算机到云

--2.5云计算商业模式概述

--2.6云计算带来的价值

--2.7云计算的分类

--2.8虚拟化技术概述

--2.9计算虚拟化

--2.10网络虚拟化:基础

--2.11网络虚拟化:软件定义网络

--2.12软件定义网络实现

--2.13存储虚拟化:用户接口

--2.14存储虚拟化:分布式存储实现方式

--2.15虚拟化技术总结

--2.16OPENSTACK

--2.17云计算小结

-2.云计算--Quiz 2

3.文件存储

-授课视频

--Video

--Video

--Video

--Video

--Video

--Video

--Video

--Video

--Video

--Video

--Video

--Video

--Video

--Video

--Video

--Video

-3.文件存储--Quiz3

4. 处理框架

-授课视频

--4.1大数据的处理框架

--4.2MapReduce编程模型

--MapReduce执行过程

--4.4MapReduce数据流

--4.5MapReduce性能优化与容错

--4.6Hadoop

--4.7MapReduce总结

--4.8Pig Latin

--4.9Pig Latin语法

--4.10Pig Latin 嵌套数据类型

--4.11Pig Latin 实现与优化

--Pig Latin 实现与优化(2)

--4.13类似框架

--4.14章节总结

-4. 处理框架--Quiz4

5.内存计算

-授课视频

--5.1内存计算概述

--5.2并行计算挑战

--5.3并行计算的局限性

--5.4大数据处理并行系统

--5.5内存计算需求

--5.6MapReduce文件传递数据

--5.7内存计算的可行性

--5.8内存层次的延迟

--5.9内存计算实例-spark

--5.10SPARK-RDD

--5.11大数据并行系统

--5.12Spark编程接口

--5.13Spark编程实例——Log挖掘

--5.14Spark编程实例——WorkCount

--5.15Spark实现技术

--5.16复杂的DAG示例

--5.17RDD性能的提高

--5.18Spark应用和生态环境

--5.19Spark的局限性

-5.内存计算--Quiz5

6. NoSQL

-授课视频

--NoSQL与Cassandra

--数据模型、接口、语言

--系统架构与Gossip协议

--一致性哈希与数据分区

--数据副本及一致性

--节点本地数据存储

-6. NoSQL--Quiz6

7. 流计算

-授课视屏

--Video

--Video

--Video

--Video

--Video

--Video

--Video

--Video

--Video

--Video

-7. 流计算--Quiz7

Video笔记与讨论

也许你还感兴趣的课程:

© 柠檬大学-慕课导航 课程版权归原始院校所有,
本网站仅通过互联网进行慕课课程索引,不提供在线课程学习和视频,请同学们点击报名到课程提供网站进行学习。