DAA-C01 Question 218
Single answer3.4 Perform forecasting.A retail analytics team stores three years of daily sales in a Snowflake table with columns STORE_ID, SALES_DATE, and NET_SALES. They want to generate a 30-day forecast for each store directly in Snowflake and compare predicted values with actuals as new data arrives. The team needs a solution that minimizes custom model code and supports SQL-based consumption by downstream dashboards. Which approach best meets these requirements?
- A
Create a Snowflake ML Forecast model using STORE_ID as a series column, SALES_DATE as the timestamp column, and NET_SALES as the target, then use the forecast output in SQL for downstream reporting.
- B
Train a classification model in Snowflake because forecasting is a categorical prediction problem, then convert class probabilities into daily sales amounts.
- C
Use a window function such as AVG(NET_SALES) OVER (PARTITION BY STORE_ID ORDER BY SALES_DATE ROWS BETWEEN 29 PRECEDING AND CURRENT ROW) as the production forecasting solution because moving averages are equivalent to forecast models.
- D
Export the data from Snowflake and build separate Python scripts outside Snowflake for each store, because Snowflake cannot generate multi-series forecasts directly from a single historical table.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake ML Forecast on the historical sales table with STORE_ID as the series key, SALES_DATE as the time index, and NET_SALES as the value to predict. This aligns with Snowflake best practices for performing forecasting directly where the data resides, reducing data movement and operational complexity. It also supports a practical analytics workflow: train or fit the forecast model in Snowflake, generate a 30-day horizon, and then compare forecasted values with actual sales as they arrive using standard SQL joins and downstream BI tools. Alternatives such as classification are fundamentally the wrong modeling type, while simple moving averages are only heuristic baselines and not substitutes for a managed forecasting capability. Exporting data to custom external scripts increases maintenance burden and is unnecessary when Snowflake provides native forecasting functionality for multi-series time-series use cases.
- A. Correct.
Correct. Snowflake ML Forecast is designed for time-series forecasting and supports generating forecasts from historical data stored in Snowflake. In a realistic multi-store scenario, the series identifier is STORE_ID, the time column is SALES_DATE, and the target is NET_SALES. This approach minimizes custom model code and keeps the workflow in Snowflake, where forecast results can be queried with SQL and joined to actuals for dashboarding and performance monitoring.
- B. Incorrect.
Incorrect. Classification models predict discrete classes, not continuous numeric values like daily sales. Converting classification probabilities into revenue amounts is not an appropriate or standard forecasting approach and would produce poor results. A candidate might choose this if they confuse predictive modeling in general with time-series forecasting specifically.
- C. Incorrect.
Incorrect. A moving average can be useful as a baseline or smoothing technique, but it is not equivalent to a forecasting model designed to learn time-series patterns and produce future predictions. It also does not satisfy the requirement for a managed forecasting solution that minimizes custom logic. This distractor targets the common misconception that any trend calculation is a true forecast.
- D. Incorrect.
Incorrect. Snowflake can support forecasting workflows directly on data in Snowflake, including scenarios with multiple time series distinguished by an identifier column. Exporting data and building one script per store adds operational overhead and contradicts the requirement to minimize custom model code and support SQL-based consumption. Someone might choose this if they assume forecasting must be done externally in a separate ML platform.