Background

A music streaming startup, Sparkify, has grown their user base and song database and want to move their processes and data onto the cloud. The goal of the project is to build an ETL pipeline that extracts data from S3, stages them in Redshift, and transforms data into a set of dimensional tables. These tables are intended for Sparkify analytics team to continue finding insights in what songs their users are listening to.

Source data

The source data is a two data sets residing on S3:

• Song data: s3://udacity-dend/song_data
• Log data: s3://udacity-dend/log_data
• Log metadata: s3://udacity-dend/log_json_path.json

Song data

The first dataset is a subset of real data from the Million Song Dataset. Each file is in JSON format and contains metadata about a song and the artist of that song. The files are partitioned by the first three letters of each song's track ID. For example, here are filepaths to two files in this dataset.

song_data/A/B/C/TRABCEI128F424C983.json
song_data/A/A/B/TRAABJL12903CDCF1A.json

And below is an example of what a single song file, TRAABJL12903CDCF1A.json, looks like.

{"num_songs": 1, "artist_id": "ARJIE2Y1187B994AB7", "artist_latitude": null, "artist_longitude": null, "artist_location": "", "artist_name": "Line Renaud", "song_id": "SOUPIRU12A6D4FA1E1", "title": "Der Kleine Dompfaff", "duration": 152.92036, "year": 0}

Log data

The second dataset consists of log files in JSON format generated by this event simulator based on the songs in the dataset above. These simulate app activity logs from an imaginary music streaming app based on configuration settings.

The log files in the dataset are partitioned by year and month. For example, here are filepaths to two files in this dataset.

log_data/2018/11/2018-11-12-events.json
log_data/2018/11/2018-11-13-events.json

And below is an example of what the data in a log file, 2018-11-12-events.json, looks like.

Database Schema

The analytical data mart is organized according to the star schema optimized for song play analysis.

Fact Table

• songplays - records in event data associated with song plays
  • songplay_id, start_time, user_id, level, song_id, artist_id, session_id, location, user_agent

Dimension Tables

• users - users in the app
  • user_id, first_name, last_name, gender, level
• songs - songs in music database
  • song_id, title, artist_id, year, duration
• artists - artists in music database
  • artist_id, name, location, lattitude, longitude
• time - timestamps of records in songplays broken down into specific units
  • start_time, hour, day, week, month, year, weekday

ETL

ETL organized into the next steps:

1. Loading raw data into the staging area:
   • Copy log data into the staging_events table
   • Copy songs data into the staging_songs table
2. Populating the fact table
3. Populatind dimensions tables

Project structure

• create_tables.py: database initialization
• dwh.cfg: configuration file
• etl.py: data loading to staging area and further transformations to create a data mart
• sql_queries.py: SQL queries to perform database initalization and ETL operations

Running

1. Populate dwh.cfg with actual input data set and AWS assets
2. Run python create_tables.py
3. Run python etl.py