Google架构学习

Google架构学习

关键字: google
原文：Google Architecture
摘自:javaeye
Google是伸缩性的王者。Google一直的目标就是构建高性能高伸缩性的基础组织来支持它们的产品。

平台
Linux
大量语言：Python，Java，C++

状态
在2006年大约有450,000台廉价服务器
在2005年Google索引了80亿Web页面，现在没有人知道数目
目前在Google有超过200个GFS集群。一个集群可以有1000或者甚至5000台机器。成千上万的机器从运行着5000000000000000字节存储的GFS集群获取数据，集群总的读写吞吐量可以达到每秒40兆字节
目前在Google有6000个MapReduce程序，而且每个月都写成百个新程序
BigTable伸缩存储几十亿的URL，几百千千兆的卫星图片和几亿用户的参数选择

堆栈
Google形象化它们的基础组织为三层架构：
1，产品：搜索，广告，email，地图，视频，聊天，博客
2，分布式系统基础组织：GFS，MapReduce和BigTable
3，计算平台：一群不同的数据中心里的机器
4，确保公司里的人们部署起来开销很小
5，花费更多的钱在避免丢失日志数据的硬件上，其他类型的数据则花费较少

可信赖的存储机制GFS(Google File System)
1，可信赖的伸缩性存储是任何程序的核心需求。GFS就是Google的核心存储平台
2，Google File System - 大型分布式结构化日志文件系统，Google在里面扔了大量的数据
3，为什么构建GFS而不是利用已有的东西？因为可以自己控制一切并且这个平台与别的不一样，Google需要：
-跨数据中心的高可靠性
-成千上万的网络节点的伸缩性
-大读写带宽的需求
-支持大块的数据，可能为上千兆字节
-高效的跨节点操作分发来减少瓶颈
4，系统有Master和Chunk服务器
-Master服务器在不同的数据文件里保持元数据。数据以64MB为单位存储在文件系统中。客户端与Master服务器交流来在文件上做元数据操作并且找到包含用户需要数据的那些Chunk服务器
-Chunk服务器在硬盘上存储实际数据。每个Chunk服务器跨越3个不同的Chunk服务器备份以创建冗余来避免服务器崩溃。一旦被Master服务器指明，客户端程序就会直接从Chunk服务器读取文件
6，一个上线的新程序可以使用已有的GFS集群或者可以制作自己的GFS集群
7，关键点在于有足够的基础组织来让人们对自己的程序有所选择，GFS可以调整来适应个别程序的需求

使用MapReduce来处理数据
1，现在你已经有了一个很好的存储系统，你该怎样处理如此多的数据呢？比如你有许多TB的数据存储在1000台机器上。数据库不能伸缩或者伸缩到这种级别花费极大，这就是MapReduce出现的原因
2，MapReduce是一个处理和生成大量数据集的编程模型和相关实现。用户指定一个map方法来处理一个键/值对来生成一个中间的键/值对，还有一个reduce方法来合并所有关联到同样的中间键的中间值。许多真实世界的任务都可以使用这种模型来表现。以这种风格来写的程序会自动并行的在一个大量机器的集群里运行。运行时系统照顾输入数据划分、程序在机器集之间执行的调度、机器失败处理和必需的内部机器交流等细节。这允许程序员没有多少并行和分布式系统的经验就可以很容易使用一个大型分布式系统资源
3，为什么使用MapReduce？
-跨越大量机器分割任务的好方式
-处理机器失败
-可以与不同类型的程序工作，例如搜索和广告。几乎任何程序都有map和reduce类型的操作。你可以预先计算有用的数据、查询字数统计、对TB的数据排序等等
4，MapReduce系统有三种不同类型的服务器
-Master服务器分配用户任务到Map和Reduce服务器。它也跟踪任务的状态
-Map服务器接收用户输入并在其基础上处理map操作。结果写入中间文件
-Reduce服务器接收Map服务器产生的中间文件并在其基础上处理reduce操作
5，例如，你想在所有Web页面里的字数。你将存储在GFS里的所有页面抛入MapReduce。这将在成千上万台机器上同时进行并且所有的调整、工作调度、失败处理和数据传输将自动完成
-步骤类似于：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS
-在MapReduce里一个map操作将一些数据映射到另一个中，产生一个键值对，在我们的例子里就是字和字数
-Shuffling操作聚集键类型
-Reduction操作计算所有键值对的综合并产生最终的结果
6，Google索引操作管道有大约20个不同的map和reduction。
7，程序可以非常小，如20到50行代码
8，一个问题是掉队者。掉队者是一个比其他程序慢的计算，它阻塞了其他程序。掉队者可能因为缓慢的IO或者临时的CPU不能使用而发生。解决方案是运行多个同样的计算并且当一个完成后杀死所有其他的
9，数据在Map和Reduce服务器之间传输时被压缩了。这可以节省带宽和I/O。

