DEV Community: Faethm AI

Improving Jupyter notebook code reviews with jupydiff

Mikhail Thornhill — Wed, 14 Oct 2020 06:15:49 +0000

As an information technology graduate looking to kickstart my career, I spent the first half of 2020 seeking opportunities to expand my skills and gain relevant practical experience.

After a few twists and turns, I started my internship as an engineer at Faethm with one big goal:

How can we make code reviews easier for our data science team?

Faethm is an AI platform built on the work of data scientists, and for them this is a very important problem to solve. Today, Faethm’s data science team works primarily with Jupyter notebooks, and these are managed in various internal GitHub repositories.

The problem with Jupyter notebooks

Jupyter notebooks are a popular productivity tool among data scientists, and for good reason.

You can execute data science workflows in cells, output tables and charts and keep documentation inline. Despite their popularity, it is cumbersome to manage changes made to Jupyter notebooks using version control systems like Git.

Tools like nbdime help a little. nbdime allows notebook users to highlight changes made between notebook versions on the command line or even within a Jupyter instance.

However, GitHub's built-in source code tools are not designed for Jupyter notebooks. A notebook captures code, outputs and metadata as a JSON document. When a data scientist executes a notebook with modifications, the JSON data changes at the cell-level to reflect the new code, updates the metadata and captures the new output.

Solving this problem became the essence of my internship.

Since many of these technologies are new to me, I knew it would be a challenge. With a combination of self-learning, persistence and support from Faethm’s engineers I’m happy to be able to present this solution.

Introducing jupydiff, a Docker action for GitHub Actions

jupydiff is a GitHub Action that allows data scientists to quickly compare changes made to Jupyter notebooks in GitHub repositories.

It works with regular commits and pull requests. When a change is made, jupydiff computes the code additions and deletions within each notebook, and summarises these as a comment on the associated commit or pull request.

jupydiff helps you streamline data science code reviews.

Without jupydiff, to compute the exact code difference between two Jupyter notebooks a reviewer would need to clone the repository, download and install nbdime and then run nbdime diff on the command line. Alternatively, observing the regular diff in a code editor, version control tool or on GitHub itself involved interpreting lines of underlying JSON Jupyter notebook structure.

How to version control Jupyter notebooks on GitHub with jupydiff

Setting up jupydiff to work with your Jupyter notebook project is simple. Since jupydiff is a GitHub Action, it works with both public and private repositories.

You can read all the details about configuring jupydiff in the jupydiff repository on GitHub, but I’ll cover the essentials here.

You’ll need to create a new GitHub Action workflow in your repository at /.github/workflows/jupydiff.yml with the following contents:

name: jupydiff

on: [ push, pull_request ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 2
      - uses: Faethm-ai/jupydiff@v1

GitHub Actions runs jupydiff on your repository for each commit pushed or pull request opened. jupydiff computes the changes made with the latest commit, and leave a comment on the commit or pull request highlighting the differences in the code.

With no more JSON mess, data scientists are free to continue with their code review right on GitHub.

You’ve been reading a post from the Faethm AI engineering blog. We’re hiring, too! If share our passion for the future of work and want to pioneer world-leading data science and engineering projects, we’d love to hear from you. See our current openings: https://faethm.ai/careers

Scaling Jupyter notebooks across the world with AWS and Papermill

Blair Hudson — Wed, 16 Sep 2020 02:40:06 +0000

As a data scientist, one of the most exciting things to me about Faethm is that data science is at the heart of our products.

As the head of our data engineering team, it's my responsibility to ensure our data science can scale to meet the needs of our rapidly growing and global customer base.

In this article, I'm going to share some of the most interesting parts of our approach to scaling data science products, and a few of the unique challenges that we have to address.

Faethm is data science for the evolution of work

Before we delve into our approach, it's important to understand a few things about Faethm and what we do.

Our customers depend on us to understand the future of work, and the impacts that technology and shifts in work patterns have on their most critical asset: their people.

Our data science team is responsible for designing and building our occupation ontology, breaking down the concept of "work" into roles, tasks, skills and a myriad of dynamic analytical attributes to describe all of these at the most detailed level. Our analytics are derived from a growing suite of propriety machine learning models.

Our platform ties it all together to help people leaders, strategy leaders and technology leaders make better decisions about their workforce, with a level of detail and speed to insight that is impossible without Faethm.

We use Python and Jupyter notebooks for data science

Our data scientists primarily use Python, Jupyter notebooks and the ever-growing range of Python packages for data transformation, analysis and modelling that you would expect to see in any data scientist's toolkit (and perhaps some you wouldn't).

Luckily running an interactive Jupyter workbench in the cloud is pretty easy.

AWS SageMaker provides the notebook platform for our teams to configure managed compute instances to their requirements and turn them on and off on-demand. Self-service access to variably powerful modelling environments requires managing a few IAM Role policies and some clicks in the AWS Console.

This means a data scientist can SSO into the AWS Console and get started on their next project with access to whatever S3 data is permitted by their access profile. Results written back to S3, notebooks pushed to the appropriate Git repository.

How do we turn this into a product so that our data scientists don't ever have to think about running a operational workflow?

Engineering data science without re-engineering notebooks

One of the core design goals of our approach is to scale without re-engineering data science workflows wherever possible.

Due to the complexity of our models, it's critical that data scientists have full transparency of how their models are functioning in production. So we don't re-write Jupyter notebooks. We don't even replicate the code within into executable Python scripts. We just execute them, exactly as written, no change required.

