Google是可伸缩性之王。每个人都知道Google是因为他们对大量，复杂信息的快速搜索，但是Google的技术并不只是在搜索领域闪闪发光。他们构建大型应用的平台方式能够让他们以惊人的竞争速度在网络规模应用上面大展拳脚。Google的目标一直是构建更高性能更高规模基础设施来支持他们的产品。他们怎么做到的呢？
1平台
• Linux
• 多种不同的语言： Python, Java, C++
数据揭秘
目前的情形：
• 2006年估计有450,000个价格便宜的商用服务器
• 2005年Google索引了80亿的web页面。到现在为止有多少，已经无法统计出来了。
• 目前Google有超过200GFS的集群。一个集群能有1000甚至5000个机器。成百上千的机器从运行大到5peta字节存储的GFS集群检索数据。通过集群的总的读写吞吐量达到每秒400亿字节。
• 目前在Google有6000个 MapReduce应用，并且每个月有几百个新的应用正在出现。
架构的层次
Google把他们的基础设施架构描述为三个层次栈：
• 产品：检索，广告，电子邮件，地图，视频，聊天，博客
• 分布式系统基础设施：GFS, MapReduce, 以及BigTable。
• 计算平台：很多不同数据中心的很多机器
• 确保公司员工容易低成本配置。
• 看看每个应用基线的价格性能数据。把更多的钱花在硬件上以期不丢失日志数据，但是在其他类型的数据上花少一点。既然这样处理，实际上他们就不会丢数据。
使用GFS（Google文件系统）的可靠存储机制
• 可靠的可伸缩存储是任何应用的一个核心需要。GFS就是他们的核心存储平台。
• Google文件系统- 大的分布式日志结构化文件系统，里面有大量数据
• 为什么不用其他的而非要构建一个文件系统呢？因为他们需要控制所有的事情，而正是这个平台把他们和其他任何一个区分开来。他们需要：
- 通过数据中心的高可靠性
- 对于几千个网络节点的可伸缩性
- 大的读写带宽需求
- 支持十亿字节大的数据块
- 高效的通过节点减少瓶颈的分布式操作
• 系统有主服务器和分块服务器（chunk servers）
- 主服务器在各种数据文件上保存元数据。数据以64MB大的块存储在文件系统中。客户机和主服务器对话来操作文件里的元数据，定位包含了磁盘上他们需要的数据的分块服务器。
• 一个新的应用可以使用一个已经存在的GFS集群或者他们自己制作。去理解他们使用的通过数据中心的这个供应过程将是非常有趣的。
• 主键是足够的基础设施来确保人们对他们的应用有多种选择。可以调整GFS以适应个人应用需要。
使用MapReduce对数据做一些事情
• 既然你有了一个好的存储系统，你怎样使用如此多的数据呢？假如说你有很多TB的数据存储在1000台机器上。数据库不能扩展或者有效地扩展到这样的规模。这时就要用到MapReduce了。
• MapReduce是一个编程模型和用来处理和产生大规模数据集。用户指定一个映射函数处理一个键/值对来产生中间的键/值对集合，还指定一个缩小函数来合并所有的与同一中间键相关的中间值。
许多现实世界的任务在这个模型里被表示出来。用这个函数风格写的程序自动并行化并且在一大集群商务机器上执行。运行时系统关心分割输入数据的细节，通过一系列的机器安排程序的执行，处理机器事故，以及管理所需的机器内部通信。这使得没有任何并行和分布式系统经验的程序员能够容易地利用一个大的分布式系统的资源。
• 为什么使用MapReduce呢？
- 在大量机器上分割任务的极佳方式
- 处理机器故障
- 在不同类型的应用上工作，如搜索和广告。几乎每个应用都有映射简化类型之类的操作。你可以预计算有用的数据，统计字数，分类几TB的数据，等等。
- 计算可以自动地更加靠近IO源。
• MapReduce 系统有三个不同类型的服务器。
- 主服务器分配用户任务以映射和减少服务器。它也跟踪任务的状态。
- 映射服务器接收用户输入，在它们上面实行映射操作。结果写入中间文件。
- 化简服务器接收由映射服务器产生的中间文件并在它们上面实行化简操作。
• 例如，你想要统计所有网页中字符的个数。你可以把存储在GFS中的页面放入MapReduce。这些都将在1000秒内发生，包括机器同步和协调，任务安排，事故处理和数据传输将会自动完成。
- 步骤如下：GFS -> Map -> Shuffle -> Reduction -> 把结果存回GFS
- 在MapReduce 里，一个映射把一个视图映射到另一个，产生一个键值对，在我们的例子里是单词和数量。
- Shuffling 聚合键的类型
- 化简把所有的键值对加起来产生最后的结果。
• Google索引管道有大概20个不同的映射化简。一个管道把数据看做记录的一个整体束和聚合键。第二个映射-化简进来把那个结果拿走做其他的一些事情。等等。
• 程序可以很小。可以小到20到50行的代码。
• 一个问题是stragglers。Stragglers是一种比其他都要慢的计算。Stragglers会发生是因为慢的IO（比如一个糟糕的控制器）或者从一个临时的CPU尖峰信号。解决办法是运行多个同样的计算，当一个完成时就销毁所有其他的计算。
• 在映射和化简之间转换的数据被压缩。这样做是因为服务器不受CPU约束，花时间在数据的压缩和解压缩上还是有意义的，可以节省花在带宽和I/O上的时间。
在BigTable中存储结构化数据 • BigTable 是一个大型的容错和自我管理系统，包括太（万亿）字节的内存和皮字节的内存。它每秒能够处理几百万的读写。
• BigTable是一个构建在GFS之上的分布式散列机制。它不是一个关系数据库。它不支持联结或者SQL类型查询。
• 它提供查找机制，可以通过键来访问结构化的数据。GFS存储不透明数据和许多应用所需的结构化数据。
• 商业化数据不能伸缩到这个层次，它们不在1000个机器上工作。
• 通过控制它们自己的低层次存储系统，Google得到更多的控制和有力的工具来改进它们的系统。例如，如果它们想要使得分布
数据操作更简单的特征，它们可以在里面构建。 • 当系统运行的时候，机器可以增加和减少，而整个系统还会正常工作。
• 每个数据条存储在一个可以使用行键，列键或者时间邮票访问的单元中。
• 每行存储在一个或者更多个tablet中。一个tablet是数据形式的64KB块的序列叫做SSTable。
• BigTable 有三个不同类型的服务器：
- 主服务器分配tablet到tablet服务器中。它们跟踪的位置，当需要时还会重新分配任务。
- Tablet 服务器处理tablet的读写请求。当tablet超过规模限制（通常是100MB - 200MB）时，它们将它分开。当一个tablet服务器出故障时，会有100个tablet服务器每个捡起一个新的tablet，所以系统就恢复了。
• 一个位置组可以被用作与几比特的数据相关的物理存储，为了有一个更好的参考位置。
• Tablets尽可能在RAM里被缓存。
1硬件
• 当你有很多个机器时，你如何构建它们以使花费代价最小电能消耗最少呢？
• 使用超便宜的商业硬件，拼命利用它们在上面构建软件。
• 增加 1,000-fold 计算机电力，如果你使用容易出事故的基础设施而不是构建在高度可靠的部件之上的基础设施时，可以有33倍更低的花费。你必须使用这一策略在不可靠之上构建可靠。
• Linux，内部的架构设计，PC类主机板，低端存储。
• 性能基线中每瓦的价格没有越来越好。存在着很多的电力和其他问题。
• 使用混合收集和它们自己的数据中心。
杂类
• 很快找出改变而不是等着提问和回答。
• 库是构建程序的主要方式。
• 一些是以服务的形式提供的应用，比如crawling。
• 基础设施处理应用程序的版本，所以它们就能够发布，不用担心破坏事情。
Google未来的方向
• 支持地理位置分布的集群
• 为所有的数据创建单一的全局名字空间。当前数据由集群分离开的。
• 更多更好的数据和计算的自动化迁移。
• 解决当你用网络分割耦合大范围的复制时产生的一致性问题（例如，即使一个集群已经因为维修或是其他一些临时停电等原因而下线时，还能继续提供服务）Goolge告诉我们的经验
• 基础设施是一个很有竞争性的优势。它当然是属于Google的。它们能更快更便宜地提供和生产新的网络服务，这在一定程度上是无人能比的。许多公司采取了完全不同的方式。许多公司把基础设施看做一种花销。每个组将使用完全不同的技术，而且他们很少有计划如何更经济地构建系统。Google把他们自己看做一个系统工程公司，以一个非常新的方式来看待构建软件。
• 跨越多个数据中心仍是一个未解决的问题。大多数网站是一个至多是两个数据中心。如何在大量数据中心上充分分配网站，我们说，非常复杂。
• 看一看Hadoop (产品)如果你没有时间来从头开始构建所有这个基础设施的话。Hadoop 是一个这里讲的一些主意的开源实现。
• 一个平台方式被忽略的优点是初级开发人员可以在平台上很快自信地构建健壮的应用。如果每个项目需要创建同样的分布式基础设施轮，你将会陷入困境，因为知道如何这样做的人员相对稀少。
• 协同工作并不总是废话。通过使系统中所有部件一起工作，一个改进会有助于所有的改进。改善文件系统，每个人都会立刻明显受益。如果每个项目使用一个不同的文件系统，那么就没有整个展的持续的改进。
• 构建不需要降低系统性能的自我管理系统。这可以让你更容易地平衡各服务器的资源，动态增加更多空间，允许机器下线，以及更从容地处理升级。
• 创建一个进化式基础设施。花时间在并行处理上会有回报的。
• 不要忽视了学院。学术界有很多好的创意并没有转入生产环境里。Google所做的大部分先于艺术，不只是先于大规模配置。
• 考虑压缩。当你有大量CPU可以挥霍和IO限制时，压缩是一个很好的选择。
