A team builds a "Direct Lake" "semantic model" over Delta tables in a "Lakehouse". Reports must read brand-new rows the instant data engineers write them, and the model must keep working even if the read-only "SQL analytics endpoint" lags behind the latest Delta commit. Which "Direct Lake" variant should the engineer choose?
- A"Direct Lake" on OneLake, which reads the Delta tables straight from "OneLake" and does not depend on the "SQL analytics endpoint" staying in sync with the latest commit Correct
- B"Direct Lake" on SQL endpoint, which routes every read through the "SQL analytics endpoint" so the model always matches what that endpoint currently exposes to queries
- CImport mode refreshed on a schedule, which loads the Delta rows into the model cache so reports query an in-memory copy that is fast and fully detached from "OneLake"
- DDirectQuery over the "SQL analytics endpoint", which pushes each report query to the endpoint at run time so visuals always resolve against the live SQL surface
Why A is correct: "Direct Lake" on OneLake binds to the Delta tables in "OneLake" directly, so it reflects the newest committed rows without waiting for the read-only SQL surface to refresh its metadata.
Why B is wrong: This variant resolves tables through the "SQL analytics endpoint", whose metadata sync can lag the latest Delta commit, so it can miss the freshest rows the stem demands.
Why C is wrong: Import duplicates the data and only updates on a refresh schedule, so brand-new rows are invisible until the next refresh, which contradicts the instant-freshness requirement.
Why D is wrong: DirectQuery still depends on the "SQL analytics endpoint" and gives up the in-memory speed of "Direct Lake", so it both lags and performs worse than the required approach.