ARA-C01 Question 279
Single answerSnowpipe StreamingA financial services company is redesigning its market-data ingestion pipeline to reduce end-to-end latency from tens of seconds to sub-second visibility in Snowflake. The current design uses files landed in cloud storage and Snowpipe auto-ingest, but architects want application services to push records directly into Snowflake without managing staged files. The solution must support high-throughput streaming ingestion, minimize operational overhead, and allow downstream consumers to query newly ingested rows quickly. Which approach should the architect recommend?
- A
Use Snowpipe Streaming with the Snowflake Ingest SDK so the application can stream rows directly into Snowflake tables without staging files first.
- B
Continue using Snowpipe auto-ingest, but reduce file sizes aggressively so each file contains only a few rows to achieve sub-second latency.
- C
Use tasks to poll an internal stage every second and execute COPY INTO commands, because tasks provide the same direct-row streaming behavior as Snowpipe Streaming.
- D
Use external tables over the landing zone and create a materialized view to provide low-latency access to newly arrived records without loading them into Snowflake tables.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowpipe Streaming with the Snowflake Ingest SDK. Snowpipe Streaming is intended for scenarios where applications need to ingest rows directly into Snowflake with lower latency than file-based Snowpipe, while reducing the need to create, stage, and manage micro-batch files. In contrast, classic Snowpipe is optimized for continuous file loading from stages, not direct row streaming. Tasks plus COPY INTO remain batch/file-oriented, and external tables are for querying data in external storage rather than ingesting it into Snowflake-managed tables. This distinction is important for architecture decisions on low-latency pipelines. Refer to Snowflake documentation on Snowpipe Streaming and the Snowflake Ingest SDK, which describes direct streaming ingestion for near-real-time use cases and contrasts it with traditional file-based Snowpipe.
- A. Correct.
Correct. Snowpipe Streaming is designed for low-latency, high-throughput ingestion directly from client applications into Snowflake, avoiding the need to stage files in cloud storage first. This aligns with the requirement to reduce latency to near real time, simplify operations, and make data queryable quickly after ingestion. The Snowflake Ingest SDK is the supported client-side mechanism for implementing this pattern.
- B. Incorrect.
Incorrect. Standard Snowpipe auto-ingest is file-based. Making files extremely small can reduce delay somewhat, but it increases file-management overhead and is not the intended architecture for sub-second streaming use cases. It also does not eliminate the operational burden of managing staged files. This option reflects a common misconception that smaller files make file-based ingestion equivalent to streaming ingestion.
- C. Incorrect.
Incorrect. Tasks can schedule SQL execution, but they do not provide direct streaming ingestion semantics. Polling a stage with frequent COPY INTO operations still relies on staged files and introduces orchestration overhead. It also does not match the requirement for applications to push records directly into Snowflake without file staging.
- D. Incorrect.
Incorrect. External tables expose data in external storage for query, but they are not a substitute for Snowpipe Streaming and do not provide direct streaming inserts into native Snowflake tables. Materialized views on external tables also do not change the fact that the architecture remains storage-based rather than direct-ingest, and they are not the recommended design for sub-second operational ingestion.