读Google三篇论文（GFS、MapReduce、Big Table）有感
首先，在拜读这三篇论文时，我遇到了大量的计算机行业专业术语，相信对于计算机专业目前处于和我差不多水平的同学来说这无疑是一件很让人头疼的问题，更不用说其他专业的同学了。在短短的一周内，我尽可能地逐字逐句地去读这三篇，期间尝试着百度了解每一个术语，并期望读完后对此有一个较好的了解，但到最后，从这三篇论文中成功了解到的知识并不多，诚然，需得我们多次反复阅读，才能从中获益。
在读期间，我发现有时候问题与需求真是使人进步的动力，为了满足 Google 迅速增长的数据处理需求，Google程序员设计并实现了 Google 文件系统(GFS)， 为了处理海量的原始数据，有了MapReduce这一处理和生成超大数据集的算法模型的相关实现的编程模型，还有Bigtable 这一个分布式的结构化数据存储系统。
鉴于Google大神太能干，还有自己目前水平对这三篇论文不太理解不足以做出较为准确透彻的分析和学习，故只能通过其他对此论文的解析来加深自己的理解，在此附加有关该论文的一些感悟博文的链接 （原文：https://blog.****.net/tiankong_/article/details/77302709）；下面将概述其几点优点：GFS架构的设计优点：1)GFS实现了控制流与数据流的分离；2）采用中心服务器模式；3）无论客户端还是chunk服务器都不需要缓存文件数据；等等。MapReduce优点：该框架解决了诸如数据分布式存储、作业调度、容错、机器间通信复杂等问题，采用 MapReduce架构可以使那些没有并行计算和分布式处理系统开发经验的程序员有效利用分布式系统的丰富资源。 Big Table优点：Bigtable已经实现了下面的几个目标：适用性广泛、可扩展、高性能和高可用性。Bigtable 已经在超过 60 个 Google 的产品和项目上得到了应用，包括 Google Analytics、Google Finance、Orkut、Personalized Search、Writely 和 Google Earth。同时，在这三篇论文中都提到了些程序员从中所获得的经验以及教训，我认为这些也是值得我们去认真研读的。在建造和部署 GFS 的过程中，遇到了一些操作上，技术上的问题；在解决MapReduce开发问题中学到了不少东西，如下所述：首先，约束编程模式使得并行和分布式计算非常容易，也易于构造容错的计算环境；其次，网络带宽是稀有资源。大量的系统优化是针对减少网络传输量为目的的：本地优化策略使大量的数据从本地磁盘读取，中间文件写入本地磁盘、并且只写一份中间文件也节约了网络带宽；多次执行相同的任务可以减少性能缓慢的机器带来的负面影响，同时解决了由于机器失效导致的数据丢失问题。在设计、实现、维护和支持 Bigtable 的过程中的两个教训：很多类型的错误都会导致大型分布式系统受损，这些错误不仅仅是通常的网络中断、或者很多分布式协议中设想的 fail-stop 类型的错误，在彻底了解一个新特性会被如何使用之后，再决定是否添加这个新特性是非常重要的；经验: 系统级的监控对 Bigtable 非常重要, 简单设计的价值。通过从雏形阶段到逐渐发展壮大，每一种设计都必须在真实环境中应用，某些设计对于特定环境适合，在其他环境却有差错，针对不同的需求需要做出不同东西与之匹配，当然，我们的各位程序员也在不断的改进中，力求最优，为用户提供更优的体验。
就我自己浅薄理解，这是三篇Google引爆大数据时代的论文，虽然Google没有给出这三个产品的源码，可是三篇详细的设计论文，奠定了风靡全球的大数据算法的基础。三篇论文涵盖的知识量很大，需反复品读，仔细领略其中“风景”，日后，必定数次拜读。