分布式系统与 Google 早期的三篇论文

版本号	修改时间	修订人	修改备注
1.0	2019-10-30	汐雪池间	初稿

Google 在 2003~2006 年间发表的三篇论文为今天 Hadoop 大数据生态的发展奠定了技术基础，工程师利用市场上相对廉价的通用计算设备（x86架构，Linux 系统）而非昂贵的定制版服务器，搭建低成本、易扩展、高可用的分布式数据存储、管理、计算集群，支撑了 Google 的多项重要服务。

许多对大数据技术感兴趣的人都听说过 Google 在十年前发表的三项重要成果： Google File System、 MapReduce 和 Bigtable 。Google 在这些成果中，介绍了其利用通用计算设备成功搭建分布式集群的方法。其中的诸多设计思想在后来被广泛借鉴。

论文题目	The Google File System [1]	MapReduce: Simplified Data Processing on Large Clusters [2]	Bigtable: A distributed storage system for structured data [3]
发表时间	2003	2004	2006
内容概述	分布式数据存储。容错、高性能的分布式文件系统，同时服务大量客户端。	分布式批处理计算。	分布式结构化数据管理。
设计理念	1. 发生错误是常态(进程错误，系统错误，设备错误) 2. 单个文件体积大 3. 文件内容一般以追加的形式进行修改 4. 对原子性和一致性进行修改	将数据以键-值对的形式进行组织，以 map、reduce 为基本操作的编程范式	它为客户端提供了一个简单的数据模型，该模型支持对数据布局和格式的动态控制，并允许客户端对底层存储中表示的数据的存储位置进行推理。
关键技术	1. 容错 2. 并发 3. 一致性	1. 容错 2. 数据分布 3. 负载均衡
系统架构	master(1主+1备) + chunkserver	master + worker
数据模型			结构化数据，关系型数据库

为什么要设计这些系统？这些系统都有什么用处？这些系统在实现上有哪些特点？对后来的系统设计有哪些启发意义?本文通过提出一系列问题并自我回答，介绍了现行大数据技术的核心设计理念和技术实现。

1. 分布式系统

• 为什么需要分布式系统？

在硬盘存储空间多年来不断提升的同时，硬盘的读取速度没有与时俱进。如果将大量数据存储于单个磁盘中，在分析时将需要耗费大量时间。

从 1990 年到 2010 年，主流硬盘空间从1GB 增长到 1TB，一千倍的提升，硬盘的读取速度从 4.4 MB/s 到 100 MB/s，仅有约20倍的提升[4]。以这种速度(100 MB/s)读完整个硬盘(1TB)的数据至少需要 2.5 个小时。

如何减少数据读写以及数据分析的时间呢？比较直接的方案是同时对多个硬盘中的数据并行读/写，即利用分布式系统存储和处理数据，提高I/O 带宽，但这一方案也会面临一些突出问题，例如：

1. 更高的硬件故障频率。假如单个硬盘连续正常使用一个月的可靠性是 99.99%，一个月中 10000 个磁盘都不出错的概率只有 36.8%。
2. 不同节点之间的数据组织和共享。一份数据要如何存放在不同磁盘上？不同节点上的数据如何更高效地通信、共享，从而避免网络I/O成为系统瓶颈？
   0.999 9 10000 ≈ 0.368 0.9999^{10000} ≈ 0.368