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的特点：
  

1. 大文件和大数据块：数据文件的大小普遍在GB级别，而且其每个数据块默认大小为64MB，这样做的好处是减少了元数据的大小，能使Master节 点能够非常方便地将元数据放置在内存中以提升访问效率。
2. 操作以添加为主：因为文件很少被删减或者覆盖，通常只是进行添加或者读取操作，这样能充分考虑到硬盘线性吞吐量大和随机读写慢的特点。
3. 支持容错：首先，虽然当时为了设计方便，采用了单Master的方案，但是整个系统会保证每个Master都会有其相对应的复制品，以便于在 Master节点出现问题时进行切换。其次，在Chunk层，GFS已经在设计上将节点失败视为常态，所以能非常好地处理Chunk节点失效的问题。
4. 高吞吐量：虽然其单个节点的性能无论是从吞吐量还是延迟都很普通，但因为其支持上千的节点，所以总的数据吞吐量是非常惊人的。
5. 保护数据：首先，文件被分割成固定尺寸的数据块以便于保存，而且每个数据块都会被系统复制三份。
6. 扩展能力强：因为元数据偏小，使得一个Master节点能控制上千个存数据的Chunk节点。
7. 支持压缩：对于那些稍旧的文件，可以通过对它进行压缩，来节省硬盘空间，并且压缩率非常惊人，有时甚至接近90%。
8. 用户空间：虽然在用户空间运行在运行效率方面稍差，但是更便于开发和测试，还有能更好利用Linux的自带的一些POSIX API。

2）BigTable的介绍：

由于在Google的数据中心存储PB级以上的非关系型数据时候，比如网页和地理数据等，为了更好地存储和利用这些数据，Google开发了一套数 据库系统，名为“BigTable”。BigTable不是一个关系型的数据库，它也不支持关联（join）等高级SQL操作，取而代之的是多级映射的数 据结构，并是一种面向大规模处理、容错性强的自我管理系统，拥有TB级的内存和PB级的存储能力，使用结构化的文件来存储数据，并每秒可以处理数百万的读 写操作。

什么是多级映射的数据结构呢？就是一个稀疏的，多维的，排序的Map，每个Cell由行关键字，列关键字和时间戳三维定位．Cell的内容是一个不 解释的字符串，比如下表存储每个网站的内容与被其他网站的反向连接的文本。 反向的URL com.cnn.www是这行的关键字；contents列存储网页内容，每个内容有一个时间戳，因为有两个反向连接，所以archor的Column Family有两列：anchor: cnnsi.com和anchhor:my.look.ca。Column Family这个概念，使得表可以轻松地横向扩展。下面是它具体的数据模型图：

 

BigTable数据模型图

在结构上，首先，BigTable基于GFS分布式文件系统和Chubby分布式锁服务。其次BigTable也分为两部分：其一是Master节 点，用来处理元数据相关的操作并支持负载均衡。其二是tablet节点，主要用于存储数据库的分片tablet，并提供相应的数据访问，同时tablet 是基于名为SSTable的格式，对压缩有很好的支持。

 BigTable架构图

BigTable正在为Google六十多种产品和项目提供存储和获取结构化数据的支撑平台，其中包括有Google Print， Orkut，Google Maps，Google Earth和Blogger等，而且Google至少运行着500个BigTable集群。随着Google内部服务对需求的不断提高和技术的不断地发展，导致原先的BigTable已经无法满足用户的需求，而 Google也正在开发下一代BigTable，名为“Spanner（扳手）”，它主要有下面这些BigTable所无法支持的特性：

1. 支持多种数据结构，比如table，familie，group和coprocessor等。
2. 基于分层目录和行的细粒度的复制和权限管理。
3. 支持跨数据中心的强一致性和弱一致性控制。
4. 基于Paxos算法的强一致性副本同步，并支持分布式事务。
5. 提供许多自动化操作。
6. 强大的扩展能力，能支持百万台服务器级别的集群。
7. 用户可以自定义诸如延迟和复制次数等重要参数以适应不同的需求。

3）Percolator
Google在抓取网页的同时进行索引更新，意味着在新文档不断加入时，需要对已有的总文档库进行持续地更新。这是通过小规模、独立的变换实现海量数据转换任务的一个 典型范例。现有的技术基础平台恰恰不能胜任这样的任务：传统DBMS无法满足存储量和吞吐率的需求，而MapReduce和其它批处理系统无法逐个处理小规模更新，因为它们必须依赖于创建大量的批处理任务才能获得高效率。因此，单独的MapReduce和BigTable都不能满足它的需求，因此Google选择在BigTable之上建立一个Transaction和Notification的机制，实现快速更新索引数据的需求。
解决此问题的关键是优化增量数据的处理方式。Percolator的一个关键设计理念是：提供对库中文档的随机访问，以实现对单个文档的处理，从而避免了像MapReduce那样对文档全集进行处理。Percolator通过“SnapShot Isolation”实现了遵从ACID的跨行及跨表事务，从而满足多线程在多台服务器上对文档库进行转换操作的需求。Percolator还提供了“观察者（observer）”机制，在用户指定的列发生更新之后，这些观察者会被系统触发，以帮助开发者追踪计算过程所处的状态。

需求驱动了系统架构的变化，但是在系统追求高的资源利用率、高的作业吞吐率、较低的延迟等方面上没有终点.