Comparison
Event timevsProcessing time
Event time
the phone was in a tunnel, so the tap happened at 14:02 and your job saw it at 16:40, and the hourly chart has to put it at 14:00.
The moment the thing actually happened, carried on the record itself. Every result that is supposed to be stable — yesterday's totals, an hourly chart, a session length — has to be computed on event time, because processing time changes if you re-run the job. It is also the harder clock: it arrives out of order, it can be arbitrarily late, and it is only as trustworthy as the device that stamped it.
Full entry →Processing time
you restarted the job to fix a bug and every bucket moved, because the buckets were made from when the job read the record.
The clock on the machine doing the work, at the moment it handles the record. It is always available, always in order and never late, which makes it a tempting default and makes every result computed on it irreproducible. Use it for operational questions about the pipeline itself — throughput, lag, how busy a consumer is — and never for a number a person will compare week to week.
Full entry →