Google云计算平台的技术架构及对其成本的影响研究.pdf

1、研 究与开发研究与开发1 引言毫无疑问 ， 云计算是 2009 年 IT 行业最热门的话题 ，Google、Amazon、Yahoo 等 互 联 网 服 务 商 ，IBM、Microsoft 等IT 厂商都纷纷提出了自己的云计算战略 ，各电信运营商也对云计算投入了极大的关注 ，云计算平台极低的成本成为业界关注的焦点 。 Google 宣称 ，由于使用了云计算技术 ，其计算成本仅为竞争对手的 1/100，存储成本仅为竞争对手的 1/30。如果事实真的如此 ，那么 Google 究竟是怎么做到的呢 ？为了满足运营管理的需要 ， 电信运营商建设了许多大规模的 IT 系统 ，如中国移动建设了业务支撑系

2、统 、网络管理系统和管理信息系统等 ，这些 IT 系统一般都是建立在高性能 UNIX 服务器集群的基础上 ，与建立在大量的廉价 x86服务器集群基础上的 Google 云计算平台相比 ， 两者在技术架构等方面存在明显的差异 。 本文试图在深入分析 Google云计算平台关键技术的基础上 ， 通过 Google 云计算平台和传统 IT 系统的对比研究 ，寻找出 Google 云计算平台极低的计算成本和存储成本的根本原因 。2 Google 云计算平台的关键技术“云计算 ”的概念是 Google 公司首先提出的 ，其拥有一套专属的云计算平台 ， 这个平台先是为网页搜索应用提供服务 ,现在已经扩展到

3、其他应用程序 。作为一种新型的计算方式 ，Google 云计算平台包含了许多独特的技术 ，如数据中心节能技术 、节点互联技术 、可用性技术 、容错性技术 、数据存储技术 、数据管理技术 、数据切分技术 、任务调度技术 、编程模型 、负载均衡技术 、并行计算技术和系统监控技术等 。Google 云计算平台是建立在大量的 x86 服务器集群上的 ，Node 是最基本的处理单元 ，其总体技术架构如图 1 所示 。在 Google 云计算平台的技术架构中 ， 除了少量负责特定管理功 能 的 节 点 （如 GFS master、Chubby 和 Scheduler等 ），所有的节点都是同构的 ，即同时运

4、行 BigTable Server、本文通过 Google 云计算平台与传统 IT 系统技术架构的对比研究 ， 指出 Google 云计算平台能够实现极低的计算成本的关键在于采用了 “自顶向下 ”的设计思想 。关键词 云计算 ；成本 ；技术架构Google 云计算平台的技术架构及对其成本的影响研究*孙 健1，贾晓菁2（1.中国移动通信集团公司 北京 100032；2.中央财经大学 北京 100081）摘 要* 国家自然科学基金资助项目 （No.70801067），教育部人文社科基金资助项目 （No.07JC630052），教育部青年专项课题 (No.EFA080250)38电 信科学 2010

5、 年第 1 期GFS chunkserver 和 MapReduce Job 等核心功能模块 ， 与之相对应的则是数据存储 、 数据管理和编程模型等 3 项关键技术 ，因此本文将重点对它们进行研究 。2.1 数据存储技术网页搜索业务需要海量的数据存储 ， 同时还需要满足高可用性 、高可靠性和经济性等要求 。 为此 ，Google 基于以下几个假设开发了分布式文件系统 GFS （google filesystem）。（1）硬件故障是常态系统平台是建立在大量廉价的 、 消费级的 IT 部件之上 ，系统必须时刻进行自我监控 、节点检测和容错处理 ，能够从部件级的错误中快速恢复是一个基本的要求 。（2

