http://blog.csdn.net/pipisorry/article/details/43235263
Introduction
DPark是豆瓣开发的基于Mesos的开源分布式计算框架，是spark的python版克隆，Davids的作品，Beandb作者。是豆瓣刚开源的集群计算框架，类似于MapReduce，但是比其更灵活，可以用Python非常方便地进行分布式计算，并且提供了更多的功能以便更好的进行迭代式计算。DPark的计算模型是基于两个中心思想的：对分布式数据集的并行计算以及一些有限的可以在计算过程中、从不同机器访问的共享变量类型。DPark具有的一个很重要的特性：分布式的数据集可以在多个不同的并行循环当中被重复利用。这个特性将其与其他数据流形式的框架例如Hadoop和Dryad区分开来。
{logo是一条亚马逊河流域的地包天食人鱼，成群的食人鱼能够在一分钟内吃光一头牛，充分体现了划分简单任务群体协作的高效与世界的残酷}
官方中文wiki: https://github.com/jackfengji/test_pro/wiki
google group：https://groups.google.com/forum/#!forum/dpark-users
支持迭代计算的MapReduce框架PDF:http://velocity.oreilly.com.cn/2011/ppts/dpark.pdf
项目地址：https://github.com/douban/dpark/
与Spark的区别
Spark中使用一个线程运行一个任务，但是DPark受python中GIL的影响，选择使用一个进程来运行一个任务。Spark支持Hadoop的文件系统接口，Dpark只支持posix文件接口。
由于Python和Scala的区别和特性，他们之间有一些不同：
- 两者之间最重要的区别就是线程和进程的区别。在Spark中使用的是一个线程来运行一个任务，而DPark是用的进程。原因如下：在Python当中，由于GIL的存在，即使在多核机器上使用多个线程，这些线程之间也没有办法真正的实现并发执行，在现在的集群计算中，机器大多是多核的，Master会将一个任务分配到一个计算节点的一个CPU中运行，以充分利用每一台计算节点，但是由于GIL的存在，如果我们使用线程来运行每一个任务，那么会导致同一个计算节点上至多只有一个线程能够被运行，大大降低了计算的速度，所以我们不得不采用进程来运行每一个任务。而这个就导致了
cache之后在同一个计算节点的各个任务之间共享内存变得相对复杂，并会带来一些额外的开销，我们在努力使得这一开销尽量降低。 - 支持的文件系统不同。Spark使用了Hadoop框架中提供的关于文件系统的接口，所以只要Hadoop支持的文件系统和文件格式，Spark都能支持。而DPark无法直接使用Hadoop的代码和接口，所以只能使用Posix文件系统，或者为某种文件系统参照textFile实现特定的接口。目前DPark支持所有能以FUSE或者类似方式访问的文件系统，包括MFS、NFS等类似系统，HDFS有FUSE接口可以使用。DPark特别针对MFS文件系统实现了一种RDD，它可以绕过FUSE，得到文件的分布信息，方便进行IO本地优化。
from:http://blog.csdn.net/pipisorry/article/details/43235263
ref:DPark安装及相关资料整理