Overview#
A semantic layer strategy decides where business logic, measures, relationships, security, and model reuse live before reports are built [S1]. In Fabric, that strategy must account for Power BI consumption, semantic model storage modes, Direct Lake over OneLake, capacity memory, table layout, and governance through shared models [S1] [S2] [S3] [S4] [S5].
Core concepts#
A semantic model is the reusable analytical model consumed by Power BI reports and other clients [S1]. Storage mode choices shape freshness and performance: Import keeps a refreshed copy, DirectQuery leaves queries in the source engine, Composite mixes table modes, and Direct Lake reads Delta data from OneLake without a traditional import copy [S1] [S2].
Direct Lake is powerful when curated Delta tables in OneLake should feed interactive BI, but it still depends on model size, column residency, and the memory envelope of the capacity SKU [S2] [S3]. The storage shape behind the model matters because Direct Lake reads Parquet/Delta data from OneLake and loads columns on demand [S2] [S4].
Semantic layer decision matrix#
| Decision | Prefer | Watch-out | Source |
|---|---|---|---|
| Shared enterprise metrics | Certified reusable semantic model | Avoid one-off measures recreated per report | [S1] [S5] |
| Current lake data without import refresh | Direct Lake | Model footprint and column residency must fit capacity behavior | [S2] [S3] |
| Source-engine freshness with no lake materialization | DirectQuery | Query latency and source load remain part of report performance | [S1] |
| Mixed freshness or table behavior | Composite model | Complexity rises when storage modes differ by table | [S1] |
| Large model | Capacity-aware design | SKU memory bounds influence resident data behavior | [S3] |
How it works and best practices#
Start with business ownership and metric consistency. Create shared semantic models for certified KPIs and let reports reuse them instead of recreating calculations per report [S1] [S5]. Choose Direct Lake when OneLake Delta data is the authoritative analytical source and the model can be shaped to fit the capacity envelope [S2] [S3]. Use Import or Composite when the source shape, transformation requirement, or performance profile makes a materialized model more appropriate [S1] [S2].
Use a thin-report pattern where reports contain visuals and report-specific layout while measures, relationships, roles, and table definitions live in the shared semantic model [S1] [S5]. Inference: this keeps governance and testing focused on fewer model artifacts, while still allowing many reports to serve different audiences [S1] [S5].
-- Illustrative model-owned measures.
-- The source-backed guidance is to centralize reusable business logic in semantic models.
Total Revenue = SUM ( Sales[RevenueAmount] )
Gross Margin % =
DIVIDE ( [Total Revenue] - SUM ( Sales[CostAmount] ), [Total Revenue] )
Direct Lake design checklist#
semantic_model:
source: curated_delta_tables_in_onelake
storage_mode: direct_lake
design_controls:
- remove_unused_columns
- keep_relationship_columns_intentional
- validate_capacity_memory_behavior
- test_cold_and_warm_query_paths
- certify_shared_model_before_report_sprawl
Inference: this checklist is an operating practice derived from sourced Direct Lake and large-model behavior: Direct Lake loads needed columns from OneLake and large models are constrained by capacity memory characteristics [S2] [S3] [S4].
What goes wrong#
Too many one-off semantic models fragment metrics and security rules [S1]. Using Direct Lake without controlling table layout, column count, and model footprint can shift bottlenecks from refresh to cold reads and capacity memory pressure [S2] [S3] [S4].
Another failure is confusing freshness with semantic correctness. Direct Lake can avoid a scheduled import copy, but it does not define business measures, relationships, row-level security, or endorsement policy for you [S1] [S2] [S5].
Internals#
Architecture & design#
The semantic layer sits between OneLake/warehouse/lakehouse data and report consumption, translating data into relationships, measures, roles, and query plans [S1]. Direct Lake connects that model layer to OneLake Delta files through the Analysis Services engine [S2].
How it works internally#
Direct Lake loads columns on demand, including columns required by relationships and measures [S2]. Large-format semantic model behavior is constrained by capacity memory, which controls how much data can remain resident [S3].
Performance characteristics#
Performance depends on storage mode, model footprint, relationship design, measure complexity, column residency, and capacity size [S1] [S2] [S3]. Direct Lake avoids import refresh but does not remove the need for semantic modeling discipline [S2].
Table layout underneath Direct Lake also matters: column selection, row group/file shape, and whether queried columns stay resident affect cold and warm query behavior [S2] [S4]. Inference: performance testing should include first-query and repeated-query scenarios, not only steady-state report interactions [S2] [S4].
Worked example#
A finance team can publish one certified semantic model over curated OneLake Delta tables using Direct Lake, centralize revenue and margin measures, and let departmental reports reuse that model [S1] [S2] [S5]. If cold reads become visible under load, the team should reduce unnecessary columns, improve source table layout, or resize capacity rather than duplicating the model per report [S2] [S3] [S4].
Curated gold tables in OneLake
-> Direct Lake semantic model
-> Measures: Total Revenue, Gross Margin %, Forecast Variance
-> Roles: Finance Viewer, Finance Analyst
-> Certified shared model
-> Executive report
-> Department report
-> Analyst exploration report
The important boundary is that reports consume the model; they do not redefine the enterprise measures locally unless a report-specific calculation is intentionally isolated [S1] [S5].