标签：大数据 hadoop gfs 架构 数据
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和子命名空间之间由数据块管理层建立映射关系，数据块管理层由若干数据块池构成。每个数据块唯一属于某个固定的数据块池，一个子命名空间可以对应多个数据块池。
ps：HDFS看的云里雾里，以后研究Hadoop的时候再好好回顾吧。
版权声明：本文为博主原创文章，未经博主允许不得转载。
大数据存储之分布式文件系统（一）
标签：大数据 hadoop gfs 架构 数据
原文地址：http://blog.csdn.net/u012422829/article/details/47398549
