云计算介绍

 

云计算介绍

 

许多数据信息中包含了十分重要的信息，以移动电话日志为例，某个用户在一个地点(机场)关机若干小时后在另一个地点(机场)开机表明该用户可能搭乘飞机旅行了，而连续变换基站表明该用户可能搭乘火车或汽车上旅行等等，通过分析和挖掘这些日志以，运营商可以发现用户的电话呼叫特征和规律，以探索新的业务增长机会、发现有离网倾向的用户等等。然而，庞大的数据量使得这种数据分析和挖掘越来越困难，例如中国移动到2009年10月的用户数突破5亿，假设每个用户平均每天拨打20个电话，每个呼叫产生200字节的日志，则所有用户一年的呼叫日志总量为5亿*365*20*200字节，即663TB，如此海量数据的存储和计算的需求大大超过了当今包括巨型机在内的单台计算机的存储和计算能力，云计算应运而生。云计算通常有以下一些特点：

 

 

首先，一个云计算机群通常由多个计算机节点组成(从几百到成千上万)，机群内的节点之间的耦合程度高于互联网上的松散耦合的众多计算机，又低于传统的并行大型机内的紧密耦合的节点。这使得云计算机群内的通信效率较高，可以达到较高的计算效率。

 

第二，云计算提供强大的数据存储和计算能力。例如，现在一个1000台机群的云计算机群可以提供高达4000TB的数据存储能力和500GB/s的数据处理能力。

 

第三，云计算提供很高的可靠性。根据不同的应用需求，云计算可以提供99.999%甚至更高的可靠性。云计算的高可靠性来自其良好的容错能力和强大的故障恢复能力。在云计算机群内，任何一个或若干个节点(包括控制节点)的故障既不会使得系统停止服务，也不会中止任何正在运行中的上层应用程序。

 

第四，云计算能够以非常低廉的成本提供上述服务，具有很高的性能价格比。良好的容错能力和快速强大的故障恢复能力使得云计算能够采用价格低廉的计算机(例如当前主流频率的处理器和主流容量的内存和硬盘等)和网络交换机，避免了高可靠硬件带来的高昂成本。

 

第五，云计算提供简单的编程模型和框架。要实现云计算的应用，应用程序开发者不需要编写调试分布式或者并行程序，甚至不需要有分布式或并行程序方面的知识，只要写简单的串行程序甚至是脚本，必要时云计算系统会自动把相关程序分发到几十、几百乃至几千个节点上自动并发运行。开发者也不需要考虑容错或故障恢复等等，因为在云计算系统内这些对应用程序是透明的。

 

第六，云计算系统具有平滑自我演进的特征(living & evolving)：与由同构节点机组成的大型机不同，云计算系统通常有异构节点组成，云计算系统的节点可以平滑地逐步升级替换，从而使得云计算系统的性能和性价比得以持续不断提高，避免了大型机的整体升级换代所带来的突发成本开销和突发的IDC机架以及电流需求。

 

云计算机群包括机房、节点计算机、网络交换机、分布式架构等设施，其中，分布式架构是其中的关键，其设计和实现有许多挑战和困难，我有幸从2005年开始关注这一领域，并随后在微软和百度从事相关的工作。

 

 

云计算分布式架构综述

 

传统的关系数据库由底层文件系统和上层表格系统构成，类似地，云计算也包含了分布式文件系统(如Google的文件系统GFS)和分布式表格系统(如Google的Bigtable)两个部分，其中分布式文件系统实现可靠、高效的数据存储和处理，分布式表格系统在分布式文件系统的基础上实现表的各种处理逻辑，例如查询、修改、扫描等。此外，鉴于开发和调试分布式程序有比较大的难度，实现高效的分布式程序挑战更大，因而云计算还有一个分布式计算系统(MapReduce)，通过它，云计算上的分布式程序开发变得易如反掌，运行效率却大大提升。MapReduce既可以运行在分布式的表格系统上，也可以直接运行在分布式文件系统上，达到很高的并行度，获得很好的效率。

 