6、）支持大数据集系统平台需要支持海量大文件的存储 ， 可能包括几百万个 100 MB 以上的文件 ，GB 级别的文件也是常见的 。与此同时 ，小文件也能够支持 ，但将不进行专门的优化 。（3）一次写入 、多次读取的处理模式Google 需要支持对文件进行大量的批量数据写入操作 ，并且是追加方式 （append）的 ，即写入操作结束后文件就几乎不会被修改了 。 与此同时 ，随机写入的方式可以支持 ，但将不进行专门的优化 。（4）高并发性系统平台需要支持多个客户端同时对某一个文件的追加写入操作 ，这些客户端可能分布在几百个不同的节点上 ，同时需要以最小的开销保证写入操作的原子性 。GFS 由一个 m

7、aster 和大量块服务器构成 ，如图 2 所示 。master 存放文件系统的所有元数据 ,包括名字空间 、存取控制 、文件分块信息 、文件块的位置信息等 。GFS 中的文件切分成 64 MB 的块进行存储 。为了保证数据的可靠性 ，GFS 文件系统采用了冗余存储的方式 ，每份数据在系统中保存 3 个以上的备份 ，其中两份拷贝在同一机架的不同节点上 ， 以充分利用机柜内部带宽 ，另外一份拷贝存储在不同机架的节点上 。 同时 ，为了保证数据的一致性 ,对于数据的所有修改需要在所有的备份上进行 ,并用版本号的方式来确保所有备份处于一致的状态 。为避免大量读操作使 master 成为系统瓶颈 ，

8、客户端不直接通过 master 读取数据 ， 而是从 master 获取目标数据块的位置信息后 ，直接和块服务器交互进行读操作 。GFS 的写操作将控制信号和数据流分开 ， 即客户端在获取 master 的写授权后 ,将数据传输给所有的数据副本 ，在所有的数据副本都收到修改的数据后 ， 客户端才发出写请求控制信号 ，在所有的数据副本更新完数据后 ,由主副本向客户端发出写操作完成控制信号 。通过服务器端和客户端的联合设计 ，GFS 对应用支持达到了性能与可用性的最优化 。 在 Google 云计算平台中部署了多个 GFS 集群 ， 有的集群拥有超过 1 000 个存储节点和超过 300 TB 的

9、硬盘空间 ，被不同机器上的数百个客户端连续不断地频繁访问着 。2.2 数据管理技术由于 Google 的许多应用 （包括 Search History、Maps、Orkut 和 RSS 阅读器等 ）需要管理大量的格式化以及半格式化数据 ，上述应用的共同特点是需要支持海量的数据存储 ，读取后进行大量的分析 ， 数据的读操作频率远大于数据的更新频率等 ， 为此 Google 开发了弱一致性要求的大规模数据库系统 BigTable。BigTable 针对数据读操作进行了优化 ，采用基于列存储的分布式数据管理模式以提高数据读取效率 。BigTable 的基本元素是行 、列 、记录板和时间戳 。 其中

10、,记录板 Tablet 就是图 1 Google 云计算平台的技术架构39研 究与开发一段行的集合体 ，如图 3 所示 。BigTable 中的数据项按照行关键字的字典序排列 ，每行动态地划分到记录板中 ，每个服务器节点 Tablet Server 负责管理大约 100 个记录板 。时间戳是一个 64 位的整数 ,表示数据的不同版本 。 列簇是若干列的集合 ，BigTable 中的存取权限控制在列簇的粒度进行 。BigTable 系统依赖于集群系统的底层结构 ， 一个是分布式的集群任务调度器 ，一个是前述的 GFS 文件系统 ，还有一个分布式的锁服务 Chubby，如图 4 所示 。 Chub

11、by 是一个非常健壮的粗粒度锁 ，BigTable 使用 Chubby 来保存 RootTablet 的指针 ，并使用一台服务器作为主服务器 ，用来保存和操作元数据 。 当客户端读取数据时 , 用户首先从 ChubbyServer 中获得 Root Tablet 的位置信息 ， 并从中读取相应的元 数 据 表 Metadata Tablet 的 位 置 信 息 ， 接 着 从 MetadataTablet 中读取包含目标数据位置信息的 User Table 的位置信息 ，然后从该 User Table 中读取目标数据的位置信息项 。BigTable 的主服务器除了管理元数据之外 ， 还负责对T

