【IT168 技术】在Google数据中心会有大规模数据需要处理，比如被网络爬虫(Web Crawler)抓取的大量网页等。由于这些数据很多都是PB级别，导致处理工作不得不尽可能的并行化，而Google为了解决这个问题，引入了MapReduce这个分布式处理框架。

　　技术概览

　　MapReduce本身源自于函数式语言，主要通过"Map(映射)"和"Reduce(化简)"这两个步骤来并行处理大规模的数据集。首先，Map会先对由很多独立元素组成的逻辑列表中的每一个元素进行指定的操作，且原始列表不会被更改，会创建多个新的列表来保存Map的处理结果。也就意味着，Map操作是高度并行的。当Map工作完成之后，系统会接着对新生成的多个列表进行清理(Shuffle)和排序，之后，会这些新创建的列表进行Reduce操作，也就是对一个列表中的元素根据Key值进行适当的合并。下图为MapReduce的运行机制：

▲

　　图1. MapReduce的运行机制

　　接下来，将根据上图来举一个MapReduce的例子来帮助大家理解：比如，通过搜索引擎的爬虫(Spider)将海量的Web页面从互联网中抓取到本地的分布式文件系统中，然后索引系统将会对存储在这个分布式文件系统中海量的Web页面进行平行的Map处理，生成多个Key为URL，Value为html页面的键值对(Key-Value Map)，接着，系统会对这些刚生成的键值对进行Shuffle(清理)，之后，系统会通过Reduce操作来根据相同的key值(也就是URL)合并这些键值对。

　　优劣点

　　谈到MapReduce的优点，主要有两个方面：其一，通过MapReduce这个分布式处理框架，不仅能用于处理大规模数据，而且能将很多繁琐的细节隐藏起来，比如，自动并行化、负载均衡和灾备管理等，这样将极大地简化程序员的开发工作;其二，MapReduce的伸缩性非常好，也就是说，每增加一台服务器，其就能将差不多的计算能力接入到集群中，而过去的大多数分布式处理框架，在伸缩性方面都与MapReduce相差甚远。而 MapReduce最大的不足则在于，其不适应实时应用的需求，所以在Google最新的实时性很强的Caffeine搜索引擎中，MapReduce的主导地位已经被可用于实时处理Percolator系统所代替，其具体细节，将在本系列接下来的文章中进行介绍。

　　相关产品

　　除了Google内部使用的MapReduce之外，还有，由Lucene之父Doug Cutting领衔的Yahoo团队开发，Apache管理的MapReduce的开源版本Hadoop，而且一经推出，就受到业界极大的欢迎，并且衍生出HDFS、ZooKeeper、Hbase、Hive和Pig等系列产品。

　　实际用例

　　在实际的工作环境中，MapReduce这套分布式处理框架常用于分布式grep、分布式排序、Web访问日志分析、反向索引构建、文档聚类、机器学习、数据分析、基于统计的机器翻译和生成整个搜索引擎的索引等大规模数据处理工作，并且已经在很多国内知名的互联网公司内部得到极大地应用，比如百度和淘宝。

　　最后，如果大家对MapReduce感兴趣的话，可以到Hadoop的官方站点上下载并试用。

　　由于搜索引擎需要处理海量的数据，所以Google的两位创始人Larry Page和Sergey Brin在创业初期设计一套名为“BigFiles”的文件系统，而GFS(全称为“Google File System”)这套分布式文件系统则是“BigFiles”的延续。

　　技术概览

　　首先，介绍它的架构，GFS主要分为两类节点：其一是Master节点，其主要存储与数据文件相关的元数据，而不是Chunk(数据块)。元数据包括一个能将64位标签映射到数据块的位置及其组成文件的表格，数据块副本位置和哪个进程正在读写特定的数据块等。还有Master节点会周期性地接收从每个Chunk节点来的更新(“Heart-beat”)来让元数据保持最新状态;其二是Chunk节点，它主要用于存储数据。在每个Chunk节点上，数据文件会以每个默认大小为64MB Chunk的方式存储，而且每个Chunk有唯一一个64位标签，并且每个Chunk都会在整个分布式系统被复制多次，默认次数为3。下图就是GFS的架构图：

▲

　　图2. GFS的架构图

　　接着，在设计上，GFS主要有八个特点：

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

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

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

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

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

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

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

　　基于用户空间：GFS主要运行于系统的用户空间(User Time)，虽然在效率方面，用户空间比内核空间略低，但是更便于开发和测试，还有，就是能更好利用Linux的自带的一些POSIX API。

　　优劣点

　　由于GFS主要是为了存储海量搜索数据而设计的，所以它在吞吐量(Throughput)和伸缩性(Scalability)这两方面表现非常优异，可谓业界的“翘楚”，但是由于其主要以64MB数据块形式存储，所以在随机访问方面速度并不优秀，虽然这点可谓是它的“软肋”，但是这本身也是其当初为了吞吐量和伸缩性所做的权衡。

　　相关产品

　　和MapReduce相似的是，GFS在开源界也有其对应的产品，最出名的是HDFS分布式文件系统，在功能和设计上，HDFS从GFS身上借鉴了很多东西，而且由于其本身就是Hadoop系列的一部分，所以它为了更好Hadoop这个MapReduce框架做了很多优化。

　　实际用例

　　现在Google内部至少运行着200多个GFS集群，最大的集群有几千台服务器，数据量是PB级别的，并且服务于多个Google服务，包括Google搜索和Google Earth等。同时，在最近几年，由于上面提到的高延迟问题，所以GFS并不很适合新的一些Google产品，比YouTube、Gmail和非常强调实时性的Caffeine搜索引擎等，所以Google已经在开发下一代GFS，代号为“Colossus”，并且在设计方面有许多不同，比如，支持分布式Master节点来提升高可用性并支撑更多文件和chunk节点能支持1MB大小的chunk以支撑低延迟应用的需要等，希望等Colossus成熟的时候，Google也能像当初GFS那样，将其设计的细节和经验拿出来和大家分享。