spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xiangrui Meng <m...@databricks.com>
Subject Re: Integrating ML/DL frameworks with Spark
Date Tue, 08 May 2018 04:59:54 GMT
Thanks Reynold for summarizing the offline discussion! I added a few
comments inline. -Xiangrui

On Mon, May 7, 2018 at 5:37 PM Reynold Xin <rxin@databricks.com> wrote:

> Hi all,
>
> Xiangrui and I were discussing with a heavy Apache Spark user last week on
> their experiences integrating machine learning (and deep learning)
> frameworks with Spark and some of their pain points. Couple things were
> obvious and I wanted to share our learnings with the list.
>
> (1) Most organizations already use Spark for data plumbing and want to be
> able to run their ML part of the stack on Spark as well (not necessarily
> re-implementing all the algorithms but by integrating various frameworks
> like tensorflow, mxnet with Spark).
>
> (2) The integration is however painful, from the systems perspective:
>
>
>    - Performance: data exchange between Spark and other frameworks are
>    slow, because UDFs across process boundaries (with native code) are slow.
>    This works much better now with Pandas UDFs (given a lot of the ML/DL
>    frameworks are in Python). However, there might be some low hanging fruit
>    gaps here.
>
> The Arrow support behind Pands UDFs can be reused to exchange data with
other frameworks. And one possibly performance improvement is to support
pipelining when supplying data to other frameworks. For example, while
Spark is pumping data from external sources into TensorFlow, TensorFlow
starts the computation on GPUs. This would significant improve speed and
resource utilization.

>
>    - Fault tolerance and execution model: Spark assumes fine-grained task
>    recovery, i.e. if something fails, only that task is rerun. This doesn’t
>    match the execution model of distributed ML/DL frameworks that are
>    typically MPI-based, and rerunning a single task would lead to the entire
>    system hanging. A whole stage needs to be re-run.
>
> This is not only useful for integrating with 3rd-party frameworks, but
also useful for scaling MLlib algorithms. One of my earliest attempts in
Spark MLlib was to implement All-Reduce primitive (SPARK-1485
<https://issues.apache.org/jira/browse/SPARK-1485>). But we ended up with
some compromised solutions. With the new execution model, we can set up a
hybrid cluster and do all-reduce properly.


>
>    - Accelerator-aware scheduling: The DL frameworks leverage GPUs and
>    sometimes FPGAs as accelerators for speedup, and Spark’s scheduler isn’t
>    aware of those resources, leading to either over-utilizing the accelerators
>    or under-utilizing the CPUs.
>
>
> The good thing is that none of these seem very difficult to address (and
> we have already made progress on one of them). Xiangrui has graciously
> accepted the challenge to come up with solutions and SPIP to these.
>
>
I will do more home work, exploring existing JIRAs or creating new JIRAs
for the proposal. We'd like to hear your feedback and past efforts along
those directions if they were not fully captured by our JIRA.


> Xiangrui - please also chime in if I didn’t capture everything.
>
>
> --

Xiangrui Meng

Software Engineer

Databricks Inc. [image: http://databricks.com] <http://databricks.com/>

Mime
View raw message