12、ablet Server 进行远程管理与负载调配 。 客户端通过编程接口与主服务器进行控制通信以获得元数据 ， 与 TabletServer 进行数据通信 ， 而具体的读写请求则由 Tablet Server负责处理 。与前述的系统类似 ，BigTable 也是客户端和服务器端的联合设计 ，使得性能能够最大程度地符合应用的需求 。2.3 编程模型Google 构造了 Map-Reduce 编程框架来支持并行计算 ，应用程序编写人员只需将精力放在应用程序本身 ， 关于如何通过分布式的集群来支持并行计算 ， 包括可靠性和可扩展性 ，则交由平台来处理 ，从而保证了后台复杂的并行执行和任务调度向用户和

13、编程人员透明 。Map-Reduce 是一种处理和产生大规模数据集的编程模型 ，同时也是一种高效的任务调度模型 ，它通过 “Map(映射 )”和 “Reduce(化简 )”这样两个简单的概念来构成运算基40电 信科学 2010 年第 1 期本单元 ， 程序员在 Map 函数中指定对各分块数据的处理过程 , 在 Reduce 函数中指定如何对分块数据处理的中间结果进行归约 ，就能完成分布式的并行程序开发 。 当在集群上运行 Map-Reduce 程序时 , 程序员不需要关心如何将输入的数据分块 、分配和调度 ,同时系统还将处理集群内节点失败以及节点间通信的管理等 。 图 5 给出了一个 Map-

14、Reduce 程序的具体执行过程 。从图 5 可以看出 , 执行一个 Map-Reduce 程序需要 5 个步骤 ：输入文件 ，将文件分配给多个 worker 并行地执行 ，写中间文件 (本地写 )，多个 Reduce worker 同时运行 ，输出最终结果 。 本地写中间文件减少了对网络带宽的压力 ，同时减少了写中间文件的时间耗费 ；执行 Reduce 时 ,根据从 master 获得的中间文件位置信息 ，Reduce 使用远程过程调用 ，从中间文件所在节点读取所需的数据 。Map-Reduce 模型具有很强的容错性 ，当 worker 节点出现错误时 ,只需要将该 worker 节点屏蔽在

15、系统外等待修复 ，并将该 worker 上执行的程序迁移到其他 worker 上重新执行 ， 同时将该迁移信息通过 master 发送给需要该节点处理结果的节点 。 Map-Reduce 使用检查点的方式来处理 master出错失败的问题 ，当 master 出现错误时 ，可以根据最近的一个检查点重新选择一个节点作为 master 并由此检查点位置继续运行 。3 Google 云计算平台与传统 IT 系统的差异传统的 IT 系统 ，尤其是大型的 IT 系统 ，几乎都是建立在高性能 UNIX 服务器集群的基础上 ， 其体系架构先后经历了主机 /终端和 Client/Server 等发展阶段 ，

16、随着互联网的发展 ， 目前主流 IT 系统大多采用了三层 Browser/Server 架构 ，如图 6 所示 。 下面我们将从数据存储 、数据管理和编程框架三个方面分析其与 Google 云计算平台之间的差异 。3.1 数据存储技术对于数据存储技术来说 ， 存储可靠性 、I/O 吞吐能力和可扩展性是最核心的技术指标 。传统 IT 系统的数据储存技术主要包括直连式存储(DAS)、网络接入存储 (NAS)和存储区域网 (SAN)等 。在存储可靠性方面 ，RAID 技术能够很好地解决单个磁盘的故障问题 ，但是需要增加 RAID 控制卡等硬件设备 。 在提高 I/O 吞吐能力和可扩展性方面 ，由于

17、DAS 依赖服务器的操作系统进行数据的 I/O 读写和存储维护管理 ， 难以满足大型 IT 系统对性能的要求 ，为此先后出现了 NAS 和 SAN 等新的数据存储技术 ，尽管两者在文件系统的分布上存在一些差异 ，但其基本策略是一致的 ，即将数据储存从服务器中分离出来 ，采用专门的硬件设备进行集中的管理 ， 其实质是计算和数据的分离 ，如图 7 所示 。在 Google 云计算平台的体系架构中 ， 单个节点 Node采用的是廉价的 x86 服务器 ，每个节点在负责计算的同时 ，图 5 Map-Reduce 程序的具体执行过程图 6 Browser/Server 的技术架构图 7 NAS 和 SA

