Video在线视频

我们介绍了这个文件系统

介绍了怎么样去

实现一个文件系统

在具体实现一个文件系统的时候

我们怎么样考虑数据处理的模式

和底层数据的

这种存储空间的分配

他们之间的这样一个关系

那么针对我们在后面的课程中

将要讲到的map-reduce

和spark等等

这种scale out的

这种数据处理的模式

实际上有一种新的文件系统

被大家提出来

叫做分布式文件系统

那么我们下面的时间

就会来看分布式文件系统

他有什么样的特征

他做了什么样的这种资源的抽象

他做了什么样的这种接口的提供

来达到一个鲁棒高效和支持特定的

这种大数据处理的

这种特征的

文件的这样一个系统的支撑

那么分布式文件系统

我们来看

他最开始的一些假设包含了哪些

第一个我们之前说到

我们认为数据是一个输入

数据是不太能够移动

不太能够轻易变化的一个资源

我们可以改变我们的程序

让我们的程序尽可能挨近数据

那么它的第一个假设

就是数据一旦存储之后

它的位置不发生变化

而是将我们的程序不断的

去靠近数据

我们的磁盘是比较慢的

这也是大数据文件系统里面的

一个假设

但磁盘一旦开始提供数据

开始有了throughput的时候

它认为是一个能够达到

一个相对不错的这样一个指标

所以随机的读取是不可取的

一定是要满足大规模

顺序的这样一个读取

有了这些假设之后

实际上一系列工业界的版本就出现了

在我们课堂里面

主要会去介绍google的分布式文件系统

GFS和支持hadoop的

分布式文件系统HDFS

那我们来看这两种文件系统

他们共同的一些假设是什么样的

首先他们要满足scale out

我们在很早以前就已经说过了

要满足scale out的特性

我们没有特别大的

非常大的一个存储的一个机器

我们是通过把一堆的小的服务器

小的磁盘连接到一块

组成了一个大的分布式文件系统

同时 我们的这些小的机器是不稳定的

有的机器可能会坏掉

有的磁盘可能会坏掉

它们之间的网络也可能会断掉

我们的分布式文件系统需要能够

处理这样的一些失败

我们整个系统的空间是非常大的

我们能够支持TB级的文件

我们能够支持PB级的整个容量

这是对空间的一个需求

文件通常是GB级别的

这样文件的一个指标

那么他们的文件的这种workloads

通常是大量的顺序的读取

然后有一定的随机的读取

但是很少去对文件进行修改

这也是能够被我们今天

大数据分析和大数据处理

任务能够接受的一个要求

而这个要求

其实在后面大家会发现

直接决定了今天

分布式文件系统的一个组织结构

同时 他们要能提供比较大的带宽

为什么会有带宽

因为我们会有成百上千台服务器

组合在一起支撑了

一个大的分布式文件系统

他们之间会需要有比较大的

这样一个数据的交换

在大部分的情况下

实际上这种带宽的要求

要远远高过启动的延迟

或者是节点到节点之间的

延迟的要求

分布式文件系统

它的一些针对刚刚的

这样的一些假设

它的一些目标是什么

我们来看第一个

它要有location transparency的一个特征

位置透明

也就是说对于用户来说

他并不关心我放的一个文件

它的每一个byte

每一个数据存到了哪个磁盘上

只要你系统告诉我已经存好了

它是存在我目前工作的这台服务器

还是远端的另外一台服务器

其实用户并不关心

只要能够存下来不丢就可以了

第二 它要能够支持并发的任务

因为在今天工业界

在使用分布式文件系统的时候

用户的数量可以达到上千上万

每一个用户实际上

可能是一个长期运行的进程

或者是一个批处理的任务

它会有非常大的

这样一个并发的需求

能够容忍失败

我们刚刚已经提到了

系统的各个模块可能会失败

失败之后

我的数据要不能丢

我正在发生的传输

要能够依然保证一定的带宽

这是最基本的一个要求

它能够支持各种各样的硬件设备

网络环境

以及各种各样的底层的存储和计算资源的配置

不同的服务器应该

能够组合在一起

不同的协议应该能够

在这里面能够工作

那么这对上层的这个抽象提出了