We do this with Papermill.

Papermill is a Python package for parameterising and executing Jupyter notebooks. As long as a notebook is written with parameters for dynamic functionality (usually with sensible defaults in the first notebook cell), Papermill can execute the notebook ($NOTEBOOK) on the command line with a single command. Any parameters (-r raw or -p normal) can be overridden at runtime and Papermill does this by injecting a new notebook cell assigning the new parameter values.

A simple Papermill command line operation looks like this:

pip install papermill
papermill "$NOTEBOOK" "$OUTPUT_NOTEBOOK" \
    -r A_RAW_PARAMETER "this is always a Python string" \
    -p A_PARAMETER "True" # this is converted to a Python data type

Since Papermill executes the notebook and not just the code, the cell outputs including print statements, error messages, tables and plots are all rendered in the resulting output notebook ($OUTPUT_NOTEBOOK). This means that the notebook itself becomes a rich log of exactly what was executed, and serves as a friendly diagnostic tool for data scientists to assess model performance and detect any process anomalies.

Reproducible notebook workflows

Papermill is great for executing our notebooks, but we need notebooks to be executed outside of the SageMaker instance they were created in. We can achieve this by capturing a few extra artifacts alongside our notebooks.

Firstly, we store a list of package dependencies in a project's Git repository. This is generated easily in the Jupyter terminal with pip freeze > requirements.txt, but often best hand-crafted to keep dependencies to essentials.

Any other dependencies are also stored in the repository. These can include scripts, pickled objects (such as trained models) and common metadata.

We also capture some metadata in a YAML configuration file:

...
Notebooks:
 - my-notebook.ipynb
 - my-second-notebook.ipynb
...

This file lists the notebooks in execution order, so a workflow can be composed of multiple independent notebooks to maintain readability.

Finally, a simple buildspec.yml configuration file is included that initiates the build process. This is the standard for AWS CodeBuild which we use as a build pipeline.

Changes to notebooks, dependencies and other repository items are managed through a combination of production and non-production Git branches, just like any other software project. Pull Requests provide a process for code promotion between staging and production environments, and facilitate a manual code review and automate a series of merge checks to create confidence in code changes.

Notebook containers built for production deployment

To keep our data science team focused on creating data science workflows and not build pipelines, the container build and deployment process is abstracted from individual Jupyter projects.

Webhooks are configured on each Git repository. Pushing to a branch in a notebook project triggers the build process. Staging and production branches are protected from bad commits by requiring a Pull Request for all changes.

A standard Dockerfile consumes the artifacts stored in the project repository at build-time:

FROM python:3.7

RUN pip install papermill

# package dependencies
COPY requirements.txt
RUN pip install -r requirements.txt

# notebook execution order from YAML config
ARG NOTEBOOKS
ENV NOTEBOOKS=${NOTEBOOKS}

# prepare entrypoint script
COPY entrypoint.sh

# catch-all for other dependencies in the repository
COPY .

# these parameters will be injected at run-time
ENV PARAM1=
ENV PARAM2=

CMD ./entrypoint.sh

The entrypoint is an iterative bash script:

#!/bin/bash

for NOTEBOOK in ${NOTEBOOKS//,/ }
do
    papermill "$NOTEBOOK" "s3://notebook-output-bucket/$NOTEBOOK" \
        -r PARAM1 "$PARAM1" \
        -p PARAM2 "$PARAM2"
done

This entrypoint.sh script follows this configuration file to execute each of the notebooks at run-time, and stores the resulting notebook output in S3.

AWS CodeBuild determines the target environment from the repository branch, builds the container and pushes it to AWS ECR so it is available to be deployed into our container infrastructure.

Serverless task execution for Jupyter notebooks

With Faethm's customers spanning many different regions across the world, the data is subject to the data regulations of each customer's local jurisdiction. Our data science workflows need to be able to execute in the regions which our customers specify for their data to be stored. With our approach, data does not have to transfer between regions for processing.

We operate cloud environments in a growing number of customer regions across the world, throughout the Asia Pacific, US and Europe. As Faethm continues to scale, we need to be able to support new regions.

To run our Jupyter notebook containers, each supported region has a VPC with a ECS Fargate cluster configured to run notebook tasks on-demand.

Each Jupyter project is associated with an ECS task definition, and an ECS task definition template is configured by the build pipeline and deployed through CloudFormation.

Event-driven Jupyter notebook tasks

To simplify task execution, each notebook repository has a single event trigger. Typically, a notebook task will run in response to a data object landing in S3. An example is a CSV being uploaded from a user portal, upon which our analysis takes place.

In the project repository, the YAML configuration file captures the S3 bucket and prefix that will trigger the ECS task definition when a CloudTrail log sent to EventBridge matches it:

...
S3TriggerBucket: notebook-trigger-bucket
S3TriggerKeyPrefix: path/to/data/
...

The EventBridge rule template is configured by the build pipeline and deployed through CloudFormation, and this completes the basic requirements for automating Jupyter notebook execution.

Putting it all together

In this article we've looked at a few of the challenges to scaling and automating data science workflows in a multi-region environment. We've also looked at how to address them within the Jupyter ecosystem and how we are implementing solutions that take advantage of various AWS serverless offerings.

When you put all of these together, the result is our end-to-end serverless git-ops containerised event-driven Jupyter-notebooks-as-code data science workflow execution pipeline architecture.

We just call it notebook-pipeline.