18、N 的基本原理41研 究与开发还需要通过 GFS Chunk Server 管理本节点存储的数据 ，也就是说 ， 继续保持了计算和数据的统一 。 GFS 放弃使用RAID 技术 ，采取了简单的冗余存储的方法 ，不仅能够满足存储可靠性的要求 ，还有效提升了读操作的性能 。 为了减少单个节点的处理负荷 ，Google 单个节点所管理的裸数据量一般小于 1 TB，但是通过大量节点的并行处理 ，很好地满足了海量数据存储的要求 。需要指出的是 ，对于 Google 云计算平台来说 ，其写操作的效率是非常低下的 ，但是由于其承载的应用大多具有 “一次写入 ，多次读取 ”的特点 ，在实际应用中很少成为瓶颈问

19、题 。3.2 数据管理技术在数据管理技术中 ， 如何提高数据库系统的性能是最核心的问题 。传统 IT 系统采用集中的数据存储方式 ，并通过使用关系型数据库管理系统 （RDBMS）实现集中的数据管理 ，为了避免数据库服务器成为系统性能的瓶颈问题 ， 主要采用了数据缓存 、索引和数据分区等技术 ，但是对于 Google 云计算平台所承载的网页搜索等应用来说 ， 由于需要大量的全文检索 ，上述技术都难以充分发挥作用 ，因此 BigTable 针对其应用中数据读操作占比很高的特点 ， 设计了简化的数据表结构 ，并采用基于列存储的分布式数据管理模式 ，很好地满足了海量数据管理 、高并发性和苛刻的响应时间

20、等要求 。传统 IT 系统普遍采取在服务器集群中进行任务分工的方法 ，以降低数据库服务器负荷并提高系统整体性能 ，例如在 B/S 体系结构下 ，Web 服务器负责接收用户通过浏览器发出的请求 ， 应用服务器负责调用相应的组件完成业务逻辑的处理 ，数据库服务器只需要实现对数据库的查询 、修改和更新等功能 。 但是 ，对于 Google 云计算平台来说 ，由于网页搜索等应用一般都是简单的读操作 ， 并不包含复杂的业务逻辑 ， 传统的 B/S 架构难以显著降低数据库服务器的负荷 ，因此 Google 将并行计算引入数据库系统中 ，将数据分散在大量完全同构的节点上 ，通过 Tablet Server

21、同时提供数据管理服务 ，从而将处理负荷均匀地分布在每个节点上 ，极大地提升了数据库系统的性能 。需要指出的是 ， 在传统 IT 系统中也有类似于 BigTable的多节点并行的数据库系统 ， 例 如 Oracle 的 并 行 集 群Oracle Real Application Server（简称 Oracle RAC），如图 8 所示 。 由于 Oracle RAC 采用了 “集中存储 +内存融合 ”的体系架构 ，不同节点之间需要通过私有网络进行通信 ，对网络带宽和节点之间的时钟同步有很高的要求 。 因此 ，在实际应用中节点数量很难超过 4 个 ，与 Google 云计算平台支持 1 000

22、 个以上节点的规模相比 ，其扩展能力存在很大的差距 。值得注意的是 ， 与传统的 RDBMS 相比 ，BigTable 也存在许多缺点 ，例如类似数据库中的 Join 操作效率太低 、只支持 string 的数据类型 ，不支持全表的排序运算 ，不支持多个表的关系运算 ，不支持多行的事务 ，不支持跨表的事务 ，对ACID 的支持有限等 ，但是由于 Google 云计算平台所承载的应用并不是以 OLTP 事务处理为重点 ， 这些缺点并不会产生严重的影响 。3.3 编程框架在传统 IT 系统中 ， 为了充分利用 UNIX 多任务操作系统的优势 ，并发执行 （concurrency）是一种常见的编程框

