Hadoop-MapReduce后时代

随着数据规模的扩展，传统的数据库朝着分布式文件系统+上层数据管理的方向发展。在这其中，Google的技术引领了整个技术的前进和发展。Google底层使用的是GFS，分布式文件系统保证了数据规模和机器规模的可扩展性，这对于一个海量数据处理系统来讲，可扩展性意味着体系架构的稳定性。

这种版本的分布式文件系统，和HDFS的设计原理非常类似，它也是由Master(元数据服务器)，ChunkServer（类似于DataNode）。这种设计有如下的好处：

1）解决了大数据存储的问题。数据块的大小默认是64mb。

2）通过备份提高数据的可靠性。

但是，经过Google和Hadoop验证，这种模型能很好地支持离线作业的执行，但是对于实时性要求比较高的应用而言，显然还有很大的问题。

1）文件规模扩大之后Master的单点故障问题(单个NameNode存在性能瓶颈)

2）ChunkServer小数据量的文件的读写性能没有优势。(小数据读取与顺序读取提高disk IO相互矛盾)

Google的Percolator开启了MapReduce处理的后时代，后时代的特征是也是分布式文件系统(GFS2-Colossus)+ BigTable + Caffeine, MapReduce后时代不代表MapReduce没有用武之地，而是海量数据处理的模式不再被MapReduce编程模型所禁锢，MapReduce编程模型也不再是传统意义上的Mapper-Reducer，它将被赋予海量数据离线批处理的代名词，模型将更灵活，新的应用更加丰富和完善。然而，技术总是在需求的驱动下在不断进步的，当前移动互联网LBS、广告推荐系统等多种应用的驱动下，谁能使得数据处理更加迅速，就更容易抓到商机和用户。

在这一点上，Google又一次站在了前面。它们提出的Caffeine系统，不仅是我们看到的实时搜索，而是它底层所蕴涵的技术架构的优势。

GFS+BigTable+Percolator的介绍

1）GFS介绍

首先，介绍它的架构，GFS主要分为两类节点：

Master节点：主要存储与数据文件相关的元数据，而不是Chunk（数据块）。元数据包括一个能将64位标签映射到数据块的位置及其组成文件的表格，数据块副本位置和哪个进程正在读写特定的数据块等。还有Master节点会周期性地接收从每个Chunk节点来的更新（”Heart- beat”）来让元数据保持最新状态。

Chunk节点：顾名思义，肯定用来存储Chunk，数据文件通过被分割为每个默认大小为64MB的Chunk的方式存储，而且每个Chunk有唯一一个64位标签，并且每个Chunk都会在整个分布式系统被复制多次，默认为3次。

GFS的特点：

大文件和大数据块：数据文件的大小普遍在GB级别，而且其每个数据块默认大小为64MB，这样做的好处是减少了元数据的大小，能使Master节点能够非常方便地将元数据放置在内存中以提升访问效率。

操作以添加为主：因为文件很少被删减或者覆盖，通常只是进行添加或者读取操作，这样能充分考虑到硬盘线性吞吐量大和随机读写慢的特点。

支持容错：首先，虽然当时为了设计方便，采用了单Master的方案，但是整个系统会保证每个Master都会有其相对应的复制品，以便于在 Master节点出现问题时进行切换。其次，在Chunk层，GFS已经在设计上将节点失败视为常态，所以能非常好地处理Chunk节点失效的问题。

高吞吐量：虽然其单个节点的性能无论是从吞吐量还是延迟都很普通，但因为其支持上千的节点，所以总的数据吞吐量是非常惊人的。

保护数据：首先，文件被分割成固定尺寸的数据块以便于保存，而且每个数据块都会被系统复制三份。

扩展能力强：因为元数据偏小，使得一个Master节点能控制上千个存数据的Chunk节点。

支持压缩：对于那些稍旧的文件，可以通过对它进行压缩，来节省硬盘空间，并且压缩率非常惊人，有时甚至接近90%。

用户空间：虽然在用户空间运行在运行效率方面稍差，但是更便于开发和测试，还有能更好利用Linux的自带的一些POSIX API。 2）BigTable的介绍：