首页hadoop › 大数据存储之分布式文件系统

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

1.Google文件系统(GFS)

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

GFSClient: 应用程序的访问接口

Master(主控服务器):管理节点,在逻辑上只有一个(还有一台“影子服务器“,在主控服务器失效时提供元数据,但并不是完整的热备服务器),保存系统的元数据,负责整个文件系统的管理。

Chunk Server(数据库服务器):负责具体的存储工作,数据以文件的形式存储在Chunk Server上;相应GFS客户端的读写请求。

整体架构:

读取数据的流程:

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

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

随后,GFS系统将这个请求发送给主控服务器,因为主控服务器保存了一些管理信息,通过主控服务器可以知道要读的数据在哪台Chunk服务器上,同时把Chunk序号转化为系统内唯一的Chunk编号,把这两个信息传回到GFS客户端。

GFS和相应的Chunk服务器建立联系,发送要读取的Chunk编号和读取范围,Chunk服务器接到请求后把请求数据发送给GFS客户端。

采用这种主从结构的优劣:

好处:管理相对简单

坏处:很多服务请求都经过主控服务器,容易成为整个系统的瓶颈;可能存在单点失效问题。

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

写数据的流程:

GFS系统必须把这个写操作应用到Chunk的所有备份,为了方便管理,GFS从多个相互备份的Chunk中选出一个主备份,其他的作为次级备份,由主备份决定次级备份的数据写入顺序。
GFS客户端首先和主控服务器通信,获知哪些Chunk服务器存储了要写入的Chunk,包括主备份和其他的次级备份的地址数据,然后GFS客 户端将要写入的数据推送给所有的备份Chunk,备份Chunk首先将这些待写入的数据放在缓存中,然后通知GFS客户端是否接受成功,如果所有的备份都 接受数据成功,GFS客户端通知主备份可执行写入操作,主备份将自己缓存的数据写入Chunk,通知次级备份按照指定顺序写入数据,次级备份写完后答复主 备份写入成功,主备份才会通知GFS客户端这次写操作成功完成。如果待写入的数据跨Chunk或者需要多个Chunk才能容纳,客户端自动将其分解为多个 写操作。

Colossus

Google下一代GFS分布式文件系统,几个改进如下:
将单一主控服务器改造为多主控服务器构成的集群,将所有管理数据进行数据分片后分配到不同的主控服务器上。
Chunk数据的多个备份虽然增加了系统可用性,但是付出了更多的存储成本,一种常见的折中方案是采用纠删码算法。
Colossus的客户端可以根据需求指定数据存放地点。
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大致相同,更简化,比如同一时刻只允许一个客户端对文件进行追加写操作。

它具有以下几个特点:

1)适合存储非常大的文件

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

3)适合部署在廉价的机器上

但HDFS不适合以下场景(任何东西都要分两面看,只有适合自己业务的技术才是真正的好技术):

1)不适合存储大量的小文件,因为受Namenode内存大小限制

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

3)不适合需要经常修改数据的场景

整体架构

由NameNode,DataNode,Secondary NameNode以及客户端组成。
NameNode
负责管理整个分布式文件系统的元数据,包括文件目录树结构、文件到数据块的映射关系、Block副本及其存储位置等各种管理数据。这些数据保存在内存中。还负责DataNode的状态监控,通过心跳来传递管理信息和数据信息。
Secondary NameNode
职责并非是NameNode的热备机,而是定期从NameNode拉取fsimage(内存命名空间元数据在外存的镜像文件))和editlog文件(各种元数据操作的write-ahead-log
文件,在体现到内存数据变化前先把操作记录到此文件防止数据丢失)并对这两个文件进行合并,形成新的fsimage文件并传回给NameNode,以减轻NameNode的工作压力。
DataNode

类似于GFS的Chunk服务器,负责数据块的实际存储和读写。
客户端

与GFS客户端类似,HDFS客户端和NameNode联系获取所需读/写文件的元数据,实际的数据读写都是和DataNode直接通信完成的。

HA方案

主控服务器由Active NameNode和Standby NameNode一主一从两台服务器构成,ANN是当前响应客户端请求的服务器,SNN是冷备份或者热备份机。为了使SNN成为热备份机,SNN的所有元 数据需要与ANN元数据保持一致。通过以下两点来保证这一要求:
1.使用第三方共享存储来保存目录文件等命名空间元数据。本质是把NN的单点失效问题转换成第三方存储的单点失效问题,但是第三方存储自带很强的冗余和容错机制,所以可靠性较强。
2.所有DataNode同时把心跳信息发送给ANN和SNN。
加入独立于NN之外的故障切换控制器,在ANN故障时,选举SNN为主控服务器。在Hadoop系统刚刚启动时,两台都是SNN,通过选举使得某台成为ANN。
由此要加入隔离措施防止脑裂现象(即同时有多个活跃的主控服务器):
1)同一时刻上只有一个NN能够写入第三方共享存储
2)只有一个NN发出与管理数据副本有关的删除命令
3)同一时刻是有一个NN能够对客户端请求发出正确相应
解决方案:

QJM:
利用Paxos协议,在2F+1GE JournalNode中存储NN的editlog,每次写入操作如果有F台服务器返回成功即可认为成功写入。最多可以容忍F个Journal Node同时故障。

NameNode联盟

核心思想:把一个大的命名空间切割为若干子命名空间,每个子命名空间由单独的NN负责管理,NN之间独立,所有DataNode被共享。 DataNode和子命名空间之间由数据块管理层建立映射关系,数据块管理层由若干数据块池构成。每个数据块唯一属于某个固定的数据块池,一个子命名空间 可以对应多个数据块池。

发表评论

注意 - 你可以用以下 HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>