Full Application

Snippet

MongoDB

Student

Community

Partner

Introductory

Advanced

Rachelle Palmer

## Creators
[Lucas De Oliveira](https://www.linkedin.com/in/lbdeoliveira/), [Chandrish Ambati](https://www.linkedin.com/in/avmchandrish/), and [Anish Mukherjee](https://www.linkedin.com/in/mukherjeeanish/) from University of San Francisco contributed this amazing project.

## Background to the Project
In 2018, Spotify organized an Association for Computing Machinery (ACM) [RecSys Challenge](https://www.recsyschallenge.com/2018/) where they posted [a dataset of one million playlists](https://www.aicrowd.com/challenges/spotify-million-playlist-dataset-challenge), challenging participants to recommend a list of 500 songs given a user-created playlist.

As both music lovers and data scientists, we were naturally drawn to this challenge. Right away, we agreed that combining song embeddings with some nearest-neighbors method for recommendation would likely produce very good results. Importantly, we were curious about how we could  solve  this recommendation task at scale with over [4 billion user-curated playlists](https://soundplate.com/how-many-playlists-are-there-on-spotify-and-other-spotify-stats/) on Spotify, where this number keeps growing. This realization raised serious questions about how to train a decent model since all that data would likely not fit in memory or a single server.

## What We Built
This project resulted in a scalable ETL pipeline utilizing
* Apache Spark
* MongoDB
* Amazon S3
* Databricks (PySpark)
These were used to train a deep learning Word2Vec model to build song and playlist embeddings for recommendation. We followed up with data visualizations we created on Tensorflow’s Embedding Projector.


## The Process
### Collecting Lyrics
The most tedious task of this project was collecting as many lyrics for the songs in the playlists as possible. We began by isolating the unique songs in the playlist files by their track URI; in total we had over 2 million unique songs. Then, we used the track name and artist name to look up the lyrics on the web. Initially, we used simple Python requests to pull in the lyrical information but this proved too slow for our purposes. We then used asyncio, which allowed us to make requests concurrently. This sped up the process significantly, reducing the downloading time of lyrics for 10k songs from 15 mins to under a minute. Ultimately, we were only able to collect lyrics for 138,000 songs.

### Pre-processing
The original dataset contains 1 million playlists spread across 1 thousand JSON files totaling about 33 GB of data. We used PySpark in Databricks to preprocess these separate JSON files into a single SparkSQL DataFrame and then joined this DataFrame with the lyrics we saved. 

While the aforementioned data collection and preprocessing steps are time-consuming, the model also needs to be re-trained and re-evaluated often, so it is critical to store data in a scalable database. In addition, we’d like to consider a database that is schemaless for future expansion in data sets and supports various data types.  Considering our needs, we concluded that MongoDB would be the optimal solution as a data and feature store.

Check out the [Preprocessing.ipynb](https://github.com/lbdeoliveira/song-playlist-recommendation/blob/main/notebooks/Preprocessing_Pipeline.ipynb) notebook to see how we preprocessed the data.

### Training Song Embeddings
For our analyses, we read our preprocessed data from MongoDB into a Spark DataFrame and grouped the records by playlist id (pid), aggregating all of the songs in a playlist into a list under the column song_list. 
Using the Word2Vec model in Spark MLlib we trained song embeddings by feeding lists of track IDs from a playlist into the model much like you would send a list of words from a sentence to train word embeddings. As shown below, we trained song embeddings in only 3 lines of PySpark code:
```
from pyspark.ml.feature import Word2Vec
word2Vec = Word2Vec(vectorSize=32, seed=42, inputCol="song_list").setMinCount(1)
word2Vec.sexMaxIter(10)
model = word2Vec.fit(df_play)
```

We then saved the song embeddings down to MongoDB for later use. Below is a snapshot of the song embeddings DataFrame that we saved:

![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/song_embeddings_dataframe_c3fc7a455b.png)

Check out the [Song_Embeddings.ipynb](https://github.com/lbdeoliveira/song-playlist-recommendation/blob/main/notebooks/Song_Embeddings.ipynb) notebook to see how we train song embeddings.

### Training Playlists Embeddings
Finally, we extended our recommendation task beyond simple song recommendations to recommending entire playlists. Given an input playlist, we would return the k closest or most similar playlists. We took a “continuous bag of songs” approach to this problem by calculating playlist embeddings as the average of all song embeddings in that playlist.

This workflow started by reading back the song embeddings from MongoDB into a SparkSQL DataFrame. Then, we calculated a playlist embedding by taking the average of all song embeddings in that playlist and saved them in MongoDB.

Check out the [Playlist_Embeddings.ipynb](https://github.com/lbdeoliveira/song-playlist-recommendation/blob/main/notebooks/Playlist_Embeddings.ipynb) notebook to see how we did this.

### Training Lyrics Embeddings
Are you still reading? Whew!
We trained lyrics embeddings by loading in a song's lyrics, separating the words into lists, and feeding those words to a Word2Vec model to produce 32-dimensional vectors for each word. We then took the average embedding across all words as that song's lyrical embedding. Ultimately, our analytical goal here was to determine whether users create playlists based on common lyrical themes by seeing if the pairwise song embedding distance and the pairwise lyrical embedding distance between two songs were correlated. Unsurprisingly, it appears they are not.

Check out the[Lyrical_Embeddings.ipynb](https://github.com/lbdeoliveira/song-playlist-recommendation/blob/main/notebooks/Lyrical_Embeddings.ipynb) notebook to see our analysis.

## Notes on our Approach
You may be wondering why we used a language model (Word2Vec) to train these embeddings. Why not use a Pin2Vec or custom neural network model to predict implicit ratings? For practical reasons, we wanted to work exclusively in the Spark ecosystem and deal with the data in a distributed fashion. This was a constraint set on the project ahead of time and challenged us to think creatively.

However, we found Word2Vec an attractive candidate model for theoretical reasons as well. The Word2Vec model uses a word’s context to train static embeddings by training the input word’s embeddings to predict its surrounding words. In essence, the embedding of any word is determined by how it co-occurs with other words. This had a clear mapping to our own problem: by using a Word2Vec model the distance between song embeddings would reflect the songs’ co-occurrence throughout 1M playlists, making it a useful measure for a distance-based recommendation (nearest neighbors). It would effectively model how people grouped songs together, using user behavior as the determinant factor in similarity.

Additionally, the Word2Vec model accepts input in the form of a list of words. For each playlist we had a list of track IDs, which made working with the Word2Vec model not only conceptually but also practically appealing.

## Data Visualizations with Tensorflow and MongoDB
After all of that, we were finally ready to visualize our results and make some interactive recommendations. We decided to represent our embedding results visually using [Tensorflow’s Embedding Projector](https://projector.tensorflow.org)which maps the 32-dimensional song and playlist embeddings into an interactive visualization of a 3D embedding space. You have the choice of using PCA or tSNE for dimensionality reduction and cosine similarity or Euclidean distance for measuring distances between vectors.

Click [here](https://projector.tensorflow.org/?config=https://embedding-projector.s3.us-west-2.amazonaws.com/template_config_2M.json) for the song embeddings projector for the full 2 million songs, or [here](https://projector.tensorflow.org/?config=https://embedding-projector.s3.us-west-2.amazonaws.com/template_config_playlist.json) for a less crowded version with a random sample of 100k songs (shown below):

![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/164569070_88be5d94_a291_495d_b33d_3094634d9205_afc69037e9.gif)

The neat thing about using Tensorflow’s projector is that it gives us a beautiful visualization tool and distance calculator all in one. Try searching on the right panel for a song and if the song is part of the original dataset, you will see the “most similar” songs appear under it.

## Using MongoDB for ML/AI
We were impressed by how easy it was to use MongoDB to reliably store and load our data. Because we were using distributed computing, it would have been infeasible to run our pipeline from start to finish any time we wanted to update our code or fine-tune the model. MongoDB allowed us to save our incremental results for later processing and modeling, which collectively saved us hours of waiting for code to re-run.

It worked well with all the tools we use everyday and the tooling we chose - we didn't have any areas of friction. 

We were shocked by how this method of training embeddings actually worked. While the 2 million song embedding projector is crowded visually, we see that the recommendations it produces are actually quite good at grouping songs together.

Consider the embedding recommendation for The Beatles’ “A Day In The Life”:
![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/165581471_420ad43d_47f9_4aee_bf0c_2de6ac301144_c656a07f0e.gif)

Or the recommendation for Jay Z’s “Heart of the City (Ain’t No Love)”:
![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/164567916_28f6ebd6_0473_4d7b_b60c_55af628016f7_ec16751581.png)

Fan of Taylor Swift? Here are the recommendations for “New Romantics”:
![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/164567889_9ccf8326_7bc8_4c8e_9bc6_f123c0acba3f_0fab2ea1db.png)

We were delighted to find naturally occurring clusters in the playlist embeddings. Most notably, we see a cluster containing mostly Christian rock, one with Christmas music, one for reggaeton, and one large cluster where genres span its length rather continuously and intuitively.

Note also that when we select a playlist, we have many recommended playlists with the same names. This in essence validates our song embeddings. Recall that playlist embeddings were created by taking the average embedding of all its songs; the name of the playlists did not factor in at all. The similar names only conceptually reinforce this fact.



## Next Steps?
We felt happy with the conclusion of this project but there is more that could be done here.

1. We could use these trained song embeddings in other downstream tasks and see how effective these are. Also, you could download the song embeddings we here: [Embeddings](https://embedding-projector.s3.us-west-2.amazonaws.com/emb_word2vec_2M.tsv) | [Meta Info](https://embedding-projector.s3.us-west-2.amazonaws.com/meta_word2vec_2M.tsv)
2. We could look at other methods of training these embeddings using some recurrent neural networks and enhanced implementation of this Word2Vec model.





Python code example application for Spotify playlist and song recommendations using spark and tensorflow

A Spotify Song and Playlist Recommendation Engine

## Description of Application
A quick and easy example application project that creates a demo blog post engine. Very simple UI, ideal for beginners to Rust programming langauge.

##  Technology Stack
This code example utilizes the following technologies:

* MongoDB Atlas
* Rust
* Rocket.rs framework



A beginner level project using MongoDB with Rust

Beginner Coding Project: Build a Blog Engine with Rust and MongoDB

Kaitlin Mahar

 I recently [revealed on Twitter](https://twitter.com/k__mahar/status/1494118397491269636) something that may have come as a surprise to many of my followers from the Swift/iOS community: I had never written an iOS app before! I've been writing Swift for a few years now but have focused entirely on [library development](https://www.youtube.com/watch?v=9-fdbG9jNt4) and [server-side Swift](https://www.swift.org/server/).

A highly compelling feature of Swift is that it allows you to write an iOS app and a corresponding backend – a complete, end-to-end application – all in the same language. This is similar to how using [Node.js](https://nodejs.org/en/) for a web app backend allows you to write Javascript everywhere.

To test this out and learn about iOS development, I decided to build a full-stack application entirely in Swift. I settled on a familiar CRUD app I've created a web version of before, an application that allows the user to manage a list of kittens and information about them.

I chose to build the app using the following components:
* A backend server, written using the popular Swift web framework [Vapor](https://vapor.codes/) and using the [MongoDB Swift driver](https://github.com/mongodb/mongo-swift-driver) via [MongoDBVapor](https://github.com/mongodb/mongodb-vapor) to store data in MongoDB
* An iOS application built with [SwiftUI](https://developer.apple.com/xcode/swiftui/) and using [SwiftBSON](https://github.com/mongodb/swift-bson) to support serializing/deserializing data to/from [extended JSON](https://docs.mongodb.com/manual/reference/mongodb-extended-json/), a version of JSON with MongoDB-specific extensions to simplify type preservation
* A [SwiftPM](https://www.swift.org/package-manager/) package containing the code I wanted to share between the two above components

I was able to combine all of this into a single code base with a folder structure as follows:
```
FullStackSwiftExample/
├── Models/
│   ├── Package.swift
│   └── Sources/
│       └── Models/
│           └── Models.swift
├── Backend/
│   ├── Package.swift
│   └── Sources/
│       ├── App/
│       │   ├── configure.swift
│       │   └── routes.swift
│       └── Run/
│           └── main.swift
└── iOSApp/
    └── Kittens/
        ├── KittensApp.swift
        ├── Utilities.swift
        ├── ViewModels/
        │   ├── AddKittenViewModel.swift
        │   ├── KittenListViewModel.swift
        │   └── ViewUpdateDeleteKittenViewModel.swift
        └── Views/
            ├── AddKitten.swift
            ├── KittenList.swift
            └── ViewUpdateDeleteKitten.swift
```

Overall, it was a great learning experience for me, and although the app is pretty basic, I'm proud of what I was able to put together! [Here](https://github.com/mongodb/mongo-swift-driver/tree/main/Examples/FullStackSwiftExample) is the finished application, instructions to run it, and documentation on each component.

In the rest of this post, I'll discuss some of my takeaways from this experience.

## 1. Sharing data model types made it straightforward to consistently represent my data throughout the stack.

As I mentioned above, I created a shared SwiftPM package for any code I wanted to use both in the frontend and backend of my application. In that package, I defined `Codable` types modeling the data in my application, for example:

```swift
/**
* Represents a kitten.
* This type conforms to `Codable` to allow us to serialize it to and deserialize it from extended JSON and BSON.
* This type conforms to `Identifiable` so that SwiftUI is able to uniquely identify instances of this type when they
* are used in the iOS interface.
*/
public struct Kitten: Identifiable, Codable {
   /// Unique identifier.
   public let id: BSONObjectID

   /// Name.
   public let name: String

   /// Fur color.
   public let color: String

   /// Favorite food.
   public let favoriteFood: CatFood

   /// Last updated time.
   public let lastUpdateTime: Date

   private enum CodingKeys: String, CodingKey {
       // We store the identifier under the name `id` on the struct to satisfy the requirements of the `Identifiable`
       // protocol, which this type conforms to in order to allow usage with certain SwiftUI features. However,
       // MongoDB uses the name `_id` for unique identifiers, so we need to use `_id` in the extended JSON
       // representation of this type.
       case id = "_id", name, color, favoriteFood, lastUpdateTime
   }
}
```

When you use separate code/programming languages to represent data on the frontend versus backend of an application, it's easy for implementations to get out of sync.  But in this application, since the same exact model type gets used for the frontend **and** backend representations of kittens, there can't be any inconsistency.

Since this type conforms to the `Codable` protocol, we also get a single, consistent definition for a kitten's representation in external data formats. The formats used in this application are:
* [Extended JSON](https://docs.mongodb.com/manual/reference/mongodb-extended-json/), which the frontend and backend use to communicate via HTTP, and
* [BSON](https://docs.mongodb.com/manual/reference/bson-types/), which the backend and MongoDB use to communicate

For a concrete example of using a model type throughout the stack, when a user adds a new kitten via the UI, the data flows through the application as follows:
1. The iOS app creates a new `Kitten` instance containing the user-provided data
1. The `Kitten` instance is serialized to extended JSON via `ExtendedJSONEncoder` and sent in a POST request to the backend
1. The Vapor backend deserializes a new instance of `Kitten` from the extended JSON data using `ExtendedJSONDecoder`
1. The `Kitten` is passed to the MongoDB driver method `MongoCollection<Kitten>.insertOne()`
1. The MongoDB driver uses its built-in `BSONEncoder` to serialize the `Kitten` to BSON and send it via the MongoDB [wire protocol](https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/) to the database

With all these transformations, it can be tricky to ensure that both the frontend and backend remain in sync in terms of how they model, serialize, and deserialize data.  Using Swift everywhere and sharing these `Codable` data types allowed me to avoid those problems altogether in this app.

## 2. Working in a single, familiar language made the development experience seamless.

Despite having never built an iOS app before, I found my existing Swift experience made it surprisingly easy to pick up on the concepts I needed to implement the iOS portion of my application. I suspect it's more common that someone would go in the opposite direction, but I think iOS experience would translate well to writing a Swift backend too!

I used several Swift language features such as [protocols](https://docs.swift.org/swift-book/LanguageGuide/Protocols.html), [trailing closures](https://docs.swift.org/swift-book/LanguageGuide/Closures.html), and [computed properties](https://docs.swift.org/swift-book/LanguageGuide/Properties.html) in both the iOS and backend code. I was also able to take advantage of Swift's new built-in features for [concurrency](https://docs.swift.org/swift-book/LanguageGuide/Concurrency.html) throughout the stack. I used the `async` APIs on [`URLSession`](https://developer.apple.com/documentation/foundation/urlsession) to send HTTP requests from the frontend, and I used Vapor and the MongoDB driver's `async` APIs to handle requests on the backend.  It was much easier to use a consistent model and syntax for concurrent, asynchronous programming throughout the application than to try to keep straight in my head the concurrency models for two different languages at once.

In general, using the same language really made it feel like I was building a single application rather than two distinct ones, and greatly reduced the amount of context-switching I had to do as I alternated between work on the frontend and backend. 

## 3. SwiftUI and iOS development are really cool!

Many of my past experiences trying to cobble together a frontend for school or personal projects using HTML and Javascript were frustrating.  This time around, the combination of using my favorite programming language and an elegant, declarative framework made writing the frontend very enjoyable. More generally, it was great to finally learn a bit about iOS development and what most people writing Swift and that I know from the Swift community do!

---

In conclusion, my first foray into iOS development building this full-stack Swift app was a lot of fun and a great learning experience. It strongly demonstrated to me the benefits of using a single language to build an entire application, and using a language you're already familiar with as you venture into programming in a new domain.

I've included a list of references below, including a link to the example application. Please feel free to get in touch with any questions or suggestions regarding the application or the MongoDB libraries listed below – the best way to get in touch with me and my team is by filing a [GitHub issue](https://github.com/mongodb/mongo-swift-driver/issues/new/choose) or [Jira ticket](http://jira.mongodb.org/browse/SWIFT)!

## References
* [Example app source code](https://github.com/mongodb/mongo-swift-driver/tree/main/Examples/FullStackSwiftExample)
* [MongoDB Swift driver](https://github.com/mongodb/mongo-swift-driver) and [documentation](https://mongodb.github.io/mongo-swift-driver/docs/current/MongoSwift/index.html)
* [MongoDBVapor](https://github.com/mongodb/mongodb-vapor) and [documentation](https://mongodb.github.io/mongodb-vapor/current/index.html)
* [SwiftBSON](https://github.com/mongodb/swift-bson) and [documentation](https://mongodb.github.io/swift-bson/docs/current/SwiftBSON/index.html)
* [Vapor](https://vapor.codes/)
* [SwiftUI](https://developer.apple.com/xcode/swiftui/)

Code Examples

Featured Code Examples

A Spotify Song and Playlist Recommendation Engine

Beginner Coding Project: Build a Blog Engine with Rust and MongoDB

Building a Full Stack application with Swift

All Code Examples