dpark用例以及前景

[Han JU]

Hi,

我们考察了分布式计算框架有一段时间了，在spark上也做了不少测试和评估。发现了dpark之后，觉得可能更适合我们这个python团队。有几个问题想请教大家：

  1. 想大致了解下dpark大规模使用的案例，比如在豆瓣内部，使用情况是如何的（部署，实现的计算，性能）？使用中主要遇到那些问题？

  2. 豆瓣有使用spark吗？

  3. 有同学使用dpark + amazon s3 这样的组合吗？我们的数据目前都在s3上面。

  4. 在项目本身的开发方面，下一阶段的计划是什么呢？

先谢谢各位了！

[田忠博(Zhongbo Tian)]

Hi Han,

对于豆瓣，我们有一个 1000+核， 2T+内存的私有计算集群，上面既有MooseFS分布式存储，同时也有Mesos资源调度系统，在这个集群上除了DPark的任务外也有基于MPI的任务和其他任务在执行。目前我们对这套系统的性能是满意的，我们并没有尝试Spark平台，因为基于的基础设施不同，可能相对的性能也难以比较。

我们现在的使用痛点有两个方面：

1. 资源管理和隔离，这个问题可能更多是Mesos方面的问题，DPark现在使用监控线程的方法来限制CPU和内存的使用，虽然可以解决大部分问题，但是依旧会有出问题的可能；另一方面在大型计算时往往磁盘IO和网络IO是瓶颈，堵塞的网络会造成很多问题，即便将这些IO放在Mesos中分配，也无法方便的限制任务的使用，即使限制了反而会导致系统吞吐量下降，这带来了一个两难问题。

2. DPark使用的推广， 虽然Spark/DPark有很简单易用的接口，但是由于编写时的数据流会经过重新切分组合成一个个Stage再分开计算，当Stage报错时，用户很难直观的了解到是哪个部分出现问题，要想可以追踪到问题点就要理解DPark的机制，而这对于用户的门槛有点过高。另外一些接口非常容易误用，导致占用过多资源、效率低下甚至导致计算集群不可用，如何让大家更了解DPark的工作方式，编写更优化的正确的程序是一个挑战

对于项目本身，我们会考虑更多的和Docker或者其他虚拟化机制结合，探索是否能更好的管控和隔离资源，另外也在考虑是否在接口和机制上有能让DPark更易(正确的)用的方法。这方面也希望能得到社区智慧的协助。

另外现在Davies也是Spark的核心开发者，如果希望在amazon s3上使用类似计算基础设施的其实也可以考虑 Spark 提供的pyspark和基于s3的基础设施。所谓举贤不避亲嘛，相信他们也能提供高效有力的商业化计算产品。

--
You received this message because you are subscribed to the Google Groups "DPark Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dpark-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Han JU]

非常感谢你的回复！

我们考虑dpark主要是因为python方面的部署我们已经相当有经验了，而且我们想对使用的框架有深入的了解（团队成员都能够读dpark的代码）。Spark或者pyspark的话，团队学习成本偏高。

目前考虑看看是不是能自己在dpark里加写一个和s3连接的模块（context.textFromS3(...)），写几个实际的job来测试一下。

在 2014年8月19日星期二UTC+2上午7时51分36秒，田忠博写道：

[田忠博]

Waiting for your pull request!

:-)

---
Windreamer

[Davies Liu]

Hey Han,

从你的描述来看，DPark 确实会比PySpark 更为合适一些，如果你们想深入了解其实现机制甚至根据自己的需要进行扩展。

PySpark 挺像Hadoop Streaming,
计算框架是Scala实现的（主要是计算模型，调度器，Shuffle，缓存等），PySpark 的大部分代码是序列化以及调用Java
API等。我最近在做一些性能优化以及改进对大规模数据的支持（比如单个任务的数据了超过内存规模时）。

DPark 跟 PySpark
相比互有优劣，如果它们能够保持兼容的API，用户选择和切换起来将会更容易。目前PySpark的API已经比较稳定（而且是开发时的重点注意事项），稳定也比较全面，让DPark
来兼容PySpark的API会更好一些。

DPark 在 MooseFS 和 Mesos 上运行得挺好，但对Hadoop以及各种云设施等基本没有支持，以后可以加强这块。

借助Python语言最近几年的进展，将DPark 和
PySpark的性能再提高几倍也是很有吸引力的，目前有多个选择，比如用Cython重新实现性能相关组件，使用PyPy，或者是使用numba等得JIT支持。这几个都值得尝试，最后哪个更合适还不知道。

Davies

--
- Davies

[muxueqz(张明源)]

Hi Davies,

依你描述，当前的PySpark效率可能还赶不上DPark？

如果有Pypy的方式，至少部署会方便点儿，现在numba的依赖太重了

明源
http://muxueqz.gitcafe.com
Twitter: @muxueqz

[田忠博]

我曾经简单的增加过一些pypy的支持，理论上现在DPark应该可以在pypy上运行。不过由于我们的部署下并没有pypy支持所以也没有深入的测试和改进。

---
Windreamer

[Davies Liu]

2014-08-19 19:00 GMT-07:00 muxueqz(张明源) <zhangmin...@gmail.com>:
> Hi Davies,
> 依你描述，当前的PySpark效率可能还赶不上DPark？

对于简单地Word Count 测试，DPark比 PySpark 快一倍，主要是PySpark多一层与JVM直接的开销（网络IO和序列化）。

> 如果有Pypy的方式，至少部署会方便点儿，现在numba的依赖太重了

但是目前PyPy中的某几个模块性能还不太行（比如cPickle和
itertools)，导致整体上用PyPy和CPython的性能相当，认真优化一下应该有不少改进空间吧。DPark依赖于PyZMQ，运行在PyPy中会有些不稳定。如果能够把pyzmq去掉会更容易一些。

[Davies Liu]

我当时的测试结果是整体上DPark在CPython和PyPy中的性能相当（互有快慢），现在PyPy应该更成熟点了，可以再看看。

[田忠博(Zhongbo Tian)]

zmq的部分我也想去掉, 只是暂时还没有时间动手

[muxueqz(张明源)]

嗯，我当时测试发现很多兼容问题，改了一下即使能跑，反而比CPython要慢

在 2014年8月20日 上午11:41，Davies Liu <davie...@gmail.com>写道：

[Davies Liu]

2014-08-19 19:00 GMT-07:00 muxueqz(张明源) <zhangmin...@gmail.com>:

> Hi Davies,
> 依你描述，当前的PySpark效率可能还赶不上DPark？
>
> 如果有Pypy的方式，至少部署会方便点儿，现在numba的依赖太重了

我最近开始注意numba， 看起来很有前途，把类似Julia的机制代入到Python，未来很有前途
DPark 和 PySpark 支持 Numba 应该会比 PyPy和 Cython 更合适些。

[田忠博]

在DPark里面放了一个Numba的Lazy Decorator，用户的函数可以用这个优化，DPark的Shuffle还没做

---
Windreamer

On 2014年8月21日 GMT+8上午8:38:20, Davies Liu <davie...@gmail.com> wrote:

2014-08-19 19:00 GMT-07:00 muxueqz(张明源) :
> Hi Davies,
> 依你描述，当前的PySpark效率可能还赶不上DPark？
>
> 如果有Pypy的方式，至少部署会方便点儿，现在numba的依赖太重了

我最近开始注意numba， 看起来很有前途，把类似Julia的机制代入到Python，未来很有前途
DPark 和 PySpark 支持 Numba 应该会比 PyPy和 Cython 更合适些。