Vibration-sensor readings from a museum's vault racking arrive at an Eventhouse table with an explicit event-time column, but network buffering means the rows are not always ingested in the same order the sensors generated them. An analyst writing a KQL query needs results grouped strictly by when each vibration actually occurred, not by when the row reached the Eventhouse. Which approach should the analyst take?
Select an answer to reveal the explanation.
Short Explanation
Order of arrival and order of occurrence aren't the same thing, and KQL keeps both available. Bin your summarize on the sensor's own event-time column and the analysis reflects when the vibration actually happened, no matter how buffering shuffled the arrival order.
Full Explanation
Eventhouse tables commonly carry two distinct timestamps: ingestion_time(), which reflects when a row physically landed, and an explicit event-time column supplied by the source, which reflects when the underlying event actually occurred. Because network buffering can reorder arrivals, only grouping by the event-time column with summarize ... by bin(EventTime, ...) guarantees the vibration readings are bucketed by when they truly happened rather than by ingestion order.
Relying on natural row order after a one-time sort at ingestion fails because Eventhouse is an append-optimized store for continuously arriving data; a single sort does not hold as new, possibly out-of-order rows keep streaming in afterward. Rebuilding the table daily to physically reorder rows is both unnecessary and wasteful — KQL's bin() and summarize operate correctly over unsorted data as long as the correct time column is referenced, so no physical reordering is required. Switching to hourly batch loads changes the ingestion cadence but does nothing about ordering within a batch, and it also abandons the low-latency streaming capability the scenario doesn't ask to give up.
A caveat: a null or malformed event-time silently drops a row from time-based grouping, so queries should filter or coalesce it first. Operationally, compare a spot-check query grouped by event-time against one grouped by ingestion_time to confirm the two produce different, and the event-time one more accurate, bucket counts.