Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

有没有考虑过先实现一下Apache Spark里的RDD,在此基础上实现分布式机器学习算法? #1

Open
soulmachine opened this issue Jan 16, 2014 · 7 comments

Comments

@soulmachine
Copy link

我用Spark写过两个机器学习算法,Naive Bayes classifier, Random forest, Apache Spark 的 RDD 是一个比Map-reduce和MPI更好用的分布式框架,表达力也很强。

看样子你目前是想直接使用golang 的 channel 实现分布式机器学习算法?这样的话,跟直接用MPI差不多,太底层,写的代码会很罗嗦。

方便程度:Spark > Hadoop > MPI, 代码简洁度:Spark > Hadoop > MPI,限制程度:MapReduce > Spark > MPI,MPI是最自由的,写起来也是最麻烦的,所以任何分布式计算框架,都似乎是在抽象和性能之间进行折中。

只有用更高层的抽象工具,写机器学习算法才会更简洁。

对了,Apache Tez,也是一个DAG计算框架(跟Spark很类似,本质上都是DAG),你也可以看看。还有MSRA的 Dryad,等等。我个人觉得Spark的RDD平衡的更好,也有非常成熟的实现,就是Spark本身。

关于用 golang 实现 Spark的RDD,有一个项目在此 Gopark,不过不太活跃,但是可以联系作者,一起做形成合力,照目前这种活跃度,项目完工遥遥无期。。。。

@huichen
Copy link
Owner

huichen commented Jan 16, 2014

感谢你的建议,spark看上去很强大,我花时间研究一下。在Google待久了被内部的那套系统束缚住反而对开源界的好东西关注不足。

其实我在自己用go实现一个分布式任务调度系统,而且想在其上实现一套分布式文件存储和数据库,不过因为没多余时间所以进度及其缓慢。

让我花点时间研究一下再详细答复你。

@soulmachine
Copy link
Author

恩,好,分布式调度系统,分布式文件系统,等,都是学术界研究了多年的东西,有一些成熟的开源项目或论文了,可以选择一个好的去实现。

例如,

  • 分布式调度系统有 Sparrow
  • 分布式文件系统,就更多了,Linux上的Ceph, Lustre;OpenStack 里的Swift;Hadoop上的HDFS
  • NoSQL数据库,耳熟能详的有redis, MongoDb, Cassandra等

可以重新实现轮子,但是不可以重新发明轮子 :)

@huichen
Copy link
Owner

huichen commented Jan 17, 2014

看了下Spark,很强大,但感觉弥勒佛不适合走这条路。针对这个项目,可以有三种发展模式:

  1. Docker + 自开发的一个轻量级并行调度系统 + 弥勒佛 RPC 服务器
  2. Spark/gopark(或者什么其它的并行框架) + 弥勒佛
  3. (这实际上不是一个选项,单纯为了比较列在这里)在Spark里实现一个分布式机器学习框架

和2相比1有下面的优势

  • 1是一个纯GO的开发环境
  • gopark不知道何时可以达到可用的程度
  • 选项1里的那个轻量级调度系统也可以用在悟空引擎里面
  • 弥勒佛未来的开发重点希望放在在线学习和神经网络上,走RPC服务这条路更灵活,Spark可能过于specialized了
  • 2和3相比,2完全没有优势,而且Spark里的机器学习包也有人在开发
  • 感觉1是最简洁的实现方式,Spark的优势在RDD和编程模型,但用在弥勒佛中有些overkill

总之Spark做分布式学习是很好的,但并不适合弥勒佛。这个项目刚刚起步,希望核心的东西还是逐步自我完善出来比较好,而不是照搬现有解决方案。否则未来over engineering可能会成为一个问题,而且一旦捆绑住想抽离就不容易了。

@soulmachine
Copy link
Author

恩,你说的有道理,2相比3,完全没优势,不过我的意思也不是方案2,不是完整实现Spark,而是实现它论文里的RDD,这个是Spark的核心,比MapReduce 抽象程度高,表达力更强,性能也高。

我的重点关注的问题是,编程接口,即抽象工具。裸用MPI, socket之类的API来写分布式算法,太麻烦太容易出错了。就像设计一门新语言一样,编程范式是最重要的,性能什么的可以慢慢优化。

做一个分布式算法,我所了解的编程接口有:

  1. MPI,这种方法比较底层,编程繁琐,类似于C语言至于Java语言。目前有人提出了MPI的改进版,把接口变得更易用了,MPI-D,但是抽象程度依然不高。国内的公司例如百度,目前基本还是用MPI,因为他们人多,可以慢慢写。Google估计是在用MapReduce的下一代吧

  2. Map-Reduce,比较成熟的实现是Hadoop。这个抽象工具比较不错,Mahout基于Hadoop实现了一些算法,但是,已经证明有些机器学习算法不适合用Map-Reduce来表达,Mahout 0.9相比0.8,就少了几个算法,官方的说法是用mapreduce无法写出高性能的实现,就去掉了,见首页原文:

    As the project moves towards a 1.0 release, the community is working to clean up and/or remove parts of the code base that are under-supported or that underperform as well as to better focus the energy and contributions on key algorithms that are proven to scale in production and have seen wide-spread adoption. To this end, in the next release, the project is planning on removing support for the following algorithms unless there is sustained support and improvement of them before the next release.

  3. RDD,比较成熟的实现是Spark。根据我的亲自使用,以及官方的宣称,它不仅能表达MapReduce,还能表达更多,表达力更强,性能也更好(因为是内存计算)。

你倾向于选择方案1,

Docker + 自开发的一个轻量级并行调度系统 + 弥勒佛 RPC 服务器

是不是意味着,弥勒佛里的分布式机器学习算法,都是裸用 socket 或 RPC ?这样应该会太底层,代码量巨长吧。因为你没有提供高级的抽象工具。

我预想的编程接口(抛开调度系统,因为他们跟编程接口无关),有以下几个:

  1. netchan. Go语言标准库之前是有这个包的,1.0发布的时候,去掉了,Rob Pike说是要重新重构。这个东西是个好东西啊,类似于Erlang里的OTP, Scala里的AKKA。用它也比MPI强很多。
  2. MapReduce. 即用Go实现分布式MapReduce,然后在MapReduce之上写分布式算法。但是这条路被Mahout已经证明走不通,很多算法用MapReduce写出来性能不高。
  3. RDD. 用Go实现RDD,在此基础上实现分布式机器学习算法。这条路目前看不到天花板,RDD表达能力很强,出了表达MapReduce这种模式,还能表达其他的。

@soulmachine
Copy link
Author

我在知乎上开了一个讨论贴子,写分布式机器学习算法,哪种编程接口比较好?

@xiaods
Copy link

xiaods commented Mar 11, 2015

这个看完,让我有点激动。我目前构建的系统是基于Mesos+Spark as service。实施中全部使用Docker,我本身是Docker commiter,所以没什么问题。但我要给国内客户提供MLS服务,所以想使用golang之类的匹配我的技术栈,不然就要去看scala了。目前项目有什么进展吗?如何用这个。

@pashifika
Copy link

这个项目已经凉了么?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants