Sep 28, 2018 · newsletter

Apache Spark gets a machine learning makeover

Machine learning on Spark: an abridged history

Apache Spark - the cluster computing framework that’s been throwing shade at MapReduce since 2011 - has always been a bit remarkable, because it bridged the divide between data engineering and data science. One of the great promises of Spark was that it would be easy, trivial almost, to scale machine learning and data science to arbitrarily large data. Seven years later, Spark has made its place in data science, but perhaps not in the way we originally hoped.

Spark’s big contribution was that it delivered a very elegant API for dealing with distributed collections of data, termed Resilient Distributed Datasets (RDDs). Compared to alternatives at the time, it was simple to use that API to write certain machine learning algorithms, and since those algorithms were built on RDDs; you got fault tolerance and scale for free. It wasn’t long until a machine learning library built on RDDs was born: MLlib.

Implementing performant, scalable machine learning algorithms in MLlib wasn’t quite as easy as just expressing the logic using RDD transformations, but in some cases it worked quite well. Spark, and by extension MLlib, work well when algorithms can be expressed in parallel, independent tasks that each work on independent chunks of data. Accordingly, MLlib has seen success and adoption with linear models, K-means clustering, decision trees, and some others. But some algorithms, most notably deep learning, are difficult to express using Spark.

In comparison to linear models, optimizing deep learning algorithms over distributed collections requires frequent communication between tasks. Further, deep learning is slow, if you don’t use a framework that has been heavily optimized for that exact use case. Tensorflow, PyTorch, MXNet, etc. all leverage accelerated hardware and heavily optimized C/C++ code to achieve reasonable efficiency. All this is to say that Spark and deep learning aren’t a very good match. So why are we talking about it?

Deep learning needs data (big data!) and that data often needs to be accessed through or pre-processed by Spark. That data is also messy and is probably stored across many datasets in many different storage platforms. Spark makes reading, aggregating, and joining these datasets less awful. So even if Spark isn’t heavily optimized for machine learning, the data that feeds these algorithms often goes through Spark first. This reality led many developers to ponder, “what if we could combine the heavily optimized ML/DL frameworks into Spark?” And with that, the family of XOnSpark libraries came to be.

But Spark hasn’t made it very easy to combine these other libraries, most of which are written in a combination of Python and C++, with Spark. There are three main shortcomings:

  • Moving data between Spark processes (JVM) and Python processes is inefficient
  • Spark task scheduling doesn’t take GPUs into account
  • Deep learning tasks need to constantly communicate gradient/weight updates between them, which is a Spark anti-pattern

Project Hydrogen makes Spark play nice with other ML frameworks

To address each of these issues, the open source community for Spark is undertaking a new initiative, dubbed Project Hydrogen, which is broken up into three main chunks, each designed to solve one of these shortcomings:

The goal of Project Hydrogen is to make it easy and efficient to build deep learning workflows that can run end to end in Spark. This is exciting!

Spark and deep learning can’t ignore each other, and that probably won’t change any time soon. Because of the current complexities, it’s best to avoid distributing deep learning training when possible. But we’re excited to see investment into scaling deep learning with Spark. There are so many great libraries for doing heavily optimized machine learning - PyTorch, Tensorflow, XGBoost, LightGBM - that it’s hugely beneficial to be able to scale these up with Spark.

Read more

Sep 28, 2018 · newsletter
Sep 17, 2018 · post

Latest posts

Jun 22, 2020 · post

How to Explain HuggingFace BERT for Question Answering NLP Models with TF 2.0

by Victor · Figure 1: In this sample, a BERTbase model gets the answer correct (Achaemenid Persia). Model gradients show that the token “subordinate ..” is impactful in the selection of an answer to the question “Macedonia was under the rule of which country?". This makes sense .. good for BERTbase. Recently, our team at Fast Forward Labs have been exploring state of the art models for Question Answering and have used the rather excellent HuggingFace transformers library. more
Jun 16, 2020 · notebook

Evaluating QA: Metrics, Predictions, and the Null Response →

by Melanie · A deep dive into computing QA predictions and when to tell BERT to zip it! In our last post, Building a QA System with BERT on Wikipedia, we used the HuggingFace framework to train BERT on the SQuAD2.0 dataset and built a simple QA system on top of the Wikipedia search engine. This time, we’ll look at how to assess the quality of a BERT-like model for Question Answering.
May 19, 2020 · notebook

Building a QA System with BERT on Wikipedia →

by Melanie · So you’ve decided to build a QA system. You want to start with something simple and general so you plan to make it open domain using Wikipedia as a corpus for answering questions. You want to use the best NLP that your compute resources allow (you’re lucky enough to have access to a GPU) so you’re going to focus on the big, flashy Transformer models that are all the rage these days.
Apr 28, 2020 · notebook

Intro to Automated Question Answering →

by Melanie · Welcome to the first edition of the Cloudera Fast Forward blog on Natural Language Processing for Question Answering! Throughout this series, we’ll build a Question Answering (QA) system with off-the-shelf algorithms and libraries and blog about our process and what we find along the way. We hope to wind up with a beginning-to-end documentary that provides:
Apr 1, 2020 · newsletter

Enterprise Grade ML

by Shioulin · At Cloudera Fast Forward, one of the mechanisms we use to tightly couple machine learning research with application is through application development projects for both internal and external clients. The problems we tackle in these projects are wide ranging and cut across various industries; the end goal is a production system that translates data into business impact. What is Enterprise Grade Machine Learning? Enterprise grade ML, a term mentioned in a paper put forth by Microsoft, refers to ML applications where there is a high level of scrutiny for data handling, model fairness, user privacy, and debuggability. more
Apr 1, 2020 · post

Bias in Knowledge Graphs - Part 1

by Keita · Introduction This is the first part of a series to review Bias in Knowledge Graphs (KG). We aim to describe methods of identifying bias, measuring its impact, and mitigating that impact. For this part, we’ll give a broad overview of this topic. image credit: Mediamodifier from Pixabay Motivation Knowledge graphs, graphs with built-in ontologies, create unique opportunities for data analytics, machine learning, and data mining. They do this by enhancing data with the power of connections and human knowledge. more

Popular posts

Oct 30, 2019 · newsletter
Exciting Applications of Graph Neural Networks
Nov 14, 2018 · post
Federated learning: distributed machine learning with data locality and privacy
Apr 10, 2018 · post
PyTorch for Recommenders 101
Oct 4, 2017 · post
First Look: Using Three.js for 2D Data Visualization
Aug 22, 2016 · whitepaper
Under the Hood of the Variational Autoencoder (in Prose and Code)
Feb 24, 2016 · post
"Hello world" in Keras (or, Scikit-learn versus Keras)


In-depth guides to specific machine learning capabilities


Machine learning prototypes and interactive notebooks

Explain BERT for Question Answering Models

Tensorflow 2.0 notebook to explain and visualize a HuggingFace BERT for Question Answering model.

NLP for Question Answering

Ongoing posts and code documenting the process of building a question answering model.

Interpretability Revisited: SHAP and LIME

Explore how to use LIME and SHAP for interpretability.


Refractor predicts churn probabilities for telecom customers and shows which customer attributes contribute to those predictions.


Cloudera Fast Forward is an applied machine learning reseach group.
Cloudera   Blog   Twitter