Flight Delay Prediction — MLOps Project

This repository contains an end-to-end MLOps example for predicting flight arrival delays. It shows how data is ingested from Azure Blob Storage, feature-engineered, trained and logged to MLflow, packaged and served via a Flask API that performs inference using the latest model and preprocessor artifacts stored in blob storage.

---

Repository layout

requirements.txt
01-notebook/
    training_delays.py        # Feature engineering + training + MLflow logging
    flight_delay.ipynb
    new.csv                   # example / sample dataset
flasc_model/
    train.py                  # (empty placeholder in this repo)
flask_API/
    app.py                    # Flask app exposing /predict
    predict.py                # Inference helpers: loads latest model & preprocessor from blob, runs predictions
    Dockerfile
mlruns/                       # MLflow tracking artifact directory (if used locally)
models/                       # Saved models (optional / local)
README.md

Note: Some files live in the 01-notebook folder and include the primary training and preprocessing pipeline (script form is present as training_delays.py). The predict.py in flask_API downloads the latest model/preprocessor from Azure Blob Storage and runs inference on an input CSV blob.

---

ASCII architecture summary:

• Data source: Azure Blob (container rawflightsdata)
• Training: 01-notebook/training_delays.py reads new.csv (or reads from blob) and trains a BalancedRandomForestClassifier. It logs models + preprocessors to MLflow and (optionally) uploads pickled artifacts to a blob container named models / preprocessors.
• Serving: flask_API/app.py exposes a POST /predict endpoint which accepts a JSON payload with blob_name. The API calls predict.py which:
  1. downloads the input CSV from rawflightsdata container,
  2. finds the latest delay_model_<version>.pkl and preprocessor_<version>.pkl in their respective blob containers,
  3. applies preprocessing and model predict,
  4. uploads predictions_<blob_name> to predicted-flight-data container and returns results in the API response.

---

Environment variables (required)

Set these before running training or the API:

• AZURE_STORAGE_CONNECTION_STRING — connection string for an Azure Storage account used to store data, models and artifacts.
• AZURE_STORAGE_ACCOUNT — storage account name (used for artifact URIs in some scripts).
• MLFLOW_TRACKING_URI — MLflow tracking server URI (e.g., http://localhost:5001 or an external server).
• MLFLOW_EXPERIMENT_NAME — name for MLflow experiment (script appends _RF for the random forest experiment).

Optional but useful:

• MLFLOW_TRACKING_USERNAME / MLFLOW_TRACKING_PASSWORD if the MLflow server requires auth.

---

Dependencies

Primary dependencies are in requirements.txt and include (non-exhaustive):

• Flask
• pandas
• numpy
• scikit-learn
• joblib
• imbalanced-learn
• mlflow
• azure-storage-blob
• holidays

Install locally (recommended inside a virtualenv):

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

If you add new runtime dependencies, add them to requirements.txt so Docker builds are consistent.

---

Training (local or remote)

The training/feature engineering pipeline is in 01-notebook/training_delays.py. That file performs:

• loading the CSV training data (either local new.csv or downloaded from blob storage),
• feature engineering (date/time cyclic features, route/airline historical rates, holiday indicator, etc.),
• building a ColumnTransformer preprocessor,
• training a BalancedRandomForestClassifier,
• logging parameters/metrics and saving the preprocessor and model into MLflow (and setting artifact tags),

To run training (locally):

# ensure env vars are set: AZURE_STORAGE_CONNECTION_STRING, MLFLOW_TRACKING_URI, MLFLOW_EXPERIMENT_NAME
python 01-notebook/training_delays.py

Notes:

• The training script will call MLflow APIs to record metrics and log models. Ensure MLFLOW_TRACKING_URI is reachable.
• The training script names models as delay_model_<version>.pkl (the inference code expects that naming pattern). Confirm the naming used by your training script.

---

API — inference

Start the Flask API (from flask_API folder):

cd flask_API
# Ensure AZURE_STORAGE_CONNECTION_STRING is set (and MLFLOW vars if needed)
python app.py

Default: the app listens on port 5000 (Dockerfile exposes 5000 as well).

Endpoint:

• POST /predict
  • JSON body: { "blob_name": "inputfile.csv" }
  • Example response: { "status": "success", "message": "Predicion Executed", "blob": "inputfile.csv", "results": [ { row1 }, { row2 }, ... ] }

Sample curl (from any machine that can reach the API):

curl -X POST http://localhost:5000/predict \
  -H "Content-Type: application/json" \
  -d '{"blob_name": "sample_input.csv"}'

What the API does under the hood (see flask_API/predict.py):

• downloads the CSV from the input container (name: rawflightsdata),
• loads latest model and preprocessor from blob containers models and preprocessors,
• applies preprocessing and model prediction,
• writes predictions_<blob_name> to container predicted-flight-data and returns the predictions.

---

How model selection/versioning works (important)

The inference code finds the latest model/preprocessor by matching a filename pattern like delay_model_<version>.pkl and preprocessor_<version>.pkl and selecting the highest version number. This implies:

• When saving artifacts from training, use a semantic version suffix (e.g. delay_model_1.1.pkl).
• Keep a consistent naming scheme so the inference function can pick the latest automatically.

If you prefer explicit model pinning, modify predict.py to read a specific artifact name from env or request.

---

MLflow

The training script uses MLflow for experiment tracking. Common usage patterns:

• Run an MLflow server locally: mlflow server --backend-store-uri sqlite:///mlflow.db --default-artifact-root ./mlruns --host 0.0.0.0 --port 5001
• Set MLFLOW_TRACKING_URI to your server: export MLFLOW_TRACKING_URI=http://localhost:5001
• The training script will call mlflow.sklearn.log_model(preprocessor, name="preprocessor") and mlflow.sklearn.log_model(brf, name="model").

If you'd like to use Azure Blob as the artifact store, configure MLflow's artifact location accordingly (the training code attempts to create an experiment with a wasbs:// artifact location if AZURE_STORAGE_ACCOUNT is set).

---

Docker (build & run API)

Build (from flask_API dir or modify path in Dockerfile):

cd flask_API
docker build -t flight-delay-api:latest .

# run container (pass env vars and map port)
docker run -e AZURE_STORAGE_CONNECTION_STRING="$AZURE_STORAGE_CONNECTION_STRING" -p 5000:5000 flight-delay-api:latest

Tips:

• For local development, prefer running python app.py inside a venv — faster iteration.
• When running in production, supply a process manager (gunicorn) and proper logging, and set --workers according to CPU.

---

Troubleshooting

• "Import X could not be resolved" — ensure dependencies are installed in the Python environment that VS Code or your runtime uses. Use pip install -r requirements.txt and confirm python -m pip list shows packages.
• Azure auth / access errors — check AZURE_STORAGE_CONNECTION_STRING and ensure the target containers (rawflightsdata, models, preprocessors, predicted-flight-data) exist and the connection string has RW permissions.
• MLflow connection issues — confirm MLFLOW_TRACKING_URI is reachable from the machine running training and that the artifact store is writable.
• Model not found — ensure training uploads or saves model artifacts with names matching the inference pattern delay_model_<version>.pkl.

---

Testing tips

1. Unit test the inference flow locally by placing a small CSV in Azure blob rawflightsdata and call the API with that blob name.
2. Use mlflow UI to inspect runs and confirm model + preprocessor were logged.
3. Use local storage emulators (Azurite) if you prefer to not use an Azure subscription during dev.

---

Next steps / recommendations

• Add CI workflow to run linting and tests.
• Add a small test harness that runs predict.py with a local CSV to verify preprocessing and model output.
• Improve model pinning or add an environment-toggle for sticking to a specific model version in production.
• Add a Makefile or tiny CLI script to standardize common tasks (train, serve, docker-build, mlflow-run).

---

Contributing

1. Fork the repository
2. Create a branch: git checkout -b feat/your-feature
3. Add tests and documentation updates
4. Create a pull request

---

License

This project includes a MIT license file in the repository

---