云计算系统常常是单一主控机(single master)+多工作机(many workers)模式，worker实现数据的存储、读写、分析处理等，master保存部分或全部元数据、实现worker的任务分配、状态监控、负载平衡、故障监测和故障恢复等。Master常常使用heartbeat+lease或类似机制监控worker的状态，向worker定期发放lease，worker在lease有效期(例如几秒到几十秒)内才进行工作，lease失效后则停止工作。如果master发现某个worker在过去一段时间内没有响应或者出现其他异常，则不再向该worker发放新的lease，并在旧的lease到期后重新分配该worker上的任务。这使得master得以发现有故障的worker并将其从系统中剔除，并在适当的时候采取措施以避免数据丢失或者任务失败等等，也使得系统管理员不需要进行任何额外的操作就可以下线部分worker(例如机器维护、软件硬件升级、机器淘汰等等)。

 

如果没有其他措施，则云计算系统的单一master会成为整个系统的单点。为了避免这种现象的出现，云计算系统通常还有一个分布式选举系统(例如Google的Chubby)，master也不再是单一master，而是单一主master+几个辅master，辅master保持着对主master的准同步，一旦主master故障，则其中一个辅master会被选举并升级成为主master。这种选举和升级通常需要若干秒的时间，但由于worker在lease有效期内即使没有master也会继续工作，且应用程序对master的访问通过名字而不是IP地址，因此上层应用程序通常看不到这种切换，或者是一个短暂的停顿。

 

以上只是对云计算分布式架构的一个简单描述，在后续的文章中我还会对各个部分进行较为详细的说明。

 

云计算之分布式文件系统

 

云计算的分布式文件系统(如Google的GFS)是整个云计算的基石，提供上层表格系统所需的可靠和高效的数据存储，假设是：

l 容错与自动故障恢复是DNA

整个文件系统由许多廉价计算机组成，机器故障是常事而非例外，系统需要不停地进行自我检测和监控，发现故障机器并自动恢复；

l 系统存储大文件而非小文件

整个文件系统存储数百万数千万的100MB或更大尺寸的文件，而不是数十亿的KB尺寸小文件，支持对小文件的创建、读写，但不高效；

l 文件的主要修改是追加

文件系统支持高效的大尺寸数据追加，特别是来自多个用户的无锁并发追加，小尺寸的数据追加和数据的改写也支持，但不高效；

l 高效的大尺寸顺序读

大尺寸的顺序读数据十分高效，小尺寸随机读相对比较低效；

l 持续可用的网络带宽比低的单次读写延时更加重要

多数上层应用程序对数据吞吐量有较高的要求，但对单次读写时间没有很高的要求。保持持续可用的网络带宽比保证每次读写的低延时有更大的意义。

 

在云计算的分布式文件系统中，数据被分成固定大小的块，即chunk(在GFS中是64MB)。由于可靠性和性能的需求，每个chunk在系统中有若干份拷贝(缺省是3份)，保存在不同的worker上。此外，这3份拷贝通所在的worker通常位于不同的机架和不同的网络交换机，因此一个机架或交换机故障不会导致数据不可用。把多个拷贝分布到不同交换机上进一步提高了数据读出的可用网络带宽，增加了数据读出的性能，但却增加了写入时在不同交换机之间传输的数据量，增加了写入成本，由于数据的读远远多于对数据的写，这种做法提高了系统的总体性能。

 

与云计算架构的其他子系统一样，云计算的分布式文件系统采用了“单一master+多个worker”的结构，其中worker保存chunk数据的拷贝，master保存了文件和目录的名字空间、文件到chunk的映射、当前worker列表、chunk拷贝在当前worker上的分布等。此外，master还记录了worker的chunk数据大小、可用磁盘空间、数据读写次数等，并在必要的时候进行chunk迁移以便实现负载的相对平衡。

 

云计算的分布式文件系统还提供了客户端库，应用程序通过客户端库访问文件数据。例如，当客户端需要读出一个文件从某个位置开始的数据时，客户端库通过询问master获得该文件的指定位置所在的chunk以及该chunk所在的worker列表，客户端库再向其中的一个worker(通常是离该客户端网络距离最近的worker)发起读chunk(指定的偏移值和指定的长度)的请求，worker读出指定的数据后返回给客户端库，客户端库再返回给应用程序。

 