在BigTable里存储结构化数据
1，BigTable是一个大伸缩性、错误容忍、自管理的系统，它包含千千兆的内存和1000000000000000的存储。它可以每秒钟处理百万的读写
2，BigTable是一个构建于GFS之上的分布式哈希机制。它不是关系型数据库。它不支持join或者SQL类型查询
3，它提供查询机制来通过键访问结构化数据。GFS存储存储不透明的数据而许多程序需求有结构化数据
4，商业数据库不能达到这种级别的伸缩性并且不能在成千上万台机器上工作
5，通过控制它们自己的低级存储系统Google得到更多的控制权来改进它们的系统。例如，如果它们想让跨数据中心的操作更简单这个特性，它们可以内建它
6，系统运行时机器可以自由的增删而整个系统保持工作
7，每个数据条目存储在一个格子里，它可以通过一个行key和列key或者时间戳来访问
8，每一行存储在一个或多个tablet中。一个tablet是一个64KB块的数据序列并且格式为SSTable
9，BigTable有三种类型的服务器：
-Master服务器分配tablet服务器，它跟踪tablet在哪里并且如果需要则重新分配任务
-Tablet服务器为tablet处理读写请求。当tablet超过大小限制(通常是100MB-200MB)时它们拆开tablet。当一个Tablet服务器失败时，则100个Tablet服务器各自挑选一个新的tablet然后系统恢复。
-Lock服务器形成一个分布式锁服务。像打开一个tablet来写、Master调整和访问控制检查等都需要互斥
10，一个locality组可以用来在物理上将相关的数据存储在一起来得到更好的locality选择
11，tablet尽可能的缓存在RAM里

硬件
1，当你有很多机器时你怎样组织它们来使得使用和花费有效？
2，使用非常廉价的硬件
3，A 1,000-fold computer power increase can be had for a 33 times lower cost if you you use a failure-prone infrastructure rather than an infrastructure built on highly reliable components. You must build reliability on top of unreliability for this strategy to work.
4，Linux，in-house rack design，PC主板，低端存储
5，Price per wattage on performance basis isn't getting better. Have huge power and cooling issues
6，使用一些collocation和Google自己的数据中心

其他
1，迅速更改而不是等待QA
2，库是构建程序的卓越方式
3，一些程序作为服务提供
4，一个基础组织处理程序的版本，这样它们可以发布而不用害怕会破坏什么东西

Google将来的方向
1，支持地理位置分布的集群
2，为所有数据创建一个单独的全局名字空间。当前的数据由集群分离
3，更多和更好的自动化数据迁移和计算
4，解决当使用网络划分来做广阔区域的备份时的一致性问题(例如保持服务即使一个集群离线维护或由于一些损耗问题)

学到的东西
1，基础组织是有竞争性的优势。特别是对Google而言。Google可以很快很廉价的推出新服务，并且伸缩性其他人很难达到。许多公司采取完全不同的方式。许多公司认为基础组织开销太大。Google认为自己是一个系统工程公司，这是一个新的看待软件构建的方式
2，跨越多个数据中心仍然是一个未解决的问题。大部分网站都是一个或者最多两个数据中心。我们不得不承认怎样在一些数据中心之间完整的分布网站是很需要技巧的
3，如果你自己没有时间从零开始重新构建所有这些基础组织你可以看看Hadoop。Hadoop是这里很多同样的主意的一个开源实现
4，平台的一个优点是初级开发人员可以在平台的基础上快速并且放心的创建健全的程序。如果每个项目都需要发明同样的分布式基础组织的轮子，那么你将陷入困境因为知道怎样完成这项工作的人相对较少
5，协同工作不一直是掷骰子。通过让系统中的所有部分一起工作则一个部分的改进将帮助所有的部分。改进文件系统则每个人从中受益而且是透明的。如果每个项目使用不同的文件系统则在整个堆栈中享受不到持续增加的改进
6，构建自管理系统让你没必要让系统关机。这允许你更容易在服务器之间平衡资源、动态添加更大的容量、让机器离线和优雅的处理升级
7，创建可进化的基础组织，并行的执行消耗时间的操作并采取较好的方案
8，不要忽略学院。学院有许多没有转变为产品的好主意。Most of what Google has done has prior art, just not prior large scale deployment.
9，考虑压缩。当你有许多CPU而IO有限时压缩是一个好的选择。

