BSP模型与实例分析 [转]

一、BSP模型概念

BSP(Bulk Synchronous Parallel ，整体同步并行计算模型)是英国计算机科学家Viliant在上世纪80年代提出的一种并行计算模型。Google发布的一往篇论文(《Pregel: A System for Large-Scale Graph Processing 》)使得这一概念被更多人所认识，据说在Google 80%的程序运行在MapReduce上，20%的程序运行在Pregel上。和MapReduce一样，Google并没有开源Pregel，Apache按Pregel的思想提供了类似框架Hama。

关于BSP，一般是下边这张图:

光看这个图理解起来还是蛮吃力的。下面按我的理解做一些解释：

1. Processors指的是并行计算进程，它对应到集群中的多个结点，每个结点可以有多个Processor；
2. Local Computation就是单个Processor的计算，每个Processor都会切分一些结点作计算；
3. Communication 指的是Processor之间的通讯。我们接触的图计算往往需要做些递归或是使用全局变量，在BSP模型中，对图结点的访问分布到了不同的Processor中，并且往往哪怕是关系紧密具有局部聚类特点的结点也未必会分布到同个Processor或同一个集群结点上，所有需要用到的数据都需要通过Processor之间的消息传递来实现同步；
4. Barrier Synchronization 又叫障碍同步或栅栏同步。每一次同步也是一个超步的完成和下一个超步的开始；
5. Superstep 超步，这是BSP的一次计算迭代，拿图的广度优先遍历来举例，从起始结点每往前步进一层对应一个超步。
6. 程序该什么时候结束呢？这个其实是程序自己控制，一个作业可以选出一个Proceessor作为Master，每个Processor每完成一个Superstep都向Master反馈完成情况，Master在N个Superstep之后发现所有Processor都没有计算可做了，便通知所有Processor结束并退出任务。

二、Hama的BSP实现原理

Apache Hama可以说是一个利用Hadoop的基础设施自己封装的一个BSP计算模型的实现，它虽然跟Hadoop有关但是不使用Hadoop集群，而是用的自己的集群。依赖ZooKeeper分布式锁作为作业的调度控制，可以用HDFS/Local/HBase等文件系统作输入输出。

(一)   基本结构

 

Hama的集群由一个BSPMaster和多个互不关联的GroomServer作计算结点组成，HDFS和Zookeeper都可以是独立的集群。启动从BSPMaster开始，如果是master会启动BSPMaster、GroomServer两个进程，如果只是计算结点则只会启动GroomServer，启动/关闭脚本都是Master机器远程在GroomServer机器上执行。下面分别解释下几个基本概念：

1. BSPMaster 即集群的主，负责了集群各GroomServer结点的管理与作业的调度，就我所知它还存在单点的问题。相当于Hadoop的JobTracker或HDFS的NameNode；
2. BSPGroomServer 即计算结点，GroomServer是物理上的概念，也相当于是BSPPeer的宿主，负责了BSPPeer对外的消息通讯、机器状态报告等，相当于Hadoop的TaskTracker或HDFS的DataNode，在集群中往往和DataNode一一对应的部署（底层机制就是Hadoop的TaskTracker）；
3. BSPPeer 即BSP中的Processor，当作业过来的时候，任务jar包和配置会被同步过来，GroomServer就启动一个独立JVM进程来执行一个BSPPeer实例，就像TaskTracker的作法一样。BSPPeer是分布式计算中的逻辑计算单元；
4. BSPJobClient 作业客户端，职责是将作业所需jar以及配置提交给BSPMaster
5. Zookeeper 分布式锁。用于实现Barrier Synchronisation机制。在ZK上，进入BSPPeer主要有进入Barrier和离开Barrier操作，所有进入Barrier的Peer会在zk上创建一个EPHEMERAL的node（/bsp/JobID/Superstep NO./TaskID），最后一个进入Barrier的Peer同时还会创建一个ready node(/bsp/JobID/Superstep NO./ready)，Peer进入阻塞状态等待zk上所有task的node都删除后退出Barrier

(二)   输入与输出

Hama的输入输出文件格式、分块、文件传输等机制都跟HDFS是一样的，也都是K-V对，派生自Writable。输入的K-V对为结点（VertexWritable）和邻接结点集合(VertexArrayWritable)。

(三)   消息通讯

图计算涉及到大量消息传递，Hama不完全是实时传送，消息的传输发生在Peer进入同步阶段后，并且对同一个目标GroomServer的消息进行了合并，两个物理结点之间每一次超步其实只会发生一次传输

(四)   图算法运用

Hama其实只提供了一个图计算框架，算法都是需要自己去实现的。理想的情况是图文件分块，Peer尽可载入本地文件作计算，这样即加快了图载入时间也减少了网络传输。不过事实是可能不能这样假设，为使结构尽更简单，对图的切割往往只是将结点用简单的Hash算法分布到Peer上，不能对图作任何局部聚类的假设。

 (下一篇：求最短路径的实例分析)

参考资料：

http://incubator.apache.org/hama/  (Hama主页)

http://kowshik.github.com/JPregel/pregel_paper.pdf  (Pregel论文)

http://ww2.cs.mu.oz.au/498/notes/notes.html  (一些非常好的分布式图文档，其中讲BSP模型 那篇很好)

http://people.apache.org/~edwardyoon/documents/pregel.pdf  (Google Pregel,A System for Large-Scale Graph Processing)

https://github.com/mesos/spark/pull/48  (Spark项目)

http://www.open-open.com/doc/view/3f5541aeece041c7a8331354df2b14a0  (Beyond MapReduce：图计算框架概览,原出处丢失)

转自：http://rdc.taobao.com/team/jm/archives/1803