23、架 ，如采用多进程 、 多线程等技术以提高处理性能 （如图 9 所示 ），与 Google 采用的 Map-Reduce 编程框架相比 ，两者之间存在的差异主要在以下两方面 。 在并行执行模式下 ，数据是集中管理的 （通常是由一个关系型数据库系统 RDBMS 来负责完成 ）， 每个应用都可以直接操作数据库中的数据 ，由数据库系统图 8 Oracle RAC 的系统架构42电 信科学 2010 年第 1 期负责保证数据的一致性和完整性 。 在 Map-Reduce 模式下 ，由于数据是由每个节点分散进行管理的 ，不存在独立的 、集中的数据库系统 ，每个节点只能对自己所管理的数据进行操作 ， 因此

24、需要上层应用软件的干预 ，以保证跨节点的数据的一致性和完整性 。 在 Map-Reduce 模式下 ，增加了对任务的分解 Map 以及结果的规约 Reduce 等处理 环 节 ， 以 支 持 多 个worker 节点的并行处理 ， 同时还需要完成 worker 节点失效处理以及 worker 节点间的协调通信等工作 ，因此系统处理负荷有所增加 ， 但是考虑到大规模并行处理所带来的巨大优势 ，这种代价是完全值得的 。事 实 上 ，Map-Reduce 这种编程模型并不仅适用于Google 云计算平台 , 在多核和多处理器 、cell processor 以及异构机群上同样都有良好的性能 ，但是

25、，该编程模式仅适用于编写任务内部松耦合并能够高度并行化的程序 ， 如何改进该编程模式 ,使程序员能够轻松地编写紧耦合的程序 ，运行时能高效地调度和执行任务 ，是 Map-Reduce 编程模型未来的发展方向 ， 同时基于 Map-Reduce 的开发工具 Hadoop目前并不完善 ，特别是调度算法过于简单 ,降低了整个系统的性能 ，仍需要继续完善和提高 。4 Google 云计算平台的成本分析Google 云计算平台独特的技术架构对其总体成本产生了深刻的影响 ，主要体现在以下 5 个方面 。 由于采用了分布式的数据存储和数据管理方式 ，降低了对单个节点处理能力的要求 ，因此 Google 不需

26、要购买价格昂贵的 UNIX 服务器和 SAN 存储设备 ，而是采用廉价的消费级 x86 芯片和内置硬盘来构建服务器集群 ，大大减少了建设投资 。 根据中国移动研究院的测算 ，在满足相同处理能力的前提下 ，其设备投资只有 UNIX 平台的 1/6。 Google 云计算平台中除少量的管理节点以外 ， 各个节点均是同构的 ，同时承担数据存储 、数据管理和任务管理等功能 ，因此很容易实现设备的标准化 ，通过大批量采购专门定制的计算机主板 ， 裁减一切与计算无关的部件 （如显示器 、 外设接口甚至机箱外壳等 ）等方式 ，进一步地降低了设备投资 。 Google 云计算平台将硬件失效视为常态 ， 转而通

27、过软件容错的方式实现节点之间的自动切换来实现高可用性 ，大大减少了设备冗余 。 例如 ，假设单个节点的可靠性为 95%，传统 IT 系统采用 1+1 的备份方式时系统可靠性为 99.75%，但此时设备冗余为 100%，采用 100 个节点的 Google 云计算平台时 ， 达到相同的可靠性水平只需要增加 12%的设备冗余 ， 设备投资减少了 44%。 设备冗余的减少带来了设备利用率的提高 ，据 Google 宣称 ，其设备利用率可以达到一般企业的 280%。 基于并行计算的独特优势 ，Google 开发了优秀的负载均衡技术 ， 能够在全球范围通过不同数据中心的动态负载切换的方式保证业务连续性

