ARA-C01 Question 192
Single answerOutline basic AI/ML pipelines and applicationsA retail company stores clickstream, customer profile, and purchase data in Snowflake. The data science team wants to build a churn prediction pipeline while minimizing data movement and operational overhead. They need a design that supports feature engineering on current warehouse data, model training with familiar open-source Python libraries, batch scoring back into Snowflake for downstream reporting, and orchestration of the end-to-end workflow. Which approach best meets these requirements?
- A
Export curated data from Snowflake to external object storage, train the model on a separate ML platform, and reload prediction results into Snowflake on a schedule.
- B
Use Snowpark Python for in-database data preparation and feature engineering, train the model in a Snowflake Python environment using supported open-source libraries, write predictions back to Snowflake tables, and orchestrate the pipeline with Snowflake tasks.
- C
Create a materialized view for training data, call a JavaScript stored procedure to train the model, and use streams alone to automate model retraining and scoring.
- D
Replicate Snowflake data into a transactional database for feature engineering, train the model there, and expose predictions to Snowflake through external tables.
Show answer and explanation
Correct answer: B
Explanation
The key architectural principle in this scenario is to keep as much of the AI/ML pipeline as practical close to the governed data in Snowflake. A basic ML pipeline typically includes data preparation, feature engineering, model training, inference, storage of predictions, and orchestration. For Snowflake-based architectures, Snowpark provides a strong option for data preparation and feature engineering using Python against Snowflake data. Batch prediction outputs can be persisted back into Snowflake tables for reporting, dashboards, or downstream applications. Tasks are the native scheduling/orchestration mechanism for recurring steps in the pipeline. By contrast, exporting data to external ML systems may still be valid in some organizations, but it adds movement, latency, and operational overhead. Relevant Snowflake documentation areas include Snowpark for Python, Python worksheets/stored procedures and supported package execution patterns, streams and tasks for pipeline automation, and general best practices for minimizing unnecessary data movement in analytical architectures.
- A. Incorrect.
This approach works technically, but it does not best meet the stated goal of minimizing data movement and operational overhead. Exporting data to another platform for training and then reloading predictions introduces additional pipelines, storage integration steps, data synchronization concerns, and governance complexity. It is a common legacy pattern, but Snowflake-centric AI/ML pipelines are typically designed to keep data processing close to the data when possible.
- B. Correct.
This is the best answer. Snowpark Python supports data engineering and feature engineering directly against data in Snowflake. Snowflake supports Python execution environments and integration with common open-source libraries for data science use cases, allowing teams to build parts of ML workflows without unnecessary data export. Writing predictions back into Snowflake tables supports downstream BI and operational consumption. Snowflake tasks are an appropriate orchestration mechanism for scheduled pipeline steps such as feature generation, batch inference, and related SQL or procedural workflow stages. This design aligns with the requirement to reduce data movement while supporting practical end-to-end ML operations.
- C. Incorrect.
This option includes multiple misconceptions. A materialized view can help with query performance for stable transformations, but it is not a model training mechanism. JavaScript stored procedures are intended for procedural logic, not as a standard approach for ML model training with Python ML libraries. Streams track data changes for CDC-style processing, but streams alone do not orchestrate a complete retraining and scoring workflow; tasks are typically used with streams for automation.
- D. Incorrect.
This design increases complexity and data movement rather than reducing it. Replicating analytical data from Snowflake into another database for feature engineering is generally counter to the stated objective. External tables are for querying data files in external stages, not for directly exposing predictions from another database system as an integrated ML serving layer. This is a plausible distractor for candidates who assume ML must happen outside Snowflake, but it is not the best architectural choice here.