COF-C03 Question 230
Single answerSnowpipe streamingA retail company captures point-of-sale events from thousands of stores and needs to load the events into Snowflake with sub-second latency for real-time dashboards. The architects want to avoid managing cloud storage stages and file-based micro-batches, while still using a fully managed ingestion service. Which approach should they choose?
- A
Use Snowpipe Streaming with the Snowflake Ingest SDK to write rows directly into a target table.
- B
Use Snowpipe with auto-ingest on an external stage and send each event as an individual file to cloud storage.
- C
Use a COPY INTO command on a schedule every minute to load files from an internal stage.
- D
Use tasks to poll a stream every few seconds and insert new rows into the target table.
Show answer and explanation
Correct answer: A
Explanation
The best choice is Snowpipe Streaming because it addresses all stated requirements: very low latency, no need to manage cloud storage stages for ingestion, and use of a managed Snowflake ingestion pattern. In contrast, standard Snowpipe is continuous but file-based, relying on staged files and event notifications. COPY INTO is batch-oriented, and streams/tasks are processing and orchestration features rather than direct ingestion services. Snowflake documentation distinguishes Snowpipe Streaming from traditional Snowpipe by highlighting direct row ingestion through the Snowflake Ingest SDK for near-real-time use cases.
- A. Correct.
Correct. Snowpipe Streaming is designed for low-latency row ingestion directly into Snowflake tables without requiring files to land in cloud storage first. It uses the Snowflake Ingest SDK and is appropriate when the goal is near-real-time ingestion with reduced dependency on staged files and external event notifications.
- B. Incorrect.
Incorrect. Standard Snowpipe auto-ingest is a managed continuous loading service, but it is file-based and depends on data landing in a stage such as Amazon S3, Google Cloud Storage, or Azure Blob Storage. Sending each event as a separate file would add overhead and does not match the requirement to avoid managing stages and file-based micro-batches.
- C. Incorrect.
Incorrect. COPY INTO is effective for batch loading but is not intended for sub-second continuous ingestion. Scheduling COPY every minute introduces additional latency and still depends on staged files, which conflicts with the stated architecture goals.
- D. Incorrect.
Incorrect. Streams and tasks are used for change data capture and orchestration inside Snowflake after data is already available in tables. They are not an alternative ingestion mechanism for pushing event rows directly from an application into Snowflake.