以上对云计算的分布式文件系统做了一个大致描述，后续文章还有更多的叙述。

 

 

云计算之分布式计算系统

 

云计算属于分布式系统，众所周知，并行程序的设计、编码和调试非常挑战，在云计算分布式系统中，由于网络延时(毫秒级)远远大于单机系统内延时(微秒级)、部件的不可靠性以及节点之间较松的耦合度(低于通常的并行大型计算机)和异构性，高效并行程序的设计和实现难度更大，极大地阻碍普通程序员使用云计算系统。为了解决这个问题，Google创造性地把Map/Reduce模型成功地应用到了云计算系统中，极大地降低了云计算系统应用程序的开发难度且提高了云计算系统的并行度和运行效率，这就是云计算的分布式计算系统，它的基本原理是：每个应用程序被分成map函数和reduce函数，都由应用程序开发者编写，map函数的输入是<key, value>对，输出是中间结果<key, value>对，云计算分布式计算系统对这些中间结果按reduce分组，然后传给对应的reduce函数，reduce函数以迭代器的方式接收这些中间结果并进行合并等处理，然后输出所需的内容。例如，以海量文档的单词个数的统计问题为例，map函数输出的中间结果可以是：<单词，“1”>，即：

Map(string key, string value)

{

对于文档中的每个单词w

      emit(w, “1”);

}

reduce函数则把所有的“1”加起来，最后输出：

Reduce(string key, iterator values)

//key: 一个单词

//values: 该单词对应的所有“1”

{

int num = 0;

for each v in values:

       num += atoi(v)

emit(itoa(num));

}

 

 

云计算的分布式计算系统的主要优点是：

l 应用程序开发者不需要设计、编写和调试并行程序

开发者只需要设计、编写和调试普通的串行程序，即map函数和reduce函数，调试通过后提交到云计算系统，由云计算分布式系统框架把它们分发到成百上千台计算机(云计算的worker)上运行，并汇总和返回运行后的结果。开发者甚至不需要有分布式或者并行程序方面的经验或背景；

l 高效率

云计算分布式计算系统的master根据用户设置自动把作业切分为许多map任务和reduce任务，然后以按需的方式分配map和reduce任务到所有的worker上，每个worker完成一个任务后就报告给master，master就给该worker再分配一个map或reduce任务，该worker执行新分配的任务…..，如此直到所有任务执行完；

l 适于异构机群

上述按需分配任务的方式使得每个worker的计算能力都能得到最大限度的发挥：快的worker执行更多的任务，慢的worker执行较少的任务；

l 容错

由于整个作业被切分成许多map任务和reduce任务，worker故障后，只要再次执行对应的map和reduce任务即可；master则定期记录检查点(checkpoint)，一旦master异常，新的master读入最后一次检查点，则整个作业可以最后一次检查点的基础上继续执行。

 

云计算的分布式计算系统也自身的局限性。云计算分布式系统的易用和高效建立Map/Reduce模型的基础上，Map/Reduce模型要求切分出来的map和reduce可以多次以任意顺序执行而没有副作用，等等。幸运的是，绝大部分应用能够适用于该模型，不适合的应用也常常能够找到可用的近似算法，这使得云计算系统在实际工作中发挥了巨大的作用。

 

尽管云计算的分布式计算系统是其中相对比较简单的部分，但也不是非常容易理解，后续文章还有更多的说明。

 

 

云计算之分布式表格系统

 

云计算的分布式表格系统依赖于下层的分布式文件系统(如Google的GFS)提供可靠和高效的数据存储，也是分布式文件系统的主要使用者。本文以Google的Bigtable为例来介绍云计算的分布式表格的基本结构，其数据模型是：

(row : string, column : string, time : int64) -> value : string

l 行(row)

