- End-to-end ML pipeline for RTB task
- README contains 3 parts:
- Setup instruction
- Project structure
- Approach description and considerations
-
Ensure the environment:
- Create
venvwith IDE - Install the dependencies with
pip install -r requirements_venv.txt - Make sure that Docker daemon is up and running, e.g. check with
docker ps
- Create
-
Put the raw data
training_data.csv.gzandtest_data.csv.gzintodata/rawproject local folder:
- Run the master script to consequently initialize Airflow, build Docker image and start all components as containers:
sh run.sh- Visit
http://localhost:8080/and log in using the credentials:user=airflowandpassword=airflow. There are two DAGs, for train and predict:
- Run the training DAG first:
- As a result, it creates in the project the following files:
data/processed/train_df.csv- processed dataset for trainmodels/pipeline_*.pkl- trained model/pipelinereports/report_*.yaml- cross-validation metrics and model parameters
- Next, run the predicting DAG:
- As a result, it creates the following files:
data/processed/test_df.csv- processed dataset for testdata/predictions/predictions_*.npy- probability predictions for test data
- Check out the tasks (containers) logs, if needed, as well as intermediate and resulting files.
├── airflow <- Airflow folder
│ ├──dags <- DAGs folder
│ | ├── pipeline <- Job Dockerfile and pipelines DAG files
│ | | └── Dockerfile
│ | | └── predict_pipeline.py
│ | | └── train_pipeline.py
│ ├──config
│ ├──logs <- Airflow auxiliary directories
│ └──plugins
│
├── data
│ ├── predictions <- Saved model predictions as NumPy arrays
│ ├── processed <- The final, canonical data sets for modeling
│ └── raw <- The original, immutable data dump
│
├── imgs <- Images for README
│
├── models <- Trained and serialized models (sklearn pipelines)
│
├── notebooks <- Jupyter notebooks with exploration
│ └── eda.ipynb <- Exploratory Data Analysis│
│
├── reports <- YAML reports with models parameters and validation metrics
│
├── src <- Source code for use in this project
│ ├── __init__.py <- Makes src a Python module
│ ├── config.py <- Config file with namings/parameters
│ │
│ ├── data <- Scripts to generate datasets
│ │ └── make_dataset.py
│ │ └── preprocessing.py
│ │
│ ├── models <- Scripts to train models and make predictions
│ │ ├── make_predicting.py
│ │ ├── make_training.py
│ │ ├── pipeline.py
│ │ └── utils.py
│ │
├── LICENSE
├── .env <- Environment variables
├── .gitignore
├── README.md
├── run.sh <- Master script to run the project
├── .flake8 <- Style checker config
├── requirements.txt <- Packages required for Docker tasks
├── requirements_venv.txt <- pip freeze of project's venv for full reproducibility
└── docker-compose.yaml <- Airflow services for pipeline
- Description of the pipeline and design choices:
- The train and predict pipelines are separated. The train pipeline is intended for periodic offline training, while the predict pipeline is designed to run as frequently as needed and utilizes the trained model.
- The approach incorporates containerization to keep Airflow and its components running in containers as services. Each of the DAG's tasks is executed with DockerOperator, enabling independent and customizable environments for various types of tasks.
- As a predictive model it's used a LogReg classifier for simplicity which sets a baseline of prediction metrics
and can be further improved. It's recommended to use a DL model with Embeddings layers to handle high cardinality of
categorical features, e.g.
nn.Embeddingrepresents each category as embedding vector, then all the tensors are concatenated alongside with numerical features and passed forward to dense layers.
- Additional considerations for deploying such a approach at scale:
- Fast real-time inference: the model must efficiently process input data, make predictions, and store results in a key-value store, such as Aerospike, for subsequent use by the other backend services.
- Model as a service: the model can be encapsulated as an API, such as FastAPI, to deliver optimal performance and serve as a service for other processes and pipelines. Real-time event stream processing, such as Apache Kafka, is useful for handling vast of messages.
- Extra considerations:
- deployment strategies and approaches:
- Deployment: it's good to use serverless functions, e.g. AWS Lambda, GCP Functions, or Azure Functions for on-demand scaling.
- Containerization: it's applicable to use Docker and Kubernetes for containerized deployments.
- API gateway: there's a way to use an API gateway like AWS API Gateway or GCP Endpoints to expose the model as a RESTful API.
- Scalability: it's critical to ensure that deployment is scalable to handle varying levels of traffic and requests.
- potential challenges and nuances:
- Low Latency: achieving low latency in RTB is crucial, the infrastructure and model should respond within milliseconds.
- Model Drift: continuously monitor and retrain the model to account for concept drift in user behavior and market conditions.
- Data Privacy: if applicable, the privacy regulations, e.g. GDPR, CCPA, are important while using user data.
- Cost Optimization: advance DL models perform great but requires GPUs resources and cost, then managing infrastructure costs and optimizing bidding strategies to maximize ROI for advertisers.
- AB Testing and Evaluation: every model update should be tested against the control version to ensure the uplift in performance.
- Monitoring and Logging: comprehensive monitoring and logging to track the performance and health of RTB system.
- deployment strategies and approaches:
Project based on the cookiecutter data science project template. #cookiecutterdatascience



