[PVLDB 12] GraphLab : 分布式机器学习大规模图处理系统 学习总结

        今天要讲的文章是PVLDB 2012年的一篇文章,Distributed GraphLab: A Framework for Machine Learning and Data Mining in the Cloud。本文主要解决的问题是:指数增长的机器学习和数据挖掘(MLDM,即Machine Learning and Data Mining)问题和日益成熟的MLDM技术,越来越需要一个能够在大型集群并行执行MLDM算法的系统。不幸的是,设计、实施和调试分布式MLDM算法,需要充分利用云平台,可能是非常具有挑战性的。这些需要MLDM专家去解决竞争、死锁、分布式状态和通信协议等问题,同时提出复杂的数学模型和算法。所以在当时这样的情况下,作者提出了高级分布式抽象概念,异步的,动态的,并行图计算:GraphLab。

1.BackGround

        在指数增长的机器学习和数据挖掘问题和日益成熟的MDLM技术的发展,我们越来越需要一个能够在大型集群并行执行MLDM算法的系统。那么我们如何去设计和实现一个并行机器学习系统呢?实现一个机器学习和数据挖掘系统存在很大的挑战。因为你需要去解决竞争、死锁、分布式状态和通信协议等问题,同时提出复杂的数学模型和算法。所以要解决这个问题,就需要提出另一个高级分布式抽象系统。

        现有的工作采用一种数据并行的做法,具体来说就是MapReduce计算框架,其中Map阶段的计算任务是独立的,可以独立运行,并且可以在没有任何交流的情况下在不同的机器上运行。然后Reduce阶段通过Shuffle操作将不同的数据经过网络传输和磁盘溢写,发送到Reduce Task中。在Reduce Task中进行reduce阶段。但是MapReduce计算框架对于机器学习来说是不适合的,因为机器学习框架一般都是采用一种迭代计算模型。计算任务要不断的迭代计算,直到算法收敛为止,计算任务才停止计算。MapReduce计算框架需要将中间结果写入到磁盘中,并且下次计算需要从磁盘中读取数据。这种做法对于迭代任务来说需要大量的额外开销。所以MLDM不适合用MapReduce计算框架来执行。 框架基于批量数据处理,如MapReduce [9]和Dryad [19],没有被设计应用于迭代计算,最近的项目如Spark [38]扩展了MapReduce和其他数据并行框架的迭代设置。然而,这些框架仍然不支持异步计算。

        为了解决实现一个机器学习和数据挖掘系统存在很大的挑战。作者提出了一种利用Graph-Parallel 的机器学习系统。作者提出了利用Graph-Parallel Abstraction抽象。

2. Graph Compution: Synchronous VS ASynchronous

        Bulk Synchronous Parallel Model: Pregel (Giraph):同步批量模型,每个任务做完之后要等待,等待所有任务都做完之后才能进入下一轮迭代。同步不批量模型一般采用Message-Passing的方式批量发送消息来提高系统整体性能。每轮迭代到下一轮迭代之间存在很明显的Barrier的限制。由于同步批量模型存在明显的Barrier的限制,每轮迭代到下一轮迭代之间存在严重的Barrier的开销。并且整个处理任务由最慢的任务占主导,也就是经常说到的水桶效应。


        所以同步批量模型对于机器学习来说是低效的。

        ASynchronous Parallel Model:异步执行模式就是每个顶点的计算任务互不干扰,当这轮迭代计算完成之后顶点任务可以马上进入到下一轮迭代计算中。这种计算模式极大的提高了系统整体性能,系统的整体并行性能得到大大提高,整个图处理模式不再受到最慢的顶点计算任务的限制。异步执行模式可以是更加有效率的。

        所以对于机器学习和数据挖掘来说,我们需要一个新的计算抽象,能够支持异步动态的计算抽象。所以作者就提出了分布式机器学习计算框架:GraphLab。GraphLab设计目标是专门为机器学习和数据挖掘考虑的。它利用了图数据的依赖、支持异步、迭代计算和动态计算特性。下面我们来介绍GraphLab的设计。

3. System Desgin

3.1 DataGraph

        GraphLab框架存储单向图的程序状态叫做数据图。数据图G =(V,E,D)是一个容器,用来管理我们用户定义的数据D。如下图所示:


