In Part 1, we answered the question What is Microsoft Fabric?
In Part 2 we will cover how Fabric is structured. Specifically:
- Where the data actually resides
- How Fabric organizes it
- How the Lakehouse and Warehouse models relate to one another
NTK -- a Lakehouse is where Fabric keeps large analytics data in open files, but organized just enough that you can still query it like tables.
A Warehouse is Fabric’s table-based view of your data that can be queried with SQL.
The way Fabric stores and structures data is what ultimately determines whether the platform is a good match for your organization.
ONELAKE
Fabric’s storage architecture begins with OneLake, a single logical data lake automatically provisioned for each tenant. You do not create multiple lakes. You do not manage storage accounts. Fabric enforces a unified model.
Under the covers, OneLake uses Azure Data Lake Storage Gen2, but Fabric abstracts those details so every workload uses the same storage foundation. This means that
- Spark, SQL, Data Engineering, Real-Time Analytics, and Power BI all write to OneLake
- Analytics storage becomes centralized
- Governance and security follow one path instead of many
This is not a new type of storage — it is a new way of managing consistency across analytics workloads.
LAKEHOUSE
A Lakehouse is Fabric’s structured layer on top of OneLake. It stores data in open formats (Delta/Parquet) and maintains managed metadata so that engines can query the same physical data without creating copies.
A Lakehouse provides:
- Open file-based storage in Delta/Parquet
- A managed metadata layer
- Access from Spark for large-scale processing
- A SQL analytics endpoint operating over the same data
The result is that data engineering and analytics teams stop exchanging extracts and instead work from a single authoritative source.
WAREHOUSE
Fabric’s Warehouse exposes the relational interface — tables, schemas, tSQL — while still storing all data in OneLake. It does not introduce a new database engine or separate storage. The Warehouse is designed for analytical workloads, not OLTP.
The Warehouse
- Uses the same underlying open table formats as the rest of Fabric
- Provides SQL modeling without duplicating datasets
- Focuses on reporting and analytical query patterns
Functionally, it’s the relational counterpart to the Lakehouse — helpful, structured, but not a replacement for SQL Server.
How do these pieces fit together?
Fabric’s architecture is intentionally consistent:
- OneLake is the unified storage layer
- The Lakehouse and Warehouse are two organizational models over that same storage
- All compute engines — Spark, SQL, BI, and real-time processing — operate against the shared data rather than isolated silos
This is a shift away from the 'pipeline-first, storage-everywhere' model that many organizations fell into. Fabric reduces fragmentation not by adding more engines, but by removing redundant copies and enforcing a single storage foundation.
Why this matters to SQL Server professionas?
Fabric is not designed to replace SQL Server. It is designed to replace the analytics systems that surround SQL Server — the extracts, one-off lakes, unmanaged BI storage, and the disconnected systems built over time to satisfy individual reporting needs.
When datasets land in Fabric:
- They are stored in one place
- They are accessible through multiple engines
- They are governed consistently
- They do not require separate operational overhead
Fabric is an analytical unification platform, and its storage model is the reason it works.
COMING NEXT
In Part 3, we will move from structure to movement: how data actually lands in Fabric, which ingestion methods exist today, and how to adopt Fabric without rebuilding your entire environment.
More to Read:
No comments:
Post a Comment