Flight Delay Prediction & MLOps Pipeline
An end-to-end machine learning project using U.S. flight data to predict departure delays for flights originating from Miami International Airport. I built the project from raw data preparation through model training, experiment tracking, API development, automated testing and Docker containerization.
Can flight information help predict departure delays?
Flight delays affect passengers, airlines and airport operations. The objective of this project was to build a reproducible machine learning system capable of using scheduled flight information to generate an estimated departure delay.
Business Question
Can information known about a flight before departure be transformed into a prediction of how many minutes the flight may be delayed?
Project Goal
Build more than a predictive model. The goal was to create a repeatable workflow that could prepare the data, train the model, track experiments and ultimately expose the prediction through an application programming interface.
Turning raw flight records into model-ready data
The project used U.S. Bureau of Transportation Statistics On-Time Performance flight records. I narrowed the analysis to flights departing from Miami International Airport and created a repeatable cleaning process before training the model.
Filter the scope
Flight records were filtered so the modeling dataset focused specifically on flights where the origin airport was MIA.
Evaluate missing values
Approximately 1.7% of the Miami departure records contained missing values. Incomplete observations were removed before model training.
Correct data types
Flight-time variables such as scheduled departure, actual departure, scheduled arrival and actual arrival required conversion from character values into numeric representations suitable for analysis.
Prepare modeling features
Airport and time information was transformed into the format required by the predictive model while maintaining the same preprocessing logic throughout training and deployment.
A reproducible machine learning workflow
Instead of placing the entire project in one script, I separated the workflow into logical stages and connected them through a main execution process. This made the workflow easier to reproduce, test and maintain.
Import
Load the raw BTS flight dataset and select the required fields.
Clean
Filter MIA departures, remove incomplete records and format variables.
Train
Train a polynomial ridge regression model on the prepared data.
Track
Record model experiments and artifacts using MLflow.
Deploy
Serve predictions through FastAPI inside a Docker container.
Polynomial ridge regression
Modeling Approach
I trained a polynomial ridge regression model to estimate departure delay. Polynomial features allow the model to represent nonlinear relationships while ridge regularization helps control model complexity.
Experiment Management
MLflow was incorporated into the workflow to track model experiments and training outputs. The completed model was saved as an artifact so the same trained model could later be loaded by the prediction API.
Turning the model into a usable API
A trained model is more useful when another application can interact with it. I built a REST API using FastAPI that loads the finalized machine learning model and generates flight-delay predictions from user-supplied flight information.
API Inputs
- Departure airport
- Arrival airport
- Local departure time
- Local arrival time
API Output
The application transforms the incoming airport and time information into the format expected by the trained model and returns the estimated departure delay in minutes.
Testing more than the happy path
I created automated tests to verify that the API responded correctly to valid requests while also handling incorrectly formatted or incomplete input.
Dockerized for consistent deployment
The completed FastAPI application was packaged inside a Docker container along with its Python dependencies, trained model and supporting files. Uvicorn was used to run the FastAPI application inside the container.
Why Docker?
Containerization creates a consistent runtime environment and reduces differences between development and deployment systems. The application can be packaged with the dependencies it needs rather than relying on the configuration of the host computer.
Deployment Stack
- Python
- FastAPI
- Uvicorn
- Docker
- GitLab
- Trained model artifact
- Airport encoding configuration
Development tracked with Git
Development was managed through GitLab using a dedicated working branch rather than committing directly to the main branch. Changes were committed throughout development to document the progression of the pipeline, API, testing and Docker configuration.
From raw data to deployable prediction service
The final result was not simply a regression model. I created an end-to-end machine learning workflow that transformed raw transportation data into a trained model and then integrated that model into a functioning prediction service.
The project connected data preparation, machine learning, experiment tracking, software development, API design, automated testing, version control and containerization into one reproducible workflow.
Key takeaways
Consistency matters
The preprocessing used during deployment must match the preprocessing used during model training.
Models are only one component
Building a useful ML product also requires testing, packaging, configuration management and an interface for predictions.
Reproducibility adds value
Separating the workflow into pipeline stages and tracking experiments makes analytical work easier to reproduce and maintain.
Interested in the technical details?
View the project repository or explore more of my data analytics, machine learning and business intelligence work.
View Project Code View More Projects