Microsoft Fabric promises to end the fragmentation of modern data stacks — but what actually is it, and how does it work? This foundational lesson breaks down every Fabric workload, explains how OneLake eliminates data duplication, and shows exactly where Power BI fits into the picture.
Imagine you're a data analyst at a mid-sized retail company. You pull sales data from your ERP system into Excel, your colleague in engineering is running Spark jobs on a data lake in Azure, and your BI team is maintaining a Power BI dataset that nobody fully trusts anymore because it's three ETL hops away from the source. Sound familiar? Most organizations don't have a data problem — they have a fragmentation problem. Their data tools are scattered, their storage is duplicated across systems, and getting everyone on the same page means stitching together a half-dozen products with custom connectors and prayer.
Microsoft Fabric is Microsoft's answer to that fragmentation. Launched in general availability in November 2023, Fabric is an end-to-end analytics platform that combines data engineering, data warehousing, data science, real-time analytics, and business intelligence under one roof — all built on a single shared storage layer called OneLake. Instead of buying and stitching together Azure Data Factory, Azure Synapse, Azure Data Lake Storage, and Power BI separately, Fabric brings all of those capabilities into a single, unified experience.
By the end of this lesson, you'll have a clear mental model of what Fabric is, what it's made of, how OneLake works, and exactly how Power BI plugs into the platform. This is the foundation you need before you start building anything inside Fabric.
What you'll learn:
No prior experience with Microsoft Fabric is required. You should be comfortable with the general idea that data moves through a pipeline (from source to storage to report). Basic familiarity with Power BI or cloud services is helpful but not essential.
Before we define what Fabric is, let's be precise about the problem it's solving — because understanding the why will make every design decision in the platform make more sense.
Before Fabric existed, a modern data stack on Azure looked something like this: you'd use Azure Data Factory to move data, Azure Data Lake Storage Gen2 (ADLS) to store raw files, Azure Synapse Analytics to run SQL queries and Spark jobs, and Power BI to build reports. Each of these is a separate product with separate billing, separate access management, separate SDKs, and sometimes separate copies of the same data.
That last point is the killer. If your Data Factory loads raw CSV files into ADLS, then Synapse transforms them into a cleaned table, then Power BI imports that table into its own in-memory cache — you now have three copies of the same data. When the source system changes, you have to chase updates through every layer. And when something breaks at 2 AM, figuring out which layer broke is its own investigation.
Key insight
The fundamental design goal of Microsoft Fabric is not "more features." It's consolidation — one storage layer, one governance model, one billing unit, and one user experience across all the analytics tools your organization needs.
Fabric achieves this by making every workload — whether it's a Spark notebook, a SQL warehouse, or a Power BI report — operate on the same underlying data rather than maintaining separate copies. That's the premise. Now let's look at how it works.
Microsoft Fabric is organized around workloads — purpose-built experiences for different kinds of data work. Think of Fabric as a single apartment building where each floor is a different department, but everyone shares the same plumbing. The plumbing is OneLake (more on that shortly). The floors are the workloads.
Here are the main workloads in Fabric today:
Data Engineering — This is where data engineers build and run Spark notebooks and Spark job definitions. If you need to read a raw JSON file, flatten it, apply some business logic, and write out a clean Parquet table, this is your workload. It uses Apache Spark under the hood, the same distributed computing engine used across the industry for large-scale data transformation.
Data Factory — This workload handles data movement and orchestration. It's where you build data pipelines (formerly called ADF pipelines) and Dataflow Gen2. If you need to pull data from a Salesforce API every night at midnight, land it in your lakehouse, and trigger a transformation job afterward, Data Factory is where that orchestration lives.
Data Warehousing — Fabric includes a full SQL analytics warehouse that supports T-SQL queries, stored procedures, and views. This is purpose-built for structured, relational workloads. If your finance team wants to run ad-hoc SQL queries on cleaned financial data, this is their home.
Real-Time Intelligence — This workload handles streaming data. It includes Eventstream for ingesting real-time event data (think IoT sensors, clickstreams, or payment events) and KQL databases (using Kusto Query Language) for ultra-fast time-series querying. If you're monitoring server health in near real-time or analyzing live web traffic, this is your workload.
Data Science — This workload brings machine learning capabilities into the platform. Data scientists can work in Spark notebooks (the same ones from Data Engineering), use MLflow for experiment tracking, and train and register models. If you're building a customer churn model using your lakehouse data, this workload is where that happens.
Power BI — Yes, Power BI is one of the Fabric workloads. It's the reporting and business intelligence layer of the platform. Semantic models (what used to be called datasets), reports, and dashboards all live here.
Note
You don't have to use all of these workloads. A small team might only use Data Factory and Power BI. A larger team might use all six. Fabric is designed so you can adopt workloads incrementally as your needs grow.
OneLake is the single most important concept in Microsoft Fabric. Everything else is built on top of it.
Here's the analogy that makes it click: think about OneDrive for personal file storage. No matter what app you use — Word, Excel, PowerPoint — when you save a file, it goes into the same OneDrive. You don't maintain a separate storage account for each Office application. OneLake is OneDrive for data — a single, organization-wide data lake that all Fabric workloads read from and write to.
Every Fabric tenant (your organization's instance of Fabric) gets exactly one OneLake. It's automatically provisioned when your organization enables Fabric — there's nothing to set up. Inside OneLake, data is organized into workspaces and then into items like lakehouses and warehouses.
When you create a lakehouse in Fabric (a lakehouse is a hybrid storage structure that combines the flexibility of a data lake with the query capabilities of a data warehouse), you're not creating a separate storage account. You're creating a logical container inside OneLake. The files and tables that live in that lakehouse are stored in OneLake in a well-known folder structure, using Delta Lake format for tables.
Delta Lake is an open-source storage format built on top of Parquet files. It adds ACID transactions (meaning your data stays consistent even if a write operation fails halfway through), schema enforcement, and the ability to query historical versions of a table — a feature called time travel. Delta Lake has become the industry standard for data lake tables, and Fabric adopts it as its native format.
Tip
Because Fabric stores everything in Delta Lake / Parquet format in OneLake, you can access your Fabric data directly from other tools — Azure Databricks, Azure Synapse, or even raw Python scripts — without any data export step. OneLake exposes a standard ADLS Gen2 API, so anything that can talk to Azure Data Lake can read your Fabric data.
The transformative thing about OneLake is what it does to data duplication. In a traditional architecture, your data engineer would load data into a Spark environment (one copy), your warehouse would import a transformed version (second copy), and Power BI would cache an aggregated version (third copy). Three copies, three places to update, three potential sources of inconsistency.
In Fabric, when your Data Engineering workload writes a cleaned Delta table to a lakehouse, that same table is immediately accessible to your SQL warehouse via a shortcut (a pointer, not a copy), your data science notebooks, and Power BI — all reading the same underlying files in OneLake. When the data changes, it changes once, and every tool sees the new version.
Warning
"One copy" doesn't mean instant consistency everywhere. When you write a large batch of data to OneLake, there can be a short window before all query engines reflect the latest state. For most analytics workloads this is fine, but if you're building real-time dashboards from batch pipelines, design your refresh schedules with this in mind.
OneLake also supports a feature called shortcuts — virtual pointers to data that lives outside OneLake. For example, if your IT team already has years of historical data sitting in an Azure Data Lake Storage Gen2 account or an Amazon S3 bucket, you can create a shortcut to that storage location inside your Fabric lakehouse. From Fabric's perspective, that external data looks like it's part of OneLake. Your Spark notebooks and SQL queries can access it without any data migration.
This is enormously practical for organizations that have existing data lakes. You don't have to "move everything to Fabric" on day one. You can create shortcuts to your existing storage, start building on top of it, and migrate incrementally.
Three organizational concepts govern how you work inside Fabric: workspaces, capacities, and items.
A workspace is a collaborative container — think of it like a project folder for your team. All Fabric items (lakehouses, warehouses, notebooks, pipelines, reports) live inside workspaces. You might have a workspace called "Finance Analytics" containing all the lakehouses, pipelines, and Power BI reports relevant to the finance team.
Workspaces control access: you grant colleagues roles (Viewer, Contributor, Member, Admin) at the workspace level, and they inherit appropriate access to everything inside. This is where governance happens in practice — if you only want the engineering team to modify pipelines but let business users view reports, you set that up at the workspace level.
A Fabric capacity is the compute resource that powers everything. When you provision Fabric, you're purchasing a capacity measured in CUs (Capacity Units), formerly called F-SKUs (F2, F4, F8, F16, etc.). Your capacity is the engine. All the workspaces and workloads assigned to that capacity share its compute.
You don't pay separately for each workload. One capacity covers Spark jobs, SQL queries, pipeline runs, and Power BI refreshes for all the workspaces assigned to it. This is a significant billing simplification compared to managing separate Azure services.
Tip
Fabric capacities can be paused when not in use, which is ideal for development environments. If your dev workspace only runs jobs during business hours, you can schedule the capacity to pause overnight and resume in the morning — and you stop paying for compute during the pause.
An item is any artifact you create inside a workspace. Lakehouses, SQL warehouses, notebooks, data pipelines, Dataflow Gen2 flows, semantic models, reports, dashboards — each of these is an "item." Items are the building blocks of your analytics solution.
The item concept matters because Fabric manages lineage across items. You can see which pipelines write to which lakehouses, which semantic models read from which warehouses, and which reports are built on which semantic models — all through the built-in lineage view in a workspace. This makes impact analysis much easier: before you change a table schema, you can see exactly which downstream reports and models depend on it.
Power BI is not just a reporting tool that "connects to" Fabric. It's a fully integrated workload within Fabric, and the integration is deeper than anything that existed before.
In classic Power BI, when you published a dataset (now called a semantic model), it lived entirely within the Power BI service — a separate, siloed system. If you wanted to query that model's data from outside Power BI, your options were limited and often awkward.
In Fabric, semantic models are Fabric items. They live in workspaces alongside lakehouses and notebooks. More importantly, a semantic model can now be connected directly to a lakehouse or warehouse using a mode called Direct Lake — and this is where things get genuinely exciting.
Traditionally, Power BI offered two ways to connect to data:
Direct Lake is a third option, unique to Fabric. In Direct Lake mode, Power BI reads Delta Lake files directly from OneLake — no import, no copying, no DirectQuery round-trips. The query engine loads column data from Parquet files on demand and caches it efficiently. You get import-speed performance on data that's always current, without the refresh-schedule bottleneck.
Key insight
Direct Lake mode fundamentally changes the reporting story in Fabric. A data engineer can finish writing a pipeline at 9:03 AM, and a Power BI report in Direct Lake mode can reflect that new data at 9:04 AM — no scheduled refresh required. For organizations that currently run overnight imports and wonder why their morning dashboards show yesterday's numbers, this is a meaningful improvement.
It's worth being clear: the Power BI you know hasn't gone away. You still build reports in Power BI Desktop (or in the browser), you still create DAX measures and calculated columns, you still design visuals the same way. The user experience for report authors and business users is unchanged.
What's changed is the plumbing beneath the report. Instead of your semantic model sitting in an isolated Power BI silo, it's now a citizen of the Fabric ecosystem — sharing governance, storage, and lineage with all the other data work happening in your organization.
You don't need to build anything complex to start getting oriented in Fabric. This exercise will walk you through the experience of accessing Fabric and seeing how workloads are organized.
Step 1: Access Microsoft Fabric
Navigate to app.fabric.microsoft.com in your browser and sign in with your Microsoft 365 or organizational account. If your organization has enabled Fabric, you'll land on the Fabric home page. If you're exploring on your own, Microsoft offers a free Fabric trial — look for "Start trial" in the top-right menu of the Power BI service.
Step 2: Explore the workload switcher
In the bottom-left corner of the Fabric interface, you'll see an icon that indicates the current workload (it might say "Power BI" or show a grid icon). Click it to open the workload switcher — a panel that lists all available workloads: Data Engineering, Data Factory, Data Science, Data Warehousing, Real-Time Intelligence, and Power BI. Click through a few of them and notice how the left-hand navigation changes for each one. The experience adapts to the kind of work you're doing, but you're always inside the same platform.
Step 3: Create a workspace
From any workload view, click "Workspaces" in the left navigation, then click "New workspace." Give it a name like "Fabric Learning." For this exercise, the default settings are fine. Click "Apply." You've just created your first Fabric workspace — the container where all your future items will live.
Step 4: Browse the item creation menu
Inside your new workspace, click the "New" button (or look for a "+ New item" option). Browse the list of item types you can create. You'll see options spanning all the workloads: Lakehouse, Warehouse, Notebook, Data pipeline, Dataflow Gen2, Semantic model, Report, and more. This single creation experience — one place to create any kind of data artifact — is a small but meaningful signal of Fabric's unified design.
Step 5: Check the OneLake data hub
In the left navigation, look for "OneLake catalog" or "Data hub" (the exact label may vary slightly by version). This view shows all the data items across your Fabric environment that you have access to — lakehouses, warehouses, and shortcuts. As your organization builds out more Fabric content, this becomes a searchable catalog of all available data assets.
Tip
Even if you don't have a paid Fabric capacity yet, the free trial gives you a full F64 capacity for 60 days. That's more than enough to work through all the exercises in this learning path.
"I can't find the Fabric workload switcher." If you only see Power BI options, your organization may not have enabled Microsoft Fabric yet, or your account may not have a Fabric license assigned. Check with your Microsoft 365 administrator. Individual users can also enable a personal Fabric trial through the Power BI service settings.
"I created a lakehouse but I can't see it in Power BI." Make sure you're looking in the same workspace in both contexts. Fabric items are workspace-scoped. A lakehouse in the "Finance Analytics" workspace will only appear as a data source when you're creating a semantic model or report in that same workspace (or have explicitly been granted cross-workspace access).
"My Direct Lake report isn't showing the latest data." Direct Lake mode automatically picks up new data as Delta files are written, but there's a metadata step called framing that happens periodically. If you need to force a refresh of the metadata frame, you can trigger a semantic model refresh manually — this is much faster than a full import refresh because it's not copying data, just updating the metadata pointer.
"I don't know which workload to use for my task." Use this rough guide: moving data from external sources → Data Factory. Transforming data with code → Data Engineering. Querying data with SQL → Data Warehousing. Building reports → Power BI. Streaming events → Real-Time Intelligence. Training ML models → Data Science. Many real projects use multiple workloads in sequence.
"Fabric seems expensive. How does pricing work?" Fabric runs on capacity-based pricing. You pay for the capacity (F-SKU) you provision, not per-query or per-user. A smaller F2 capacity is inexpensive and suitable for development. Production workloads typically start at F8 or F16. Because one capacity covers all workloads, you're not paying separately for Spark, SQL, and Power BI Premium — it's bundled.
Let's consolidate what you've learned.
Microsoft Fabric is a unified analytics platform that brings data engineering, data warehousing, data science, real-time analytics, and business intelligence into a single environment, organized around a shared storage layer called OneLake.
OneLake is the single, tenant-wide data lake at the heart of Fabric. It stores everything in open Delta Lake (Parquet) format, eliminates data duplication by letting all workloads read the same files, and supports shortcuts to external storage without requiring data migration.
Workloads — Data Engineering, Data Factory, Data Warehousing, Real-Time Intelligence, Data Science, and Power BI — are purpose-built experiences for different kinds of data work, all operating on the same underlying OneLake storage.
Workspaces organize items (lakehouses, warehouses, notebooks, reports) into collaborative containers with role-based access. Capacities provide the shared compute that powers all workloads assigned to them.
Power BI is a first-class workload inside Fabric, not an add-on. The Direct Lake connection mode lets Power BI reports read directly from Delta files in OneLake, delivering import-speed performance on data that's always current.
Key insight
Microsoft Fabric isn't just "Azure data tools, packaged together." The OneLake foundation genuinely changes the economics and architecture of analytics by eliminating the data duplication that plagues traditional multi-tool stacks.
Where to go from here:
The natural next step is to get hands-on with the core storage artifact in Fabric: the lakehouse. Understanding how lakehouses are structured — the difference between the Files section and the Tables section, how Delta tables are managed, and how to load your first data — will give you the foundation to work with every other Fabric workload. From there, you'll be ready to explore how data pipelines move data, how Dataflow Gen2 handles transformation without code, and how Spark notebooks give you full programmatic control over your data.
The platform is large, but it's also surprisingly coherent once you understand the central role OneLake plays. Everything connects back to that single storage layer — and once that mental model clicks, the rest of Fabric starts to make intuitive sense.
Microsoft Fabric Fundamentals