A fraud team needs website clickstream events analyzed within a few seconds of each click. Today the web servers write events to log files that a batch job loads into the database once each night. Which data acquisition approach meets the new requirement?
Select an answer to reveal the explanation.
Short Explanation
Batch is the mail truck that comes once a day; streaming is the phone call that comes the second something happens. If fraud must be caught within seconds, you can't wait for any truck, even an hourly one. Speeding up the batch is the trap: faster batch is still batch.
Full Explanation
Data sources can be consumed as streaming or non-streaming. Non-streaming, or batch, acquisition collects data over a period and loads it in bulk on a schedule, which is efficient but introduces latency equal to at least the batch interval. Streaming acquisition treats data as a continuous, unbounded flow of events: producers publish each event as it happens, and consumers process it within moments, which is what a requirement measured in seconds demands. For clickstream fraud detection, events would be sent from the web tier to a stream or message platform and processed continuously, with results written to the database or alerting system. Hourly batch loads reduce latency from a day to an hour, but an hour is still far outside a few seconds, so the requirement is not met. Nightly compressed extracts over SFTP improve transfer efficiency and security, but they remain a once-a-day batch. Weekly snapshots are even more delayed and are a recovery or copy mechanism, not an acquisition method for near-real-time analysis. Exam caveat: streaming adds operational complexity, including ordering, duplicate events and back-pressure, so it is justified when latency requirements demand it rather than by default. Operational check: measure end-to-end latency by comparing each event's creation timestamp with its arrival time in the target and alert when it exceeds the agreed threshold.