Google 分布式系统与Hadoop
名称 | Hadoop | |
分布式文件系统 |
Google file system(GFS) |
Hadoop Distributed File System(HDFS ) |
分布式计算 |
Google MapReduce |
MapReduce |
分布式存储 |
Google BigTable |
HBase |
分布式协同服务 |
Google Chubby |
ZooKeeper |
数据仓库工具 |
Hive |
|
其他 |
Avro,Hadoop Common,Pig,Chukwa,CloudBASE等 |
分布式文件系统术语对比
术语 |
GFS中的术语 |
HDFS中的术语 |
术语解释 |
主控服务器 |
Master |
NameNode |
整个文件系统的大脑,它提供整个文件系统的目录信息,并且管理各个数据服务器。 |
数据服务器 |
Chunk Server |
DataNode |
分布式文件系统中的每一个文件,都被切分成若干个数据块,每一个数据块都被存储在不同的服务器上,此服务器称之为数据服务器。 |
数据块 |
Chunk |
Block |
每个文件都会被切分成若干个块,每一块都有连续的一段文件内容,是存储的基恩单位,在这里统一称做数据块。 |
数据包 |
无
|
Packet |
客户端写文件的时候,不是一个字节一个字节写入文件系统的,而是累计到一定数量后,往文件系统中写入一次,每发送一次的数据,都称为一个数据包。 |
传输块 |
无 |
Chunk |
在每一个数据包中,都会将数据切成更小的块,每一个块配上一个奇偶校验码,这样的块,就是传输块。 |
备份主控服务器 |
无 |
SecondaryNameNode |
备用的主控服务器,在身后默默的拉取着主控服务器 的日志,等待主控服务器牺牲后被扶正。 |
Hadoop服务器的基本架构、各服务所使用的协议、调用方向、以及协议中的基本内容
Hadoop 服务器简介
分布式文件系统不是将这些数据放在一块磁盘上,由上层操作系统来管理。而是存放在一个服务器集群上,由集群中的服务器,各尽其责,通力合作,提供整个文件系统的服务。其中重要的服务器包括:主控服务器(Master/NameNode),数据服务器(ChunkServer/DataNode) ,和客户服务器。HDFS和GFS都是按照这个架构模式搭建的。其中设计的最核心内容是:文件的目录结构独立存储在一个主控服务器上,而具体文件数据,拆分成若干块,冗余的存放在不同的数据服务器上。存储目录结构的主控服务器,在GFS中称为Master,在HDFS中称为NameNode。
每一个文件的具体数据,被切分成若干个数据块,冗余的存放在数据服务器。通常的配置,每一个数据块的大小为64M,在三个数据服务器上冗余存放,数据服务器其主要的工作模式就是定期向主控服务器汇报其状况,然后等待并处理命令,更快更安全的存放好数据。整个分布式文件系统还有一个重要角色是客户端。它不和主控服务和数据服务一样,在一个独立的进程中提供服务,它只是以一个类库(包)的模式存在,为用户提供了文件读写、目录操作等APIs。
分布式文件系统
uFault-tolerant, 容错性
uRun on commodity hardware,在通用的机器上运行
uScalable 可扩缩的
分布式文件系统
数据分布
一个文件系统中,最重要的数据,其实就是整个文件系统的目录结构和具体每个文件的数据。具体的文件数据被切分成数据块,存放在数据服务器上。每一个文件数据块,在数据服务器上都表征为出双入队的一对文件(普通的Linux文件),一个是数据文件,一个是附加信息的元文件,这对文件简称为数据块文件。数据块文件存放在数据目录下,它有一个名为current的根目录,然后里面有若干个数据块文件和从dir0-dir63的最多64个的子目录,子目录内部结构等同于current目录,依次类推。
主控服务器的数据量不大,但逻辑更为复杂。主控服务器主要有三类数据:文件系统的目录结构数据,各个文件的分块信息,数据块的位置信息(数据块放置在哪些数据服务器上)。在GFS和HDFS的架构中,只有文件的目录结构和分块信息才会被持久化到本地磁盘上,而数据块的位置信息则是通过动态汇总过来的,仅仅存活在内存数据结构中,机器宕机数据就消失了。每一个数据服务器启动后,都会向主控服务器发送注册消息,将其上数据块的状况都告知于主控服务器。
服务器间协议
在Hadoop的实现中,部署了一套RPC机制,以此来实现各服务间的通信协议。在Hadoop中,每一对服务器间的通信协议,都定义成为一个接口。服务端的类实现该接口,并且建立RPC服务,监听相关的接口,在独立的线程处理RPC请求。客户端则可以实例化一个该接口的代理对象,调用该接口的相应方法,执行一次同步的通信,传入相应参数,接收相应的返回值。基于此RPC的通信模式,是一个消息拉取的流程,RPC服务器等待RPC客户端的调用,而不会先发制人主动把相关信息推送到RPC客户端去。
数据结构
NameNode
–存贮HDFS的元数据(metadata)
–管理文件系统的命名空间(namespace)
创建、删除、移动、重命名文件和文件夹
–接收从DataNode来的Heartbeat和Blockreport
DataNode
–存贮数据块
–执行从Namenode来的文件操作命令
–定时向NameNode发送Heartbeat和Blockreport
分布式计算(Map/Reduce)
uJobtraker(Master)
–接收任务(job)的提交
–提供任务的监控(monitoring)和控制(control)
–把job划分成多个tasks,交给Tasktracker执行,并管理这些tasks的执行
uTasktracker(Worker)
–管理单个task的map任务和reduce任务的执行
分布式存储
Client
1包含访问hbase的接口,client维护着一些cache来加快对hbase的访问,比如regione的位置信息。
Master
1.为Region server分配region
2.负责region server的负载均衡
3.发现失效的region server并重新分配其上的region
4.GFS上的垃圾文件回收
5.处理schema更新请求
Region Server
1.Region server维护Master分配给它的region,处理对这些region的IO请求
2.Region server负责切分在运行过程中变得过大的region
Zookeeper
1.保证任何时候,集群中只有一个master
2.存贮所有Region的寻址入口。
3.实时监控Region Server的状态,将Region server(管理区域服务器)的上线和下线信息实时通知给Master
4.存储Hbase的schema,包括有哪些table,每个table有哪些column family
ZooKeeper 是Google的Chubby一个开源的实现。它是一个针对大型分布式系统的可靠协调系统,提供的功能包括:配置维护、名字服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。