Pregel_A System for Large-Scale Graph Processing

Pregel: A System for Large-Scale Graph Processing

Abstract

许多实际应用问题中都涉及到大型的图算法。比如网页链接关系和社会关系图等。这些图都有相同的特点：规模超大，常常达到数十亿的顶点和上万亿的边。这么大的规模，给需要在其上进行高效计算的应用提出了巨大的难题。在这篇论文中，我们将提出一种适合处理这类问题的计算模式。将程序用一系列的迭代来描述(Programs are expressed as a sequence of iterations)，在每一次迭代中，每一个顶点都能接收来自上一次迭代的信息，并将这些信息传送给下一个顶点，并在此过程中修改其自身的状态信息，以该顶点为起点的出边的状态信息，或改变整个图的拓扑结构。这种面向顶点的方法足够的灵活，可以用来描述一系列的算法。这种计算模式被设计的足够高效，可扩展，和足够的容错，并在有上千台的计算节点的集群中得以实现。这种模式中隐式的同步性(implied synchronicity)使得它对程序的确认变得简单。分布式相关的细节已经被一组抽象的API给隐藏。而展现给人们的仅仅是一个表现力很强，很容易编程的大型图算法处理的计算框架。

Keywords

分布式计算，图算法

1．Introducetion

Internet使得Web graph成为一个人们争相分析和研究的热门对象。Web 2.0

更是将对社会关系网的关注推向高潮。同时还有其他的大型图对象（如交通路线图，报纸文献，疾病爆发路径，以及科学研究的发表文章中的引用关系等），也已经被研究了很多年了。同时也有了许多相应的应用算法，如最短路径算法，page rank理论演变而来的图相关算法等等。同时还有许多其他的图计算问题也有着

相当的实际价值，如最小切割，以及连通分支等相关问题。

事实证明，高效的处理大型图对象的计算是一件极具挑战性的事情。图算法常常暴露出类似不高效的本地内存访问，针对每个顶点的处理过少，以及在计算过程中改变并行度等问题。分布式的介入更是加剧了locality的问题，并且加剧了在计算过程中机器发生故障而影响计算的可能性。尽管大型图形无处不在，其商

业应用也非常普及，但是一种通用的，适合各种图算法的大型分布式环境的实现到目前还不存在。

要实现一种大型图计算的算法通常意味着要在以下几点中作出选择:

1.为特定的图应用定制相应的分布式框架。这通常要求对于新的图算法或者图相关的应用，就需要做大量的重复实现，不通用。

2.基于已有的分布式计算平台，而这种情况下，通常已有的分布式计算框架并不是完全适合图计算的应用。比如mapreduce就是一个对许多大规模应用都非常合适的计算框架。它也常常被用来解决大型图的问题，但是通常对图算法来说都不是最优的解决方案，常常也不是最合适的方案。对数据处理的基本模式，通常有聚合(facilitate aggregation)以及类SQL的查询方式，但这些扩展方式通常对大型图计算这种消息传递模型来说并不理想。

3.使用单机的图算法库，如BGL，LEAD，NetworkX，JDSL，Standford GraphBase，FGL等，但这种单机的方式就对图本身的规模有了很大的限制。

4.使用已有的并行图计算系统。并行的BGL和CGM 图计算库就提供了并行图计算的方式。但是对容错等其他大规模分布式系统中非常重要的一些方面的支持却并不好。

以上的这些选择都或多或少的存在一些局限性。为了解决大型图的分布式计算问题，我们搭建了一套可扩展，有容错机制的平台，该平台提供了一套非常灵活的API来描述各种各样的图计算。这篇论文将描述这套名为Pregel的系统，并分享我们的经验。

对Pregel计算系统的灵感来自Valiant提出的Bluk Synchronous Parallell mode。Pregel计算由一系列的迭代(iterations)组成，每一次的迭代被我们称之为”superstep”。在每一次的superstep中，计算框架都会invoke用户针对每个顶点自定义的函数，在概念上，这个过程是并行的。该用户自定义函数定义了对于一个顶点V以及一个superstep S中需要执行的操作。该函数可以将前一轮迭代（S-1）中发送给V的message读入，并将该message通过下一轮迭代（S+1）发送给另外的顶点，并且在此过程中修改V的状态以及其出边的状态。message 通常通过顶点的出边发送，但一个消息可能会被发送到许多已知ID的特定的顶点上去。

这种面向顶点的计算方法很容易让人联想起mapreduce，因为他们都让用户只需要关注其本身的执行逻辑，分别独立的执行各自的处理过程，而系统都将负责处理其余剩余的大量复杂的事情。这种计算模式非常的适合分布式化的实现：它没有限制每个superstep的执行顺序，所有的通信都仅限于S到S+1之间。

这种计算模式在同步性上的特点使得在实现算法时推算程序执行的语义变得简单，并且能够在Pregel系统层面保证程序在异步系统中是天然的对死锁以及临界资源竞争免疫的。理论上，Pregel程序的性能应该即使在与足够并行化的异步系统的对比中都有一定的竞争力。因为通常情况下图计算的应用中顶点的数量要远远大于机器的数量，所以必须要平衡各机器之间的负载，已达到各个superstep之间的同步不会增加额外的延迟。

本文接下来的结构如下：Section2主要描述Pregel模式；Section3描述其C++的API；Section4讨论实现方面的情况，如性能和容错等；Section5中将例举几个实际应用；Section6将提供性能的对比数据；最后是其他一些相关工作和将来的方向。

2．Model of Computation

在Pregel计算模式中，输入是一个有向图，该有向图的每一个顶点都有一个相应的由String描述的vertex identifier。每一个顶点都有一些属性，这些属性可以被修改，其初始值由用户定义。每一条有向边都和其源顶点关联，并且也拥有一些用户定义的属性和值，并同时还记录了其目的顶点的ID。

一个典型的Pregel计算过程如下：读取输入，初始化该图，当图被初始化好后，运行一系列的supersteps，每一次superstep都在全局的角度上独立运行，直到整个计算结束，输出结果。

在每一次的superstep中，顶点的计算都是并行的，每一次执行用户定义的同一个函数。每个顶点可以修改其自身的状态信息或以它为起点的出边的信息，从前序superstep中接受message，并传送给其后续superstep，或者修改整个图的拓扑结构。边，在这种计算模式中并不是核心对象，没有相应的计算运行在其上。算法是否能够结束取决于是否所有的顶点都已经“vote”标识其自身已经达到“halt”状态了。在superstep 0，所有顶点都会被置于active状态，每一个active的顶点都会在计算的执行中在某一次的superstep中被计算。顶点通过