An analyst already has gallery sensor readings landed in an Eventhouse and wants to quickly check, ad hoc, which vault exceeded a vibration threshold in the last hour before deciding whether to escalate. Which tool should the analyst reach for first?
Select an answer to reveal the explanation.
Short Explanation
Think of KQL like walking straight up to the live-monitor desk and asking the guard a quick question, instead of photocopying the whole tape first. Since the data's already sitting in the Eventhouse, a direct KQL query is the fastest way to get an answer.
Full Explanation
KQL is the native query language for an Eventhouse and is designed for exactly this pattern: fast, ad hoc, time-windowed filtering over data that's already landed, using operators built for bucketing and comparing against a threshold within a recent time range. Since the sensor readings are already in the Eventhouse, querying them there avoids any unnecessary movement of data. Building a new Dataflow Gen2 to re-ingest the same data into a Lakehouse adds a whole pipeline and a second copy of the data just to answer a one-off question, which is wasted effort and introduces latency the analyst doesn't have time for. Reading the data into a Spark notebook DataFrame works technically, but it means spinning up a Spark session and writing code for a query KQL already answers directly and faster against the source. There is no built-in Warehouse mirror of Eventhouse data in this scenario, and even if one existed, adding a T-SQL hop over a mirrored copy is a slower, more indirect path to the same one-hour window a direct KQL query answers immediately. Before escalating, double check the KQL time filter is using the same time zone as the physical sensor logs to avoid a false positive.