About this lab
Hearthside Bakeries runs six shops and bakes five products every morning. Today each shop bakes what it sold on the same weekday last week, which misses by about 13 units per product per day: bread in the bin on quiet days, empty shelves on busy ones. The data team has a forecasting model. What it does not have is a way to serve that model every night, let analysts query it, swap in a better version safely, and know when it goes wrong.
In this lab you register a V1 forecaster in the Snowflake Model Registry, score a four-month holdout as one batch with version.run(), and call the same model straight from SQL, proving both paths return identical forecasts. You train a V2 that also uses recent sales history, compare both versions on the same holdout in one query, and promote the winner through the registry default. A view that names only the model switches to V2 with no code change.
You then automate it: new forecast requests land in a table, a stream tracks them, and a scheduled task calls a Python stored procedure that scores each request exactly once. When the real sales land, a monitoring query compares every forecast with what sold, using the registry's own metric as the baseline, and catches a store whose demand suddenly dropped. Finally you deploy V2 as an always-on model service on Snowpark Container Services and call it through its SQL service function, getting the same forecasts as the warehouse.
Lab details
- Level: Intermediate
- Cloud: Snowflake
- Domain: Data Science & MLOps
- Duration: 120 minutes
What you will learn
- Run batch inference on a warehouse with version.run() and write the forecasts to a table
- Call specific and default model versions directly from SQL, including from a view
- Compare a V2 candidate on the same holdout and promote it through the registry default without changing any caller
- Automate incremental scoring with a stream, a Python stored procedure, and a scheduled task, and prove it ran
- Monitor forecasts against actuals and flag drift using the registry's own metric as the baseline
- Deploy the model as a service on Snowpark Container Services and call it from SQL
Concepts covered
- Model Registry versions and the default version
- Batch inference vs SQL inference vs a container service
- A stable input contract across model versions
- Promotion and rollback without code changes
- Incremental scoring with streams and tasks
- Model monitoring and drift detection
- Snowpark Container Services
Technologies used
- Snowflake Model Registry
- Snowflake Notebooks
- XGBoost and scikit-learn
- Streams and Tasks
- Python Stored Procedures
- Snowpark Container Services
Prerequisites
- Basic SQL (SELECT, JOIN, GROUP BY) and basic Python
- Know what a train/test split and mean absolute error are
- A Snowflake trial account with the ACCOUNTADMIN role
Topics
- Snowflake
- Snowpark ML
- Model Registry
- MLOps
- Model Deployment
- Batch Inference
- Model Serving
- Snowpark Container Services
- XGBoost
- Streams
- Tasks
- Forecasting
- Python
- SQL
