第十一讲流计算图计算辨析.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ?在循环的阶段0，左边集合中那些还未被匹配的顶点会发送消息给它的每个邻居请求匹配，然后会无条件的VoteToHalt。如果它没有发送消息，或者是所有的消息接收者都已经被匹配，该顶点就不会再变为active状态。 ?在循环的阶段1，右边集合中那些还未被匹配的顶点随机选择它接收到的消息中的其中一个，并发送消息表示接受该请求，然后给其他请求者发送拒绝消息。然后，它也无条件的VoteToHalt。 ?在循环的阶段2，左边集合中那些还未被匹配的顶点选择它所收到右边集合发送过来的接受请求中的其中一个，并发送一个确认消息。左边集合中那些已经匹配好的顶点永远都不会执行这个阶段，因为它们不会在阶段0发送任何消息。 ?最后，在阶段3，右边集合中还未被匹配的顶点最多会收到一个确认消息。它会通知匹配顶点，然后无条件的VoteToHalt，它的工作已经完成。 Execution of a cycle (A cycle consists of 4 supersteps) 作为第一个通用的大规模图处理系统，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/127776