SnowPro Associate: Platform Question 241
Single answer● Warehouse sizingA data engineering team runs a nightly ETL job on a Snowflake virtual warehouse. The job is a single sequence of large transformation queries with no meaningful concurrency, and it is currently running on a SMALL warehouse. The team wants to reduce the total job completion time without changing the SQL logic. Which action is the most appropriate first step?
- A
Resize the warehouse from SMALL to a larger size, such as MEDIUM or LARGE, and measure whether the queries complete faster
- B
Enable multi-cluster scaling so multiple clusters can process each ETL query in parallel
- C
Create additional virtual warehouses of the same size and split the ETL job across them automatically
- D
Reduce the warehouse size and rely on result caching to speed up the transformation queries
Show answer and explanation
Correct answer: A
Explanation
Warehouse sizing in Snowflake should match the workload pattern. For low-concurrency workloads made up of large, compute-heavy queries, the best first step is usually to scale up to a larger warehouse and compare elapsed time and credit usage. Snowflake documentation distinguishes between scaling up, which increases resources available to execute queries, and scaling out with multi-cluster warehouses, which is designed for concurrency rather than speeding up a single query. In practice, teams should test larger warehouse sizes, monitor query history and execution times, and choose the size that provides the best balance of performance and cost.
- A. Correct.
Correct. Increasing warehouse size adds more compute resources to a single cluster, which can improve execution time for compute-intensive queries. For a workload that is primarily a single stream of large queries with low concurrency, scaling up the warehouse is the appropriate first action to test. This aligns with Snowflake guidance that larger warehouses can improve performance for individual query execution, while cost should be balanced against runtime gains.
- B. Incorrect.
Incorrect. Multi-cluster warehouses are primarily intended to handle higher concurrency by adding clusters when many queries run at the same time. They do not make a single query run faster by splitting one query across multiple clusters. This option reflects a common misconception that multi-cluster scaling is a general performance feature for any slow workload.
- C. Incorrect.
Incorrect. Additional warehouses do not automatically accelerate a single sequential ETL pipeline. Separate warehouses can isolate workloads, but Snowflake will not automatically distribute one sequence of dependent queries across multiple warehouses. This would also add operational complexity without addressing the main issue: each large query needs more compute.
- D. Incorrect.
Incorrect. Reducing warehouse size would generally provide less compute and likely increase execution time for large transformation queries. Result caching is also unlikely to help a nightly ETL job that performs transformations on changing data, because cache reuse depends on identical queries and unchanged underlying data. This option combines two common misunderstandings: that smaller warehouses can somehow be more efficient for heavy processing, and that caching is a reliable solution for ETL transformations.