行(row)是二进制串，最大长度为64KB(实际应用中，大部分行字符串为10~100字节)。对统一行内的数据的读或写总是原子的。分布式表格系统总是把整个表格按行(row)排序(字典序)，然后按整行动态切分，每个切分后的块称为一个子表(tablet，在Google的Bigtable中，每个子表一般不超过256MB)，子表也是分布式表格系统的worker加载/卸载和负载平衡的基本单元。在网页库表格中，行(row)是网页的URL，但其中的域名部分被颠倒了，例如maps.google.com/index.html变成了com.google.maps/index.html，这样使得域名相似的网页聚集在一起，由于域名相似的网页在内容上往往有一定的相似性，因此可以产生更高的压缩倍率，并使得一些应用程序更加高效。

l 列(column)

列按列族(column family)分组，同一列族内的单元格的内容常常相同，并用修饰词(qualifier)区分不同的单元格，即column = “family:qualifier”。一个表格内的列族个数是有限的(例如最多上百个)且一般由可打印字符组成，但修饰词(qualifier)的个数没有任何限制且可以是任意字符。例如，网页库表格中，content(网页内容)可以是一个列族，language(语言)可能是另外一个列族。出于进一步的性能优化的考虑，Bigtable还允许用户把内容相似或相关的列族组成局部群组(locality group)，同一局部群组内的列族的数据常常存放在一起，这样可以加快它们的访问速度；用户还可以把某些局部群组设定为装入内存，这样访问这些群组时就不需要访问磁盘。

列族是权限控制的基本单元：有些用户可以添加新数据、修改已经存在的数据，有些用户只能读已经存在的数据，还有一些用户连已经存在的数据都不能读。

局部群组则是数据压缩的基本单元，用户可以对不同的局部群组指定不同的压缩算法或者同一压缩算法的不同参数，等等；

l 时间戳

时间戳是64位整数，可以用来表示真正的时间(例如网页抓取的时间)，这时它的单位是微秒，时间戳也可以是用户指定的任意值。Bigtable允许用户(针对列族)指定保存最新的多少个时间戳版本或者从现在起多长时间内的版本(如一周以内所有版本)，例如，在网页库表格中设置为保留最新的3个版本，超出的版本则被垃圾回收；

 

Bigtable采用了3层B+树结构来存储表格数据，第三层为用户数据层(user data tablets)，第二层为元数据索引层(metadata tablets)，用来索引用户数据tablets，第一层为根索引层(root tablet)，用来索引第二层数据。根索引层和元数据索引层的主要数据被设置为装入内存，应用程序需要访问用户数据时，Bigtable会根据需要依次访问root tablet和metadata tablets，这使得系统仅仅在访问用户数据时才访问磁盘。

 

云计算的分布式表格系统是其中相对比较复杂的部分，这里以Bigtable为例做了十分简单的描述，后续文章还会有比较详细的叙述。

 

 

云计算系统的容错和故障恢复(1)

 

云计算属于分布式系统，许多因素导致系统异常：首先，云计算系统由成百上千的节点组成，节点的失效是常事。假如节点的平均无故障时间是3年，则一个1000节点的机群，平均每天可能有一个节点故障。从商业成本来看，使用普通和主流的计算机(CPU，内存、网络、硬盘等)比高可靠计算机的性能/价格比更高，更何况无论多么可靠的计算机也会出现故障。其次，电源、网络等其他硬件也会出现故障；第三，软件出故障的几率远远高于硬件；第四，各种人为因素，例如错误的操作，也导致故障。由于这些因素，云计算系统需要很好地处理各种原因导致的故障，自动从故障中恢复，并且不影响运行中的上层的应用程序：

 

l 多副本的数据

云计算分布式文件系统保存了数据的多个副本(例如，GFS缺省保存3份)，当某个副本失效后，分布式文件系统的master会在适当的时机启动副本复制，使得数据的副本数保持设定的数量，保证了数据的安全；

l Worker故障

分布式文件系统的worker可能出现故障，master通过内置的heartbeat/lease监控所有worker的状态，一旦确认某个worker故障，master会把该worker保存的数据的副本个数减一，以便系统在适当时机启动副本复制以保证数据不会丢失；

l Master故障

为了避免master成为系统的单点，master也有多个副本：其中一个是主master，其余为辅master，主master承担着master的职责，例如应答用户和worker的请求，记录操作日志等；辅master通过操作日志保持与主master的准同步。当主master发生故障后，在分布式选举协议作用下，一个辅master会升级成为主master，保证系统的继续运行；

