Snowflake ML and Data Science Reference Architecture

The usual ML architecture has a seam down the middle: data lives in the warehouse, models are trained somewhere else, and the pipeline between them is the part that breaks. This reference architecture removes the seam by making the warehouse the training environment — the same governed tables that feed reporting also feed feature engineering, training and inference, and the model that comes out is a schema-level object in the same account.

How it works

Training data starts where the application produces it. A streaming service buffers it for continuous ingestion, then batches it to the data lake or sends it directly to Snowflake. From there the ingestion path depends on the format and the layout: Snowpipe for files landing in a stage, Snowpipe Streaming and the Kafka connector for row-level ingestion, external tables for data that should be queried without being copied, and Iceberg Tables where reads and writes must operate on Parquet and Iceberg metadata in storage the customer owns.

Once the data is queryable, tasks schedule stored procedures to transform it, and streams chain into tasks to build a real pipeline rather than a single job. That is what produces the curated tiers a data scientist actually wants to train on.

Training happens in the same place. Snowpark gives an API for querying and processing data in the pipeline, and the Snowpark ML Modeling API brings scikit-learn and XGBoost feature engineering and model training to that data without moving it out. Heavier runs go to Snowpark-optimized warehouses through Python stored procedures; GPU work goes to Snowpark Container Services. Teams that would rather train on Dataiku, Hex or Azure ML still can — the Snowpark DataFrame API pushes preprocessing and training down to the warehouse, and the resulting model is registered back to the Snowflake Model Registry, which stores models and their metadata as first-class schema-level objects whatever their origin.

Serving splits by latency. Real-time predictions are a UDF call, an External Function to an API-hosted endpoint, or an online inference service in Container Services. Batch predictions read an input table and write an output table the application reads. Cortex sits beside both: LLM and ML-based functions callable from one line of SQL or Python, hosted and managed by Snowflake so no GPU infrastructure has to be provisioned to use them. Streamlit in Snowflake closes the loop, letting a data scientist put an interface on the results without leaving the platform.

The original design

The diagrams above are redrawn in the site’s own style from Snowflake’s ML and data science reference architecture, published in 7 Snowflake Reference Architectures for Application Builders. Credit for the original architecture and diagram belongs to Snowflake.

What to get right

• Decide what actually needs to be ingested. External tables and Iceberg Tables exist so data already sitting in object storage does not need a second copy and a second pipeline to keep it fresh. Copy what benefits from being copied.
• Snowpark-optimized warehouses are a different resource, not a bigger one. They exist for the memory profile of training runs; putting that work on a standard warehouse is where “it worked on the sample” becomes an out-of-memory error on the full dataset.
• Register every model, including the ones trained elsewhere. The Model Registry is only a control point if the externally-trained models are in it too — otherwise half the fleet is governed and half is a notebook someone ran.
• Pick batch or real-time per prediction, not per project. Batch scoring into an output table is cheaper and simpler; keep UDF and endpoint inference for the predictions that genuinely have to happen inside the request.
• Reach for Cortex before standing up GPUs. For classification, forecasting and LLM tasks that a hosted function already covers, managed inference removes an entire layer of infrastructure from the architecture.