3.2 Update Functions

        计算方式被编码在GraphLab框架的更新函数中。一个更新函数是一个无状态的过程,这个过程修改一个顶点作用域内的数据和调度未来执行在其他顶点上的更新函数。一个顶点v的作用域(用Sv表示)是存储在v上的数据,以及数据存储的所有相邻点和相邻边(图2(a))。

        GraphLab更新函数把一个点v和作用域Sv作为输入,并返回作用域内数据的新版本——顶点的集合T。


        在执行更新函数后,在Sv上的修改数据会被写回到数据图。顶点集T的每个顶点u最终更新执行为函数f(u,Su)依据执行语义描述。

4. GraphLab Execution Model

        GraphLab框架的输入包括数据图G =(V,E,D), 一个更新函数,一个将被执行初始顶点集合。当有顶点在T,该算法选择(第1行)和执行(第2行) 顶点,添加任何新的顶点回到T(第3行)。重复的顶点被忽略。最后数据图和全局值在完成后返回给用户。

        为了更有效的分布式执行,我们降低了执行共享内存GraphLab框架的要求,并且允许GraphLab运行时确定最佳的顶点执行顺序。例如,RemoveNext(T) 可以选择返回依照最小化网络沟通或延迟的顺序来执行顶点(见第4.2.2节)。GraphLab框架允许用户指定优先级对在T中的顶点,所以许多MLDM应用程序从优先级受益。GraphLab运行时可能会使用这些优先级结合系统级目标来优化顶点的执行顺序。


4.1 可串行化执行

        GraphLab为了防止数据竞争以及方便程序的调试、运行。GraphLab支持顶点程序的可串行化执行,也就是说防止相邻顶点同时运行顶点程序。

        一个实现可串行性的简单方法是确保同时执行的更新函数作用域不重叠。在[24]我们称之为完全一致性模型(见图2(b))。然而,完全一致性同时限制了潜在的并行性,执行更新函数必须至少两个顶点(见图2(c))。然而,对于许多机器学习算法,更新功能不需要完整的读/写访问所有的数据作用域的权限。例如,PageRank更新只需要读访问边和相邻的顶点的权限。为了提供更大的并行性,同时保留可串行性,GraphLab 定义了边一致性模型。边一致性模型确保每个更新函数独占读写访问顶点和相邻的边,但只读访问相邻的点(图2(b))。因此,边缘一致性模型也在不断增加并行性,通过允许更新函数使用少量重叠作用域来安全并行运行(见图2(c))。最后,点一致性模型允许并行运行,所有更新功能提供最大的并行性。


4.2 染色引擎

        为了实现可串行执行,就必须要确定一种机制,来防止相邻顶点程序同时运行。这样如何去调度顶点程序来防止相邻顶点同时运行成为了一种挑战。染色引擎就是用来解决这个问题的:每个顶点分配一个颜色,这样没有相邻的顶点共享相同的颜色。给定一个数据图的顶点着色情况,我们可以通过同步执行顶点集合T中相同颜色的所有顶点,然后继续下一个颜色,来满足边缘一致性模型。

        我们可以仅通过改变顶点的颜色,满足其他一致性模型。完整的一致性模型是满意的通过构造一个二阶顶点着色(即没有顶点分享相同的颜色在任何两个邻居的之间)。顶点的一致性模型是通过设定所有顶点为相同的颜色来实现的。而最优图着色是NP难题,一个合理的高质量着色使用启发式方法图形着色可以快速构建(如贪心的着色)。此外,许多MLDM问题生成带有琐碎的颜色的图表。例如,许多优化问题在MLDM自然表达为双边(two-colorable)图表,而基于模板模型的程序可以很容易的使用模板[12]。

4.3 分布式锁引擎

        当染色引擎满足分布式GraphLab框架(第3节),它不提供足够的调度灵活性为许多有趣的应用程序。此外,它是以图着色的可用性为先决条件,这可能并非总是有效的。为了克服这些限制,我们介绍扩展了用于共享内存引擎的技术的分布式互斥锁引擎。

        我们通过实现分布式互斥读写锁关联每个顶点。不同的一致性模型可以使用不同的锁协议实现。顶点  的一致性是通过获取每个请求中心顶点作用域的写锁来完成的。边一致性是通过在中央顶点获取写锁,在相邻的顶点获取读锁。最后,完全一致性是通过获取中央顶点和相邻顶点的写锁来实现。通过依照有顺序的规范秩序的方式获取锁而避免死锁。我们依照顶点id的机器id来引用(所有者(v),v),因为这允许在一个远程的机器的所有锁可以被请求通过单个消息。

猜你喜欢

转载自blog.csdn.net/qq_21125183/article/details/80678187