Real-Time and Streaming Data Processing
Streaming questions test whether you understand unbounded data. Core concepts: event time versus processing time, watermarks to bound lateness, windows (tumbling, sliding, session), state and checkpointing for fault tolerance, and exactly-once versus at-least-once semantics. On Alibaba Cloud, Flink is the stream engine, DataHub and Log Service are common sources, and Hologres or AnalyticDB are common sinks for serving.
Traps abound. Candidates treat processing time as event time and then cannot explain late-arriving data; they assume a tumbling window overlaps (it does not - sliding windows do); they forget that state must be checkpointed to survive failure; and they describe exactly-once as free when it depends on source/sink support and idempotent writes. Another trap is confusing DataHub (ingestion) with Flink (processing).
A useful mental model: source → operator with keyed state → window → sink, with watermarks flowing through and checkpoints snapshotting state.
Worked example: count orders per minute where events may arrive up to two minutes late. Use event-time tumbling windows of one minute with a watermark allowing two minutes of lateness; late events beyond the watermark are dropped or routed to a side output. If you used processing time, a delayed event would land in the wrong minute bucket.
Rule of thumb: window by event time, bound lateness with watermarks, checkpoint state, and confirm sink idempotency before claiming exactly-once.