fabric-eventhouse-rti

KQL uses a pipe-based syntax where you filter by time first, such as `Logs | where ingestion_time() > ago(1h) | summarize count() by AppName`. Always place the temporal filter on the first line to trigger partition predicate pushdown for fast queries.

Use Eventhouse for continuous streaming data, sub-second dashboards, and high-volume telemetry with short TTL. Use Lakehouse for batch data, stable schemas, complex joins, and BI reports with Direct Lake over large historical volumes.

SQL SELECT/WHERE becomes `table | where x == 'y' | project col`, GROUP BY becomes `| summarize count() by col`, and LIKE becomes `| where col contains "text"`. KQL has no UPDATE or DELETE; corrections use new schemas or materialized views.

Yes, a single Eventstream supports fan-out to multiple simultaneous destinations such as Eventhouse for real-time analysis, Lakehouse for Delta history, and Activator for alerts, without duplicating the source connection.

Activator monitors Eventstreams or Eventhouse data and triggers actions like email, Teams messages, webhooks, or Power Automate when conditions are met. Configure threshold, anomaly, or dead-source triggers with a cooldown period to avoid alert flooding.

Slow queries usually result from missing temporal filters, which prevents partition pruning, or from querying cold storage instead of hot cache. Filter by ingestion_time() first, adjust the table caching policy, and use materialized views for recurring aggregations.