ARA-C01 Question 260
Single answerData in motionA retail company ingests order events from Kafka into Snowflake using Snowpipe Streaming. The architecture team must support near-real-time dashboards while keeping compute cost predictable. During peak traffic, event volume spikes sharply for 20-30 minutes, and analysts notice that some dashboards temporarily lag. The team wants to improve freshness without introducing unnecessary warehouse usage or relying on staged files. Which approach best aligns with Snowflake best practices for data in motion in this scenario?
- A
Continue using Snowpipe Streaming and tune the client-side channel buffering/flush behavior so records are committed more frequently during spikes, while monitoring ingestion lag
- B
Replace Snowpipe Streaming with standard Snowpipe on internal stages because file-based micro-batches provide lower latency for real-time dashboards
- C
Load all Kafka events into a temporary table first, then run scheduled COPY INTO commands every minute from the temporary table into the target table
- D
Create a dedicated virtual warehouse for Snowpipe Streaming ingestion and scale it up during peak periods to reduce streaming ingest latency
Show answer and explanation
Correct answer: A
Explanation
For data-in-motion scenarios requiring near-real-time ingestion from Kafka, Snowpipe Streaming is the native Snowflake capability intended to reduce latency compared with file-based ingestion patterns. It avoids the need to stage files and does not rely on a user-provisioned virtual warehouse for the ingestion service. When lag appears during traffic spikes, architects should first evaluate producer and client SDK behavior, including buffering, batching, and flush/commit frequency, because these directly affect end-to-end freshness and throughput tradeoffs. Standard Snowpipe remains appropriate for continuous file ingestion, but it is generally not the best fit when the requirement is very low latency and no staged files. This aligns with Snowflake best practices and product guidance for streaming ingestion architectures, including using Snowpipe Streaming for low-latency data pipelines and separating ingestion considerations from downstream warehouse sizing for transformations and analytics.
- A. Correct.
Correct. Snowpipe Streaming is designed for low-latency ingestion without requiring files in stages or customer-managed warehouses for the ingest path. In a near-real-time Kafka scenario, adjusting the client SDK behavior such as buffering and flush frequency can help balance latency and throughput during spikes. Monitoring ingestion lag and tuning the producer/client behavior is the appropriate architectural response when freshness degrades under bursty traffic.
- B. Incorrect.
Incorrect. Standard Snowpipe is file-based and depends on staged files and event-driven or REST-triggered loading. It is useful for continuous ingestion, but it typically does not provide lower latency than Snowpipe Streaming for event-at-a-time or very small micro-batch use cases. This option also conflicts with the requirement to avoid relying on staged files.
- C. Incorrect.
Incorrect. This introduces unnecessary complexity and is not how Snowflake ingestion is typically architected for Kafka event streams. COPY INTO loads from files in stages, not by periodically copying rows from one table to another as an ingestion mechanism. Using temporary tables in this way would not solve the core streaming freshness issue and adds avoidable operational overhead.
- D. Incorrect.
Incorrect. Snowpipe Streaming ingestion does not use a customer-managed virtual warehouse for the ingestion service itself. Scaling a warehouse would only affect downstream query or transformation workloads, not the core ingest latency of Snowpipe Streaming. This reflects a common misconception that all ingestion performance in Snowflake is warehouse-driven.