l 应用程序容错

出于容错和故障恢复的原因，云计算系统的上层应用程序不能假设它正在或将要使用哪个worker，也不能假设数据存储在或将要存储到哪个worker上，当应用程序需要使用数据时，云计算客户端库将询问云计算系统的master获得数据副本所在的位置，并向其中一个副本(通常是与该客户端网络“距离”最近的)发出数据请求，如果该worker在开始或者中途出现故障或因为其他原因无法完成该请求，则云计算客户端库会自动转向另外一个副本，这对上层应用是完全透明的。

 

云计算系统的容错和故障恢复(2)

 

在前一篇文章中，我谈到了云计算采用了数据多个副本(缺省是3)，除了应对各种软件硬件故障外，多个副本还提高了云计算系统数据读服务能力：每个副本都可以独立提供读服务，由于多个副本通常分布在不同的网络交换机上，因此网络带宽得到更充分的利用。与此同时，多个副本增加了数据写入的成本：写入数据时要同时在多台机器上写入，占用了更多的磁盘空间，传输数据要跨多个网络交换机。由于通常情况下数据的读出次数远多于写入次数，这样获得了更好的整体性能。

 

一个问题是：为什么缺省用3个数据副本而不是2个或4个？让我们用一个非常简化的模型来分析使用3个副本时数据的可靠性如何，或者说，数据丢失的可能性有多大。为了简单起见，让我们把问题局限在节点计算机上，假设总共有N个节点计算机，它们的平均无故障时间都是M，云计算系统对一个数据副本丢失并进行复制的时间为T，则一台计算机在T时间内出故障的概率是T/M，不出故障的概率是(1-T/M)：

N台机器在该时间内都不出故障的概率是(1-T/M)的N次方；

N台机器在该时间内恰好有1台出故障的概率是：(1-T/M)的(N-1)次方*T/M*N；

N台机器在该时间内恰好有2台出故障的概率是：

(1-T/M)的(N-2)次方*T/M*T/M*N*(N-1)/(2*1)

因此，N台机器在该时间段内至少有两台机器故障的概率是：

P2(N, M, T)=1-都不出故障的概率-恰好1台出故障的概率

因此，N台机器在该时间段内至少有两台机器故障的概率是：

P3(N, M, T)=1-都不出故障的概率-恰好1台出故障的概率--恰好2台出故障的概率

因此假如N=1000，M=50,000小时，T=600秒，则

P2 (N=10台，M=50,000小时，T=600秒) = 5.0*10的-10次方；

P2 (N=1000台，M=50,000小时，T=600秒) = 6.1*10的-9次方；

P2 (N=5000台，M=50,000小时，T=600秒) = 1.4*10的-4次方；

 

P3 (N=10台，M=50,000小时，T=600秒) = 4.5*10的-15次方；

P3 (N=1000台，M=50,000小时，T=600秒) = 6.2*10的-9次方；

P3 (N=5000台，M=50,000小时，T=600秒) = 7.6*10的-7次方；

可以看出，当机器数量达到5000台时，至少3台机器出故障的概率低于百万分之一，而至少两台机器出故障的概率高于万分之一。因此采用3个数据副本时数据有比较高的可靠性。

 

当机器数量较小时，例如10台时，至少两台机器出故障的概率也是很低的，但是，如果采用2个副本，则当一台机器出现故障时，则该机器上保存的数据都变成单副本，因此云计算系统需要马上做出反应，复制这些数据以避免再有一台机器故障时导致的数据丢失。假如该计算机上保存了1TB数据，则即使剩下9台机器每秒复制50MB数据，则仍然需要1TB/(9*50MB)，约2230秒的时间，这将使得系统在较长时间内对外服务性能有明显下降。因此2个副本很少使用。

 

分享

0

顶

阅读(57)┊评论 (0)┊ 收藏(0)┊禁止转载 ┊ 顶▼┊打印┊举报

已投稿到：

排行榜

加载中，请稍候......

前一篇：区域分解的并行算法

后一篇：我们的软件STGS 1.0(时空相关分析及时空统计建模)