F5助力eBay数据库服务器负载均衡

美国eBay公司是世界上最大的网上交易平台。据统计，每天有涉及几千个分类的几百万件商品在eBay上销售；eBay的年增长率达到50%。但是，和快速增长的业务相比，eBay的IT支撑系统的高可用性还相对滞后，其IT系统重构规划时还确认用户数据库有单点故障(SPOF)。为此，eBay采用了F5公司提供的数据库服务器负载均衡解决方案，不仅使数据库可用性达到99.9%，而且还实现了在线拓展、高安全和高可管理性，从而解决了eBay的用户数据库服务请求的压力，为其进一步的持续高速发展铺平了道路；该方案也为电子商务以及其他公共服务行业类的数据库服务器负载均衡，提供了一个不可多得的成功样板。
需求及挑战

问题还得从eBay的数据库系统说起，eBay拥有30套生产数据库，全部采用Oracle数据库,其中包括12 数据库支持 “live” 项目 (Sun 480/4500)；1 个数据库支持存档项目(Sun 4800)；4个数据库支持客户数据 (Sun 4800)；2 个数据库支持 eBay的反馈系统 (Sun 480)；1个 数据库支持非正常的 “cache” 数据 (Sun 4800)；其他的数据库 (大部分 Sun 480 class)。同时，采用Hitachi SAN 建立存储架构,建立了两个远程备份数据库，并实施实时复制数据到远程数据库实现冗灾，同时每24小时实施针对数据块的数据备份。

因此，通过eBay 数据库读写的比率分析，可以发现，eBay在数据库提供服务时，读和查询的操作达到530亿次，而数据库写和更新的操作达到2亿次。“读和查询”操作与“写和更新”的比率达到265:1。可见查询和数据库读的操作给数据库管理系统带来巨大的压力。而更为严峻的是，eBay年增长率达到50%，这意味着，来自读和查询的操作压力将持续增大，要保证数据库服务的响应能力和效率，稳定性和安全性，eBay 必须采用数据库服务器的负载均衡解决方案。

但是，由于系统庞大，出于投资保护等考虑，Bay 对数据库服务器的负载均衡解决方案的需求有如下几个特点：不改变eBay的数据库体系结构；可用性目标达到99.9%；需承载eBay每年50%的高成长；简单管理等等。这意味着在不对系统大动干戈的同时，却革命性地提高其性能，其挑战不言而喻。

解决方案

针对eBay数据库服务器负载均衡的需求特点，eBay考虑了三种主要解决方案。1） 将数据库垂直分割，划分成多层数据库处理，减轻原来单层数据库处理数据而形成的瓶颈与可用性问题。但问题：这种方案很难部署，而且也没有从根本上解决单点故障问题。2）采用Oracle OPS/RAC机群解决方案。问题：要求给便数据库编程代码，非常难以管理与维护。3）采用F5 与SharePlex 联合解决方案。其优点是：简单管理，不需要改变整个体系结构。

在最初，eBay采用Oracle OPS/RAC解决问题。但是后来经过充分论证和探讨，最终eBay采用了基于F5/SharePlex的解决方案。F5解决方案是应用类似OPS/RAC，但是却相对简单的f5的解决方案，不用改变数据库体系结构，管理和维护简单得多。F5解决方案得主要思路是，通过应用将数据库“读与查询”的操作与”写和更新”的操作导向到分开的 “逻辑” 数据库，这些数据库服务器都单独配备数据存储，而没有采用共享存储的方式！这样，F5 应用交换机动态的将所有的数据库”读与查询”请求导向到查询数据库服务器群中，并智能负载均衡到最佳的数据库服务器上。所有的”写和更新”请求都指向到一个单一的数据库服务器上,由SeharePlex动态实时将数据记录复制到”读与查询”数据库服务器群的数据库中。

这样，一方面，数据库服务器群被F5应用交换机虚拟化和集群，变成了一个“池”；另一方面，“读与查询”的操作，可以根据需要，选择更高效率得数据库服务器，从而使“读与查询”的操作压力得到解决。同时，随着业务的增长，还可以随时根据客户业务的压力在线扩展新的服务器在这个群之中。由于根据以上分析，数据库读写的比例超过260倍，采用这样的方法，有效解决了数据库性能和高可用性要求。



