Power BI Architecture Choices for Azure Databricks (w/ Liping Huang)

LIVESTREAM DATE/TIME 📅

October 16th 2026 - 9:30 AM (Pacific Time)

DESCRIPTION 📄

Power BI gives you four main ways to report on data that lives in Azure Databricks: Direct Lake on OneLake, Direct Lake over mirrored Unity Catalog tables, DirectQuery against a Databricks SQL warehouse, and a composite model with import aggregations. Liping Huang wrote Microsoft's new white paper benchmarking all four side by side, and joins me to walk through the results.

The test runs the same TPC-DS data at roughly 26 million, 260 million and 2.6 billion rows, across cold, warm and hot cache, three filter scenarios and a 20-user load test. No pattern wins everywhere. Direct Lake holds up best for the warm and hot cache reports people open every day, queries that hit an aggregation table stay under 100ms at every volume, DirectQuery catches up (and sometimes wins) at 2.6 billion rows on an X-Large warehouse, and mirrored Unity Catalog tables slow down badly as the data grows.

GUEST BIO (NAME HERE) 👤

Liping Huang is the CEO of Data Leaps and a Data & AI Architect, blogger, YouTuber, keynote speaker and user group organizer (ex-Microsoft, ex-Databricks). Liping works with Tabular Editor as Field CTO for APAC and is passionate about helping Power BI users build better semantic models faster, creating content about Tabular Editor, Power BI, Fabric and Databricks on the Data Leaps YouTube channel and at dataleaps.co.uk.

RELATED CONTENT 🔗

White Paper (PDF)
White Paper Announcement
Data Leaps
Data Leaps YouTube
Liping's LinkedIn

Model Your Data in Power BI: Star Schemas, Filter Flow & Field Lists

Video by: Reid Havens

Plenty of Power BI issues that look like DAX issues start one layer down, in the model. The formula is correct, the relationship underneath it isn't doing what you assumed, and you spend an afternoon rewriting a measure that was never the problem.

This one covers the foundation the rest of it sits on. Why a model beats one giant flat table (smaller storage, better compression, faster refresh, and filter paths you get without writing any code), how dimensions and facts split the who-what-when-where from the numeric events, and what actually happens when someone picks a value in a slicer and that filter travels down the relationship into the fact table.

Then star versus snowflake, compared on the four things that decide it in practice: query performance, DirectQuery latency, how long the DAX ends up, and whether business users can find a field without asking someone. Star wins on all four. I also get into why the snowflake version keeps turning up anyway, since it usually arrives from a source system rather than from a decision anyone made.

The last section is the one that gets skipped. Every visual in Power BI generates a query with three ingredients (filter, group, summarize), and once that clicks, a wrong number stops being mysterious. After that it's the fields list itself: friendly names instead of cgo_key_fk, display folders, hidden keys, and descriptions that surface as tooltips. It sounds cosmetic, but an unreadable fields list is how you end up with six competing Excel copies of the same report.

Materialized Lake Views in Microsoft Fabric: How They Actually Work

Video by: Reid Havens

Every report hitting your raw tables runs the same expensive joins and aggregations over and over, even when the underlying data hasn't moved. Materialized Lake Views in Microsoft Fabric pre-compute those results once and store them as Delta tables in OneLake, so consumers read finished numbers instead of recalculating from scratch.

In this video I cover what MLVs actually are, how the automatic refresh logic decides between skip, incremental, and full rebuild, the Spark SQL syntax to create and manage them, and where they sit in a medallion architecture (think of them as a "Gold+" layer).

The part worth sticking around for: point Direct Lake at an MLV instead of your raw tables and you get pre-aggregated data at import speed. In the example here, a 50 million row fact table collapses to around 500K. Fewer rows means faster transcoding into VertiPaq and a lot less DirectQuery fallback risk. That's the single best reason to pair the two.

I also get into when NOT to use them, because they're not free. Sub-minute volatile data, tiny tables, and row-level security needs are all cases where an MLV is the wrong tool.

Your Core Model Isn't Supposed to Do Everything | Power BI Extensibility Layer Objects

Video by: Reid Havens

Here's something that trips up a lot of Power BI developers: not everything belongs in your core semantic model. Some objects are meant to live in a departmental layer. Some belong in a single report, knowing the difference changes how you build, and how well your architecture holds up over time.

In this video I walk through Power BI's extensibility layer objects: what they are, where each one belongs in your architecture, and when to actually use them.

RELATED CONTENT 🔗

Full Guide | Analytic Endeavors