# Scala & Spark Bindings:

*Bringing algebraic semantics*

## What is Scala & Spark Bindings?

In short, Scala & Spark Bindings for Mahout is Scala DSL and algebraic optimizer of something like this (actual formula from **(d)spca**)

`\[\mathbf{G}=\mathbf{B}\mathbf{B}^{\top}-\mathbf{C}-\mathbf{C}^{\top}+\mathbf{s}_{q}\mathbf{s}_{q}^{\top}\boldsymbol{\xi}^{\top}\boldsymbol{\xi}\]`

bound to in-core and distributed computations (currently, on Apache Spark).

Mahout Scala & Spark Bindings expression of the above:

val g = bt.t %*% bt - c - c.t + (s_q cross s_q) * (xi dot xi)

The main idea is that a scientist writing algebraic expressions cannot care less of distributed
operation plans and works **entirely on the logical level** just like he or she would do with R.

Another idea is decoupling logical expression from distributed back-end. As more back-ends are added,
this implies **"write once, run everywhere"**.

The linear algebra side works with scalars, in-core vectors and matrices, and Mahout Distributed Row Matrices (DRMs).

The ecosystem of operators is built in the R's image, i.e. it follows R naming such as %*%, colSums, nrow, length operating over vectors or matices.

Important part of Spark Bindings is expression optimizer. It looks at expression as a whole and figures out how it can be simplified, and which physical operators should be picked. For example, there are currently about 5 different physical operators performing DRM-DRM multiplication picked based on matrix geometry, distributed dataset partitioning, orientation etc. If we count in DRM by in-core combinations, that would be another 4, i.e. 9 total -- all of it for just simple x %*% y logical notation.

Please refer to the documentation for details.

## Status

At this point, this environment addresses Linear Algebra side of things only. However, it would be very exciting to include statistics and data frame support too.

Also, this is early stage and experimental at this point. Tweaks may be needed here and there for performance on case-per-case basis. But being run on Spark, and assuming there's enough RAM not to swap intermediate products of computation to disk, it should be as fast as it can be expected of in-memory matrix block manipulations in Mahout and IO associated with the use of Spark distributed primitives.

## Documentation

## Distributed methods and solvers using Bindings

- In-core (ssvd) and Distributed (dssvd) Stochastic SVD -- guinea pigs -- see the bindings manual
- In-core (spca) and Distributed (dspca) Stochastic PCA -- guinea pigs -- see the bindings manual
- Distributed thin QR decomposition (dqrThin) -- guinea pig -- see the bindings manual

## Related history of note

- CLI and Driver for Spark version of item similarity -- MAHOUT-1541
- Command line interface for generalizable Spark pipelines -- MAHOUT-1569
- Cooccurrence Analysis / Item-based Recommendation -- MAHOUT-1464
- Spark Bindings -- MAHOUT-1346
- Scala Bindings -- MAHOUT-1297
- Interactive Scala & Spark Bindings Shell & Script processor -- MAHOUT-1489
- OLS tutorial using Mahout shell -- MAHOUT-1542
- Full abstraction of DRM apis and algorithms from a distributed engine -- MAHOUT-1529

## Work in progress

- Text-delimited files for input and output -- MAHOUT-1568
- Weighted (Implicit Feedback) ALS -- MAHOUT-1365
- Data frame R-like bindings -- MAHOUT-1490
- Port Naive Bayes -- MAHOUT-1493
*Your issue here!*

## Stuff wanted:

- Data frame R-like bindings (similarly to linalg bindings)
- Stat R-like bindings (perhaps we can just adapt to commons.math stat)
**BYODMs:**Bring Your Own Distributed Method on SparkBindings!- In-core jBlas matrix adapter
- In-core GPU matrix adapters