比较大的这样一个挑战

那么最后一个是scalability

那么这是最基本的一个保证

因为我们希望我们的系统

能够不断的随着业务的扩展

去支撑增大的这种数据规模

那么可扩展性是必须的

它体现在分布式文件系统当中

就是当我们有了更多的钱

可以购买更多的服务器的时候

它应该能够达到一个更大的带宽

更大的容量

以及更好的这样一个容错的保证

那么为了实现刚刚的这样一些目标

那么在分布式文件系统最开始的

这帮工程人员的设计当中

他们选取了这样的一些设计的选择

第一 我们不再按文件作为单位

去存储数据

而是把文件划分成一系列的

chunk或者block

那么这些chunk

为了支撑GB级的这样一个文件

或者TB级的文件

那么这个chunk通常也是比较大的

通常是几十兆

或者是几百兆的一个空间

同时它为了保证对失败的一个抵抗

那么对数据

进行了一个冗余的放置

那么在今天的分布式文件系统中

每一个chunk

每一个数据块实际上会被分散

在系统中的不同的服务器上

那么我们在后续会给大家介绍

这种分配是怎么做到的

那么他们是怎么样解决

系统的失败的

同时我们使用了中心的节点

来进行顺序化的操作的

这样一个管理

我们在之前也提到

假设我们不管理这种

各个工作节点的话

他们可能会对稀缺资源进行竞争

最终导致一些系统性能的下降

或者是严重的死锁

那么我们通过一个中心的节点

对分布式文件系统进行了有效的

这种稀缺资源的管理

那么大家可以想象在分布式文件系统当中

对于名字空间这种需要全局统一

全局一致的这样一个信息

实际上是由中心的节点

来进行管理的责无旁贷

那么在分布式文件系统当中

通常不进行数据的一个缓存

那么在单机文件系统当中

为了提高磁盘的效率

实际上在磁盘和进程之间

可能会有缓存的这样一个中间件

那么缓存会把最近读取的一些数据

进行内存当中的复制

然后当对相同的数据

进行访问的时候

可以达到比较快的一个响应

那么在分布式文件系统当中

由于我们的任务很多

我们的用户很多

同时我们的数据量也太大

那么缓存它带来的好处

可能就没有单机文件系统当中那么大

所以缓存是在最开始的设计中

没有被考虑的

然后简化它的这个操作的API

那么在分布式文件系统当中

目前的这个API实际上

被简化到有读有写

然后有一些简单的删除

那么其他的功能实际上并不会有

我们在单机文件系统中那么高 那么多

比如说一些权限的控制

一些属性一些复杂的这种关联结构

圈状的结构

实际上在分布式文件系统当中

就不会被非常有效的支持

因为它为了使自己的操作尽可能简单

对某一些这种比较复杂的结构

进行了有意的删去

那么我们这个后面会介绍了

GFS它的一个架构为例

来给大家看看今天的

分布式文件系统

它的这种体系结构

它的架构

大概是一个什么样的样子

首先文件被分成了大概64兆的

这样一个chunk

在GFS当中文件被

分成了这个块被称为chunk

那么这些chunk 通常会被复制到三个

这个replicas上 就3个服务器上进行保存

当其中某一个服务器坏了

这个系统依然可以从

另外两个服务器拿到数据的副本

来恢复这个数据

那么支持的文件空间是64位

所以可以支持一个相对比较大的

一个文件的名字空间

可以存储相对比较多的

这样一个数据

那么对于这个底层的

工作节点来说

它们存储chunk

利用了单机上的文件系统

每一个chunk

会不会组织成一个单机上的文件

这是GFS它的一个基本的选择

我们来看GFX的一个架构

GFX它的架构

实际上包含了中心的这个nameNode

维护了整个系统的名字空间

然后也维护了每个chunk

在各个服务器上保存的位置

然后有底下存储具体数据的这些data node

存储了每一个chunk

每个chunk被组织成了单一的文件

那么在这个里面

还会有一个客户端用户

他会执行比较复杂的操作

比如说和名字空间先通信

进行数据的发现

然后进行数据的读写和data node的通信

那么后面我们会对这部分流程

进行一个详细的介绍