大数据存储之分布式文件系统(一)

时间:2024-02-25 11:40:26

1.Google文件系统(GFS)


使用一堆便宜的商用计算机支撑大规模数据处理。

GFSClient: 应用程序的訪问接口

Master(主控server):管理节逻辑上仅仅有一个(另一台“影子server“,在主控server失效时提供元数据,但并非完整的热备server),保存系统的元数据,负责整个文件系统的管理。

Chunk Server(数据库server):负责详细的存储工作,数据以文件的形式存储在Chunk Server上;对应GFSclient的读写请求。


总体架构:


读取数据的流程:

应用开发人员提交读数据请求: 读取文件file,从某个位置P開始。读出大小为L的数据。

GFS系统收到这样的请求后。在内部做转换,由于Chunk大小固定,所以从位置P和大小L能够推算出要读的数据位于file的第几个chunk,即请求被转换为<文件file,Chunk序列号>的形式。

随后,GFS系统将这个请求发送给主控server,由于主控server保存了一些管理信息,通过主控server能够知道要读的数据在哪台Chunkserver上,同一时候把Chunk序号转化为系统内唯一的Chunk编号,把这两个信息传回到GFSclient。

GFS和对应的Chunkserver建立联系。发送要读取的Chunk编号和读取范围。Chunkserver接到请求后把请求数据发送给GFSclient。


採用这样的主从结构的优劣:

优点:管理相对简单

坏处:非常多服务请求都经过主控server,easy成为整个系统的瓶颈。可能存在单点失效问题。


PS:要做数据冗余,每一个Chunk多个备份在不同的Chunkserver上。


写数据的流程:

GFS系统必须把这个写操作应用到Chunk的全部备份。为了方便管理,GFS从多个相互备份的Chunk中选出一个主备份,其它的作为次级备份,由主备份决定次级备份的数据写入顺序。

GFSclient首先和主控server通信,获知哪些Chunkserver存储了要写入的Chunk,包含主备份和其它的次级备份的地址数据,然后GFSclient将要写入的数据推送给全部的备份Chunk,备份Chunk首先将这些待写入的数据放在缓存中,然后通知GFSclient是否接受成功。假设全部的备份都接受数据成功。GFSclient通知主备份可运行写入操作,主备份将自己缓存的数据写入Chunk。通知次级备份依照指定顺序写入数据。次级备份写完后答复主备份写入成功。主备份才会通知GFSclient这次写操作成功完毕。假设待写入的数据跨Chunk或者须要多个Chunk才干容纳,client自己主动将其分解为多个写操作。


Colossus

Google下一代GFS分布式文件系统,几个改进例如以下:
将单一主控server改造为多主控server构成的集群。将全部管理数据进行数据分片后分配到不同的主控server上。

Chunk数据的多个备份尽管添加了系统可用性。可是付出了很多其它的存储成本,一种常见的折中方案是採用纠删码算法。
Colossus的client能够依据需求指定数据存放地点。


PS:

纠删码算法的基本原理例如以下:  

给定n个数据块d1, d2,..., dn,n和一个正整数m。 RS依据n个数据块生成m个校验块。 c1, c2,..., cm。  对于随意的n和m,  从n个原始数据块和m 个校验块中任取n块就能解码出原始数据, 即RS最多容忍m个数据块或者校验块同一时候丢失(纠删码仅仅能容忍数据丢失。无法容忍数据篡改,纠删码正是得名与此)。 


关于纠删码的很多其它细节能够參考:http://blog.sina.com.cn/s/blog_3fe961ae0102vpxu.html

关于数据可靠性:对冷数据进行编码冗余,对热数据进行副本冗余。(前者降低存储成本,后者降低计算成本,应该非常好理解)



2.HDFS


是Hadoop中的大规模分布式文件系统,在整个架构上与GFS大致同样,更简化,比方同一时刻仅仅同意一个client对文件进行追加写操作。

它具有下面几个特点:

1)适合存储很大的文件

2)适合流式数据读取。即适合“仅仅写一次,读多次”的数据处理模式

3)适合部署在便宜的机器上

但HDFS不适合下面场景(不论什么东西都要分两面看。仅仅有适合自己业务的技术才是真正的好技术):

1)不适合存储大量的小文件。由于受Namenode内存限制大小

2)不适合实时数据读取,高吞吐量和实时性是相悖的,HDFS选择前者

3)不适合须要常常改动数据的场景



总体架构



由NameNode,DataNode。Secondary NameNode以及client组成。


NameNode
负责管理整个分布式文件系统的元数据,包含文件文件夹树结构、文件到数据块的映射关系、Block副本及其存储位置等各种管理数据。

这些数据保存在内存中。

还负责DataNode的状态监控。通过心跳来传递管理信息和数据信息。


Secondary NameNode

职责并不是是NameNode的热备机,而是定期从NameNode拉取fsimage(内存命名空间元数据在外存的镜像文件))和editlog文件(各种元数据操作的write-ahead-log
文件。在体现到内存数据变化前先把操作记录到此文件防止数据丢失)并对这两个文件进行合并。形成新的fsimage文件并传回给NameNode,以减轻NameNode的工作压力。

DataNode

类似于GFS的Chunkserver。负责数据块的实际存储和读写。

client

与GFSclient类似。HDFSclient和NameNode联系获取所需读/写文件的元数据,实际的数据读写都是和DataNode直接通信完毕的。

HA方案

主控server由Active NameNode和Standby NameNode一主一从两台server构成,ANN是当前响应client请求的server,SNN是冷备份或者热备份机。

为了使SNN成为热备份机,SNN的全部元数据须要与ANN元数据保持一致。通过下面两点来保证这一要求:

1.使用第三方共享存储来保存文件夹文件等命名空间元数据。

本质是把NN的单点失效问题转换成第三方存储的单点失效问题,可是第三方存储自带非常强的冗余和容错机制。所以可靠性较强。

2.全部DataNode同一时候把心跳信息发送给ANN和SNN。

增加独立于NN之外的故障切换控制器,在ANN故障时。选举SNN为主控server。在Hadoop系统刚刚启动时,两台都是SNN。通过选举使得某台成为ANN。

由此要增加隔离措施防止脑裂现象(即同一时候有多个活跃的主控server):
1)同一时刻上仅仅有一个NN可以写入第三方共享存储
2)仅仅有一个NN发出与管理数据副本有关的删除命令
3)同一时刻是有一个NN可以对client请求发出正确对应

解决方式:

QJM:
利用Paxos协议。在2F+1GE JournalNode中存储NN的editlog,每次写入操作假设有F台server返回成功就可以觉得成功写入。

最多能够容忍F个Journal Node同一时候故障。


NameNode联盟

核心思想:把一个大的命名空间分割为若干子命名空间,每一个子命名空间由单独的NN负责管理,NN之间独立,全部DataNode被共享。

DataNode和子命名空间之间由数据块管理层建立映射关系,数据块管理层由若干数据块池构成。每一个数据块唯一属于某个固定的数据块池,一个子命名空间能够相应多个数据块池。


ps:HDFS看的云里雾里。以后研究Hadoop的时候再好好回想吧。