第十一讲流计算图计算.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 作为第一个通用的大规模图处理系统，pregel已经为分布式图处理迈进了不小的一步，这点不容置疑，但是pregel在一些地方也不尽如人意。 ?1.在图的划分上，采用的是简单的hash方式，这样固然能够满足负载均衡，但是hash方式并不能根据图的连通特性进行划分，导致超步之间的消息传递开销可能会是影响性能的最大隐患。 ?2.简单的checkpoint机制只能向后式地将状态恢复到当前S超步的几个超步之前，要到达S还需要重复计算，这其实也浪费了很多时间，因此如何设计checkpoint，使得只需重复计算故障worker的partition的计算节省计算甚至可以通过checkpoint直接到达故障发生前一超步S，也是一个很需要研究的地方。 ?3.BSP模型本身有其局限性，整体同步并行对于计算快的worker长期等待的问题无法解决。 ?4.由于pregel目前的计算状态都是常驻内存的，对于规模继续增大的图处理可能会导致内存不足，如何解决尚待研究。 PowerGraph将基于vertex的图计算抽象成一个通用的计算模型：GAS模型，分为三个阶段：Gather，Apply和Scatter。 ?1. Gather阶段，用户自定义一个sum操作，用于各个vertex，将vertex的相邻vertex和对应edge收集起来； ?2. Apply阶段各个vertex利用上一阶段的sum值进行计算更新原始值； ?3. Scatter阶段利用第二阶段的计算结果更新vertex相连的edge值。 由于vertex计算会频繁调用Gather阶段操作，而大多数相邻vertex的值其实并不会变化，为了减少计算量，PowerGraph提供了一种Cache机制，下面是PowerGraph机制下Page Rank计算的过程伪代码。 ?PowerGraph提出了一种均衡图划分方案，减少计算中通信量的同时保证负载均衡。与Pregel和GraphLab均采用的hash随机分配方案不同，它提出了一种均衡p-路顶点切割（vertex-cut）分区方案。根据图的整体分布概率密度函数计算顶点切割的期望值： ? 根据该期望值指导对顶点进行切割，并修改了传统的通信过程，具体如下图所示。 ?实验时，PowerGraph按同步方式不同分别实现了三种版本（全局同步，全局异步，可串行化异步）。 ?1. 全局同步与Pregel类似，超步之间设置全局同步点，用以同步对所有edge以及vertex的修改； ?2. 全局异步类似GraphLab，所有Apply阶段和Scatter阶段对edge或vertex的修改立即更新到图中； ?3. 全局异步会使得算法设计和调试变得很复杂，对某些算法效率可能比全局同步还差，因此有全局异步加可串行化结合的方式。 ?在差错控制上，依靠checkpoint的实现，采用GraphLab中使用的Chandy-Lamport快照算法。 ?通过将图计算模型进行抽象，设计实现均衡的图划分方案，对比三种不同方式下的系统实现，并实现了差错控制。 ?网上资料 –Pregel——大规模图处理系统/panfeng412/archive/2011/10/28/2227195.html –PowerGraph: Distributed Graph-Parallel Computation on Natural Graphs(OSDI12) /blog/static/127776163201312863021180/ –PageRank算法在Pregel和MapReduce两种计算模型中的思路/blog/static/1277761632012111043525435/ –被冷落的大数据热点：图谱分析/ccnews/12340.html ?论文资料 --Pregel: A System for Large-Scale Graph Processing * * * * * * * * * * * * * * * * * * * * * * * * * * * Pregel是由Google开发的一个用于分布式图计算的计算框架，主要用于图遍历（BFS）、最短路径（SSSP）、PageRank计算等等。共享内存的运行库有很多，但是对于Google来说，一台机器早已经放不下需要计算的数据了，所以需要分布式的这样一个计算环境。没有Pregel之前，可以选择用MapReduce来做，但是效率很低。下面简单介绍一下PageRank算法在Pregel