28、， 因此对单个数据中心来说 ， 对电源和空调等配套设备的要求大大降低 。 Google 的数据中心仅在服务器主板上安装小型备用电池 ，舍弃了传统 IT 系统所必须的不间断电源系统 （UPS），同时通过将数据中心建设在山区图 9 Map-Reduce 模式和并行执行模式的对比43研 究与开发A Study of the Influence of Technical Architecture on the TotalCost of Google Cloud Computing PlatformSun Jian1，Jia Xiaojing2(1.China Mobile Communications

29、 Corporation, Beijing 100032, China;2. Central University of Finance and Economics, Beijing 100081, China)Abstract This paper compares the technical architecture between Google cloud computing platform and traditional IT system,and posts that the key of extremely low cost of google cloud computing p

30、latform is applying the “top-down” design method toinfrastructureconstruction.Key words cloud computing, cost, technology architecture (收稿日期 ：20091112)等寒冷地带 ， 将机房专用空调系统改为地下水冷却系统等方式 ， 大大降低了配套设备的建设投资和运营成本 。 据 Google 宣称 ， 其 6 个数据中心的平均PUE （电能利用率 ） 为 1.21， 年度最优数据中心的PUE 为 1.15， 在某一特定季度的 PUE 值为 1.13，而传统数据中

31、心的 PUE 一般为 3.0 或者更大 。 Google 云计算平台大量采用 Linux 等开源软件以及自行开发的专用组件 ，几乎不需要系统软件的投资 。对于传统 IT 系统来说 ，操作系统 、数据库和中间件等系统软件占建设投资的比重一般超过 15%， 而且还需要持续支付版本升级 、维护支持等运营成本 ，对成本的影响是不言而喻的 。基于以上分析我们可以得出判断 ，Google 宣称其极低的计算成本和存储成本是完全可行的 ， 同时这也充分表明了技术架构对 IT 系统成本所起到的决定性作用 。尽管 Google 云计算平台采用的数据存储 、 数据管理和编程框架等技术都存在不同程度的缺陷 ， 有些甚

32、至是非常严重的 ， 但是由于其云计算平台的建设目标是为某些特定的业务提供服务 ，因此这些技术缺陷不仅没有成为问题 ，反而在有效满足业务需求的同时 ， 极大地减少了建设投资和运营成本 。5 结束语通过对 Google 平台技术架构的分析 ，可以发现其 3 个基本特征 ，即 ：系统建立在大规模的廉价服务器集群之上 ；通过基础设施与上层应用程序的协同构建以达到最大效率利用硬件资源的目的 ；通过软件的方法实现节点的容错 ，这些都与基于高性能 UNIX 服务器集群的传统 IT 系统形成了强烈的反差 。实际上 ， 这种平台技术架构的差异来源于完全不同的设计思想 。 传统 IT 系统采用的是 “自下而上 ”

33、的设计方法 ，以逐层堆叠的方式承载上层应用 ， 强调基础设施对应用透明 ， 分层的集中管理以及通过工业标准实现异构设备的互联 ，其本质上是一种通用平台 ，而 Google 云计算平台则采用了 “自顶向下 ”的设计方法 ，即从上层应用出发 ，根据特定应用的业务特征对基础设施进行改造 （而不是一般意义的优化 ），其本质上是一种专用平台 ，这也是 Google 云计算平台具有极低的计算成本和存储成本的根本原因 。参考文献1 Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung. The googlefile system, http:/ Mike Burro

34、ws. The chubby lock service for loosely-coupleddistributed systems, http:/ Dean J, Ghemawat S. Distributed programming with mapreduce.Oram A,Wilson G, eds. Beautiful Code. Sebastopol:OReillyMedia, Inc., 2007:3713844 陈康 ,郑纬民 .云计算 :系统实例与研究现状 .软件学报 , 2009(5)5 陈全 ,邓倩妮 .云计算及其关键技术 .计算机应用 , 2009(9)6 NGBOSS1-CRM 技术规范 .中国移动通信企业标准 , 20097 云计算平台的并行数据挖掘工具对经分系统的业务支撑能力的研究 ,中国移动通信集团上海有限公司 , 200944