采用F5/Share Plex 解决方案示意图

方案特点

F5解决方案具有以下特点：1.运用分离读和写操作，使读和写操作进入分别的逻辑数据库 而不是共享磁盘2. f5 数据库服务器均衡可以使所有的读操作交叉分配到available hosts; 所有的写操作都指定到单一的database-of-record ; 3.应用类似OPS/RAC，但是却相对简单的f5的解决方案; 4.发挥f5产品灵敏的量测性和显著的增强可用性。

采用F5的BIG-IP负载均衡器后,对于eBay应用系统有独到的优势:
高可用性: BIGIP动态分配每一个流量请求到后台的四台Oracle 9i Database 数据库服务器,并动态检查各个服务器的健康状态,将下一个请求分配给最有效率的服务器,任何服务起死机时,BIGIP即刻将流量请求分配给其他的三台服务器,从而达到99.999%系统有效性。特别是针对Oracle 9i 数据库服务器，F5公司专门为Oracle 9i 数据库开发了专用的健康检查模块，通过调用F5专有的扩展应用校验(EAV)进程，F5能够随时得到Oracle 9i数据库的应用层服务能力而不是其他的负载均衡设备所采用的iCMP / TCP 层进行健康检查。

高安全性: BIGIP支持地址翻译技术和安全地址翻译，这样一来客户不可能知道真正提供服务的服务器的IP地址与端口，从而保护数据库服务器不受到诸如SYN Flood 等DOS及DDOS进攻。

高效率: 采用BIG-IP 负载均衡之后, BIG-IP可以智能寻找最佳状态的数据库服务器从而保证客户得到响应最快的数据库服务器以提供最佳的查询数据库服务!

高可扩展性: BIGIP可以支持动态增加或删除其负载均衡的数据库服务器群组的任何数量的服务器,而不需要对前端或后台做任何改变从而使得系统扩展轻松方便，透明。

高可管理性: BIGIP有专门的管理软件可以实时监控整个数据库服务器群组的流量状态,并分析发展趋势帮助客户及时根据流量增长增加服务器。

客户价值

F5解决方案具有低成本、低维修，以及保护投资，高效率的特点，并方便在线拓展，面向未来。在2001年第二季度，F5公司与Quest公司合作成功帮助客户实现了以上解决方案，初期布署了两台”读与查询”数据库服务器和一台”写和更新”数据库服务器。在2001年第三季度成功通过了99.9%高可用性。并真正实现了在线高可扩展性，在2002年增加另外两台读与查询”数据库服务器，并于2002年第三季度增加部署了冗灾备份的功能。

F5提供的eBay数据库服务器负载均衡解决方案对行业也具有相当的借鉴意义。电子商务应用同样有着数据库查询的压力，如果能够有效将查询的压力分解到单独的服务器群来处理，将有效提高电子商务的应用效率。 对于电子商务类应用系统数据库扩展解决方案，只需要在Web Portal上将数据库请求分成两个不同模块，问题便迎刃而解。

对于公众服务行业类的数据库服务器的负载均衡，如银行，电信，税务等系统，每月和每季度的都会有报表生成汇总，这些报表既包括用户的月结单数据信息，也需要产生总体业务的业绩报告。这样就必须对数据库系统进行检索和查询。如果这些业务工作与实际生产环境是一个数据库的情况下，将造成系统的巨大压力。采用F5类似方法，同样能够有效达到高可用性预告可扩展性能的需要！

Verizon：2008年数据泄露多于四年总和

　　2008年泄露的电子记录总量比去年四年的总和还要多，而且其中大部分（90%）的泄露都是可以通过持续实施基本的防护性控制避免的。

　　Verizon在发布的《2009年Verizon业务数据泄露调查报告》中指出，2008年发生的已经确定的90起数据泄露事件涉及2.85亿份记录，而在2004年到2007年之间发生的数据泄露事件总共涉及2.3亿份记录。

　　Verizon调查的数据泄露事件中有大约1/3已经公开，预计今年年底还会有更多事件被公开。

　　调查发现：被涉及的记录中有91%的记录与犯罪组织团伙有关；有目的的病毒攻击翻了一番；受到攻击最多的板块是默认证书和SQL注入。

　　Verizon业务安全解决方案部门研究副总裁Peter Tuppett表示，这份报告向人们敲响了警钟：企业业务需要更完善的安全和防护措施，尤其是当前的经济危机很可能引发更频繁的犯罪活动。

　　不过也有一个好消息，针对个人数据的市场已经瓦解。

　　报告指出：“最近几年磁带数据的大量泄露已经泛滥了整个信息黑市，这种市场饱和已经导致磁带信息变得一文不值。甚至出售被盗戏弄卡数据的价格已经从2007年年中的每份记录10～16美元锐减到现在每份记录0.5美元。”

　　坏消息是，网络犯罪开始转向盗取和银行账户信息有关的个人身份数字，罪犯可以利用这些数字盗走受害人账户上的现金。

　　这就解释了为什么2008年受牵连的2.85亿份记录中有95%都是来自于金融机构。报告中还指出，这主要是因为2008年金融机构发生数据泄露规模之大。

　　正如Verizon之前的数据泄露报告一样，大多数受调查的数据泄露事件都是有第三方发现的。这表明企业机构需要对他们自己的数据有更好的监管和控制。

　　令人感到以外的是，99%的泄露记录都是通过服务器和应用访问的，而不是笔记本电脑、上网本、手机或者可移动存储介质。

　　从报告中中我们可以接受到很多教训。但最主要的一个是持续应用安全策略其实是可以防止大多数数据泄漏事件发生的。

　　而且Verizon还给企业机构提供了更具体的建议，比如更改默认证书、避免分享证书、复查用户账户、应用测试和代码复查、智能补丁管理、员工期满终止流程、应用日志和监控、对可以或者匿名网络行为的监控。

Oracle收购Sun七大明智之处

北京时间4月20日，甲骨文和Sun微系统公司联合发表声明，甲骨文以74亿美元收购Sun。国外媒体发表分析文章称，甲骨文收购Sun有7大明智之处：

1，如果云计算对企业来说变得越来越重要，那么数据将是云计算的核心。 而讲到数据，也就意味着数据库。就如塔克商学院数字策略中心主任M. Eric Johnson所说的那样，Sun已经清楚展现了一个真实的云计算环境。就那些将云计算停留在理论阶段的对手来说，收购Sun对甲骨文来说将获得竞争优势。

2，Johnson主任还指出，Sun在很多需求旺盛的方面“保持领先地位”。Sun的技术可以帮助数据库提高性能，尤其是对大型数据库。甲骨文和Sun的结合之后，对任何一个信息官来说都具有吸引力。

3，甲骨文软件和Java的紧密结合，使得甲骨文的软件能跨平台使用。就如IDC研究副总裁Jean Bozman指出那样，真正云计算的第一步是“将服务器和存储单元垂直化”，可以适用于不同的硬件平台。凭借Java，甲骨文可以拓展跨平台的控制力，而这正是企业IT部门想要的。实际上，甲骨文的Oracle Fusion Middleware正是基于Java。

4，有意思的是，Oracle Fusion Middleware扩大了对服务器的需求，其中原因正是由于它是基于Java。而现在，甲骨文通过购得Sun服务器资源，可以进一步降低价格，从而进一步提高Oracle Fusion Middleware的竞争力。

5，由于甲骨文大部分收入来自数据库软件许可，因此有必要的话，可以用便宜的服务器硬件作为促销的手段，这样对那些硬件服务器竞争对手来说是不小的打击。

6，Sun已经售出160万到200万台服务器，还有更多的运行Sun Solaris操作系统的其它公司的服务器。这对甲骨文捆绑销售自家产品也很有帮助。

7，甲骨文收购Sun，当然也包括开源数据库MySQL。对于那些预算不多但又需要甲骨文产品的用户，甲骨文可以用MySQL来满足这些用户的需求。这可以使甲骨文进入中小企业业务，更有机会在这方面超过SAP。此外，还提供了和微软SQLServer的竞争产品，而不需要降低甲骨文自有的产品的定位。

甲骨文和Sun的合作可能会影响甲骨文和一些合作伙伴的关系，比如甲骨文和惠普的关系可能就会出现问题。不过，不像IBM，事实上，每个硬件公司都绕不开甲骨文，因为它是数据库的主力军。他们离不开甲骨文，因此，他们也只能选择忍气吞声。

而且，与Sun和IBM联合不同，甲骨文和Sun不存在硬件的冲突，那些Sun的服务器用户不必担心合并会导致放弃自己在使用的服务器产品线。

总而言之，甲骨文以相对较低的价格收购Sun是明智之举，将会使得合并后的甲骨文成为各大公司数据中心的枢纽。