Tag: Lakehouse

  • Medallion Architecture & Delta Lake in Microsoft Fabric Lakehouse

    ← Back to Microsoft Fabric — Complete Learning Series

    Lakehouse Deep Dive, Part 2: Medallion Design, Storage, and Delta Lake

    This post is Part 2 of the Lakehouse series and focuses on three areas: Medallion Architecture as the Lakehouse’s natural design pattern, Lakehouse storage using files and Delta tables, and Delta Lake as the engine that powers the Lakehouse.

    Medallion Architecture: The Lakehouse’s Natural Design Pattern

    This section covers Medallion Architecture and explains why it is a natural design pattern for the Lakehouse.

    Bronze, Silver, and Gold Explained

    This part of the deep dive focuses on Bronze, Silver, and Gold layers and how they are explained within the Medallion Architecture.

    Why Medallion Works Perfectly in Fabric

    This part describes why the Medallion Architecture works particularly well in Fabric.

    Lakehouse Storage: Files and Delta Tables

    This section of the deep dive covers Lakehouse storage, focusing on files and Delta tables.

    Two Types of Assets

    This part describes two types of assets in Lakehouse storage: files and Delta tables.

    When to Use Each

    This part explains when to use files and when to use Delta tables in the context of Lakehouse storage.

    Delta Lake: The Engine Behind the Lakehouse

    This section focuses on Delta Lake as the engine that powers the Lakehouse.

    ACID Transactions

    This part covers ACID transactions in Delta Lake.

    Schema Evolution

    This part covers schema evolution in Delta Lake.

    Time Travel

    This part covers time travel capabilities in Delta Lake.

    Partitioning

    This part covers partitioning in Delta Lake.

    Z-Order

    This part covers Z-order in Delta Lake.

    File Compaction

    This part covers file compaction in Delta Lake.

    Open Format

    This part covers Delta Lake as an open format.

    In the next post in this Lakehouse series, we will move from concepts to implementation and focus on SQL Endpoint, Direct Lake, and building a Lakehouse step by step.

    Lakehouse Series Navigation (Part 2 of 5)

    Previous in Series

    What Is a Lakehouse? — And Why It Replaced Data Lakes & Warehouses

    Next in Series

    SQL Endpoint, Direct Lake & Building a Lakehouse Step-by-Step in Microsoft Fabric

    Related Posts

    ← Back to Microsoft Fabric — Complete Learning Series

  • What Is a Lakehouse? — And Why It Replaced Data Lakes & Warehouses

    ← Back to Microsoft Fabric — Complete Learning Series

    Lakehouse Foundations · Part 1 of 5

    Why the Lakehouse Became the New Standard

    Modern analytics teams have been stuck between two imperfect options for years: fast but rigid data warehouses, or flexible but chaotic data lakes. Both solved important problems, but neither could deliver a complete, governed, end-to-end analytics platform on its own. This post kicks off a five-part series on the Lakehouse — and how Microsoft Fabric turns the idea of a unified analytics platform into a practical reality.

    The Old World: Lakes vs. Warehouses

    For a long time, organizations had to choose between two very different analytics worlds — and live with the trade-offs.

    Data Lakes

    Data lakes are flexible, scalable, and cost-effective. They are ideal for raw data, machine learning workloads, and handling unstructured assets.

    But when it comes to SQL analytics, strong governance, and reliable BI performance, traditional lakes fall short. The result is often a messy, hard-to-govern environment.

    Data Warehouses

    Data warehouses are structured, governed, and fast. They excel at dimensional modeling and powering business intelligence reports.

    However, they struggle with unstructured data, streaming scenarios, and very large-scale transformations, making them a poor fit for many modern analytics needs.

    This split forced teams into an uncomfortable reality: two storage systems, two compute engines, two governance models, two security layers, two ingestion pipelines, and ultimately, two competing versions of the truth.

    What Is a Lakehouse?

    The Lakehouse emerged to resolve this tension by combining the best properties of both lakes and warehouses in a single architecture.

    A Lakehouse brings together the flexibility of a data lake, the structure of a warehouse, the performance of columnar storage, the openness of Delta Lake, and the governance capabilities of enterprise systems.

    Just as important is what a Lakehouse is not. It is not a warehouse simply sitting on top of a lake. It is not a Spark cluster with SQL bolted on. It is not a BI model that happens to use lake storage. And it is certainly not just a marketing term.

    Instead, a true Lakehouse is a unified architecture where raw files, Delta tables, SQL endpoints, Spark notebooks, BI models, and machine learning workloads all operate on the same data, in the same place, under the same governance model.

    Fabric’s Lakehouse is one of the cleanest implementations of this concept in the industry, bringing these capabilities together in a way that is both powerful and approachable for modern analytics teams.

    The Fabric Lakehouse: What Makes It Different

    Microsoft Fabric takes the Lakehouse idea further than any platform before it. At its core is OneLake, a unified storage layer that serves the entire organization. On top of OneLake, the Fabric Lakehouse brings together storage, compute, governance, and BI in a single experience.

    Key components of the Fabric Lakehouse include:

    • Files — Support for raw data, logs, JSON, CSV, Parquet, images, PDFs, and more.
    • Delta tables — Structured, ACID-compliant, optimized tables that sit directly in OneLake.
    • SQL endpoint — A fully managed SQL engine that queries Delta tables without copying data.
    • Notebooks — PySpark, SQL, Markdown, and ML libraries, all working against the same underlying data.
    • Direct Lake integration — Power BI reads Delta tables directly, eliminating refresh cycles and data duplication.
    • Unified governance — Microsoft Purview provides lineage, labels, and access control in one place.
    • Unified security — Role-based access control is applied consistently across Spark, SQL, BI, and ML workloads.
    • Unified workspaces — Clear Dev/Test/Prod separation, deployment pipelines, and artifact organization.

    The result is not a “Spark-first” or “SQL-first” system. Fabric’s Lakehouse is a unified analytics engine where different personas can work the way they prefer, without fragmenting data or governance.

    Why Lakehouses Matter: The Business Perspective

    Technical details only matter if they move the business forward. Executives and business leaders care about outcomes: faster insights, lower costs, better governance, real-time analytics, reduced complexity, and a unified data strategy. The Lakehouse directly supports all of these goals.

    • Lower costs — Eliminates duplication across separate lake, warehouse, and BI systems.
    • Faster development — One platform, one storage layer, and one security model shorten the path from idea to insight.
    • Real-time analytics — Direct Lake integration removes traditional refresh cycles and copies.
    • Stronger governance — Purview governs data, analytics, and BI assets centrally.
    • Enterprise scalability — Delta Lake supports massive datasets without sacrificing performance or reliability.
    • Unified collaboration — Data engineers, BI developers, and data scientists all work on the same data, instead of maintaining separate pipelines.

    In other words, the Lakehouse is not just a technical evolution. It represents a fundamental shift in how organizations think about data, analytics, and governance across the business.

    What Comes Next in This Series

    This first post set the stage by explaining why the Lakehouse has become the new standard for modern analytics, and how Microsoft Fabric delivers a particularly strong implementation.

    In the rest of this five-part series, we will build on this foundation and explore how the Lakehouse model shapes architecture, development workflows, and analytics experiences across the organization.

    By the end of the series, you will have a clear mental model for how a Lakehouse works in practice and how Fabric can support your data, BI, and AI strategy on a single, unified platform.

    Lakehouse Series Navigation

    Previous in this series

    No previous post.

    Next in this series

    Medallion Architecture & Delta Lake in Microsoft Fabric Lakehouse

    Related posts

    ← Back to Microsoft Fabric — Complete Learning Series

  • SQL Endpoint, Direct Lake & Building a Lakehouse Step-by-Step in Microsoft Fabric

    ← Back to Microsoft Fabric — Complete Learning Series

    Lakehouse Deep Dive, Part 3

    [Intro placeholder – please provide the original text for Part 3 so it can be cleaned up without adding new information.]

    Lakehouse series navigation

    Previous in series (2 of 5)
    Medallion Architecture & Delta Lake in Microsoft Fabric Lakehouse

    Next in series (4 of 5)
    Lakehouse Engineering Best Practices & Security in Microsoft Fabric

    Related posts

    ← Back to Microsoft Fabric — Complete Learning Series

  • Lakehouse Engineering Best Practices & Security in Microsoft Fabric

    Lakehouse Deep Dive, Part 4: Engineering Best Practices and Security

    This is Part 4 of the Lakehouse deep dive series. In this post we focus on two practical topics: how to engineer your Lakehouse for reliable performance and how to set up unified, consistent security across the platform.

    Lakehouse Engineering Best Practices

    The following ten practices help you design Lakehouse workloads that are easier to manage, scale, and optimize over time.

    1. Always Use the Medallion Architecture

    Organize data into Bronze, Silver, and Gold layers so ingestion, cleansing, and serving are clearly separated. This keeps pipelines understandable, supports gradual data refinement, and avoids mixing raw and curated data in the same tables.

    2. Use Delta Lake Everywhere

    Standardize on Delta Lake tables for all Lakehouse storage so you get versioning, reliability, and consistent behavior across ingestion, transformation, and consumption workloads.

    3. Partition Large Tables

    Partition large Delta tables to keep queries efficient and maintenance operations manageable as data volume grows.

    4. Optimize Delta Tables

    Regularly optimize Delta tables so reads and writes stay fast, especially for high-traffic fact tables in your Silver and Gold layers.

    5. Use a Star Schema for the Gold Layer

    Model your Gold layer as a star schema so analytics tools can work with clear fact and dimension tables and you can keep business logic centralized.

    6. Avoid Wide Tables

    Avoid creating very wide tables in the Lakehouse. Keep schemas focused on specific analytical needs rather than combining many unrelated attributes into a single table.

    7. Use Surrogate Keys

    Introduce surrogate keys in your dimensional models so joins are stable and independent of changing source system identifiers.

    8. Use Aggregation Tables

    Create aggregation tables for common reporting patterns so queries do not have to scan detailed fact tables for every request.

    9. Avoid Tiny Files

    Design ingestion and processing so the Lakehouse does not accumulate large numbers of tiny files, which can hurt performance and increase overhead.

    10. Use Deployment Pipelines

    Use deployment pipelines to move Lakehouse changes through environments in a controlled, repeatable way instead of making ad hoc changes directly in production.

    Lakehouse Security: Unified and Consistent

    Security in the Lakehouse should be applied consistently across all entry points, including the Lakehouse itself, the Warehouse, Power BI, notebooks, and pipelines. A unified RBAC (role-based access control) model helps keep permissions aligned for the same users and groups wherever they work.

    RBAC Across the Lakehouse Stack

    Use RBAC to govern access across Lakehouse, Warehouse, Power BI, notebooks, and pipelines so that a user’s role consistently controls what they can see and do, no matter which interface they use.

    The Five Key Security Layers

    A unified security design relies on five complementary layers that work together to protect data and manage access.

    • Workspace roles define who can manage, develop in, or use a workspace at a high level.
    • Item-level permissions control access to specific Lakehouse and Warehouse items.
    • SQL endpoint permissions govern who can query data through SQL endpoints.
    • RLS/OLS in semantic models apply row-level and object-level security for fine-grained control inside Power BI models.
    • Purview sensitivity labels classify and label data so protection and monitoring can follow sensitive information wherever it is used.

    What’s Next in the Series

    The final post in this Lakehouse deep dive series will bring everything together with a look at governance, Dev/Test/Prod strategy, real-world use cases, and a concluding summary of the overall approach.

    Lakehouse Series Navigation (Part 4 of 5)

    Previous in this series

    Part 3 of 5: SQL Endpoint, Direct Lake & Building a Lakehouse Step-by-Step in Microsoft Fabric

    Next in this series

    Part 5 of 5: Lakehouse Governance, Dev/Test/Prod Strategy & Real-World Use Cases in Microsoft Fabric

    Related posts

  • Lakehouse Governance, Dev/Test/Prod Strategy & Real-World Use Cases in Microsoft Fabric

    ← Back to Microsoft Fabric — Complete Learning Series

    Lakehouse Deep Dive, Part 5: Governance, DevOps, and Real-World Use Cases

    This final part of the Lakehouse series brings everything together. It focuses on how governance becomes centralized with Purview integration, how to structure Dev/Test/Prod for a Lakehouse at scale, and how these capabilities show up in seven real-world use cases. It closes by positioning the Lakehouse as the backbone of modern analytics going forward.

    Section 12: Lakehouse Governance — Purview Integration

    Lakehouse governance centers on integration with Purview, which brings together capabilities that were previously scattered across tools and teams. These capabilities include lineage, sensitivity labels, access control, classification, audit logs, and policy enforcement, all unified over Lakehouse assets.

    Lineage Across the Lakehouse

    Lineage tracks how data flows across the Lakehouse, from raw ingestion zones through transformation layers into curated tables, semantic models, and downstream reports. With Purview integration, this lineage is captured consistently for Lakehouse objects, making it possible to understand the impact of changes, trace data quality issues, and support regulatory requirements that depend on end-to-end data traceability.

    Sensitivity Labels and Classification

    Sensitivity labels and data classification can be applied centrally to Lakehouse assets. Classification identifies data domains and categories, while sensitivity labels express how strictly data must be handled. Together, they allow the Lakehouse to consistently tag and protect data, instead of relying on one-off rules in individual tools or datasets.

    Access Control and Policy Enforcement

    Access control is defined and enforced over Lakehouse objects using a unified model. Policies that reference classifications and sensitivity labels can be enforced across data and analytics layers. This means that who can see, query, or export data is governed centrally, rather than being reimplemented separately in each engine or reporting tool.

    Audit Logs and Centralized Governance

    Audit logs capture how Lakehouse data is accessed and governed over time. Combined with lineage, classification, sensitivity labels, and access control, these logs give a full picture of what happened to data and when. Governance is no longer scattered across multiple systems and manual processes; it is expressed once and applied consistently over the Lakehouse.

    Section 13: Lakehouse Dev/Test/Prod Strategy

    A Lakehouse Dev/Test/Prod strategy relies on clear separation of environments, repeatable deployment pipelines, and consistent rules for how assets move from development into production. The core best practices include separate workspaces, deployment pipelines, naming conventions, RBAC roles, parameterized pipelines, version control for notebooks, and semantic model deployment rules.

    Separate Workspaces and Deployment Pipelines

    Dev, Test, and Prod are implemented as separate workspaces. Deployment pipelines move Lakehouse assets across these workspaces in a controlled, repeatable way. This separation reduces risk, supports validation before changes reach production, and provides a clear path for promoting features from development to stable environments.

    Naming Conventions and RBAC Roles

    Naming conventions make Lakehouse assets understandable and predictable across environments. RBAC roles control who can change, deploy, or consume assets in Dev, Test, and Prod. Together, naming and RBAC make it easier to manage large Lakehouse estates and to keep responsibilities clear between engineering, operations, and business users.

    Parameterized Pipelines and Version-Controlled Notebooks

    Parameterized pipelines allow the same logic to run in multiple environments by switching parameters, instead of maintaining separate pipeline definitions. Version control for notebooks brings Lakehouse development in line with software engineering practices, enabling change history, collaboration, and controlled releases of transformation logic.

    Semantic Model Deployment Rules

    Semantic model deployment rules define how models are promoted between Dev, Test, and Prod. These rules cover which changes are allowed, how they are validated, and how they are rolled out to consumers. In the Lakehouse context, this ensures that semantic layers stay in sync with underlying tables and pipelines as they progress through environments.

    Section 14: Real-World Lakehouse Use Cases

    Lakehouse capabilities come together in real-world scenarios. Seven representative use cases illustrate how one Lakehouse, with unified governance and Dev/Test/Prod practices, supports enterprise data lake modernization, real-time analytics, operational visibility, regulatory reporting, customer intelligence, machine learning, and IoT workloads.

    Enterprise Data Lake Modernization

    Enterprise Data Lake Modernization uses the Lakehouse to consolidate existing data lakes, warehouses, and marts onto a single platform. The unified storage format and governance layer allow legacy data platforms to be modernized without losing control over security, lineage, and access policies.

    Real-Time Sales Dashboards

    Real-Time Sales Dashboards rely on the Lakehouse to land and process sales events quickly while keeping them available for reporting on current performance. With a single Lakehouse, real-time and historical sales data share the same storage format and governance model.

    Supply Chain Visibility

    Supply Chain Visibility brings together data from logistics, inventory, orders, and partners into the Lakehouse. With one governance layer, teams can monitor movement, stock levels, and fulfillment status without duplicating data and controls across multiple systems.

    Financial Reporting

    Financial Reporting uses the Lakehouse to centralize financial data in one storage format, with one security model applied consistently. This supports reporting and analytics that depend on strict control over lineage, auditability, and policy enforcement while keeping data accessible to authorized users.

    Customer 360

    Customer 360 aggregates customer data into Lakehouse tables that share a single governance layer. Lineage, sensitivity labels, access control, and classification help manage the mix of personally identifiable data and behavioral signals, while still giving a unified view of customers.

    ML Feature Store

    An ML Feature Store built on the Lakehouse exposes features in the same storage format and governance model as analytical tables. Version-controlled notebooks, parameterized pipelines, and semantic model deployment rules support how features are engineered, validated, and promoted through Dev, Test, and Prod.

    IoT Analytics

    IoT Analytics uses the Lakehouse to store and analyze device data at scale. Real-time and batch processing share the same Lakehouse, so governance, access control, and audit logging apply uniformly across sensor streams, curated aggregates, and downstream dashboards.

    Conclusion: The Lakehouse Is the Backbone of Modern Analytics

    The Lakehouse acts as the backbone of modern analytics by converging data, governance, and operations into a single platform. It delivers one lake, one security model, one governance layer, one storage format, and one experience for data engineering, analytics, and machine learning teams.

    One lake simplifies where data lives. One security model and one governance layer standardize how data is protected, audited, and controlled. One storage format streamlines how data is ingested, transformed, and queried. One experience aligns how teams develop, test, deploy, and consume data products. Together, these Lakehouse principles support the next wave of analytics initiatives that rely on consistency, trust, and scale.

    Lakehouse series navigation

    ← Previous in series (Part 4 of 5): Lakehouse Engineering Best Practices & Security in Microsoft Fabric

    This is the final post in the Lakehouse series (Part 5 of 5).

    Related posts

    ← Back to Microsoft Fabric — Complete Learning Series

  • Microsoft Fabric Workloads — Lakehouses, Warehouses & More

    ← Back to Microsoft Fabric — Complete Learning Series

    Fabric is composed of multiple workloads, each designed for a specific part of the analytics lifecycle. What makes Fabric unique is that all workloads operate on the same underlying data — no copies, no silos, no synchronization.

    The 7 Fabric Workloads

    1. Data Engineering (Lakehouses, Notebooks, Pipelines)

    Build medallion architectures, transform data, orchestrate ingestion.

    2. Data Science (ML Models, Notebooks)

    Train models directly on Delta tables without moving data.

    3. Real‑Time Analytics (Event Streams)

    Ingest and analyze streaming data with low latency.

    4. Data Warehousing (Fabric Warehouse)

    A fully managed SQL warehouse engine for high-concurrency enterprise workloads.

    5. Business Intelligence (Power BI)

    Direct Lake models, dashboards, and reports — always current, no refresh needed.

    6. Governance (Microsoft Purview)

    Lineage, sensitivity labels, access control — built into the platform.

    7. Monitoring & Operations

    Built‑in observability across all workloads.

    Lakehouses — The Heart of Fabric’s Architecture

    The Lakehouse is Fabric’s core data engineering construct. It combines the flexibility of a data lake with the reliability of a warehouse.

    Key components of a Lakehouse:

    • Files — raw data, logs, unstructured assets
    • Tables — Delta Lake tables for structured data
    • SQL Endpoint — query Delta tables using T‑SQL
    • Notebooks — PySpark, SQL, and data science workflows

    Why Lakehouses matter:

    • They support medallion architecture naturally.
    • They unify Spark and SQL workloads.
    • They eliminate the need for separate lake + warehouse systems.
    • They integrate seamlessly with Power BI via Direct Lake.

    A well‑designed Lakehouse becomes the backbone of your entire analytics estate.

    Fabric Warehouse — SQL for the Modern Era

    Fabric Warehouse is a fully managed SQL engine built for high concurrency, fast query performance, and enterprise workloads. It complements Lakehouses by providing a familiar SQL‑first experience for analysts and BI developers — and connects directly to Power BI via Direct Lake.

    Fabric is not a collection of services — it is a single integrated platform.

    Series Navigation

    Previous in this series

    OneLake & Direct Lake — The Foundation of Microsoft Fabric

    Next in this series

    Medallion Architecture in Microsoft Fabric — Bronze, Silver & Gold

    Related posts

    Microsoft Fabric — Getting Started Series

    This is Part 3 of 5: Microsoft Fabric Workloads — Lakehouses, Warehouses & More

    ← Previous: OneLake & Direct Lake — The Foundation of Microsoft Fabric

    Next: Medallion Architecture in Microsoft Fabric — Bronze, Silver & Gold →

    Related Reading

    ← Back to Microsoft Fabric — Complete Learning Series

  • Direct Lake — Lakehouse & Warehouse Integration with a Real-World Architecture Blueprint

    Section 6 — How Direct Lake Integrates with Lakehouses

    Direct Lake is deeply tied to the Lakehouse architecture.

    Lakehouse Components

    • Files (raw data)
    • Delta tables (structured data)
    • SQL endpoint
    • Notebooks
    • Pipelines

    Direct Lake Reads Gold Tables

    In a medallion architecture:

    • Bronze = raw
    • Silver = cleaned
    • Gold = business-ready

    Direct Lake models should always read Gold tables.

    Why Gold Tables?

    • Cleaned
    • Conformed
    • Aggregated
    • Optimized
    • Business-friendly

    This ensures: Fast performance, Accurate analytics, Stable schemas, Predictable modeling.

    Section 7 — How Direct Lake Integrates with Fabric Warehouse

    Fabric Warehouse also stores data in OneLake as Delta tables. This means Direct Lake can read Warehouse tables directly.

    This is a major advantage over traditional warehouses like Snowflake or Synapse.

    Benefits

    • No ETL needed
    • No duplication
    • No refresh
    • No latency
    • Unified governance
    • Unified security

    Warehouse + Direct Lake = SQL + BI in perfect harmony.

    Section 8 — Designing a Direct Lake Architecture (Real-World Blueprint)

    Here is the architecture used by top enterprises adopting Fabric:

    1. Step 1 — Ingest Raw Data into Bronze: Use Pipelines or Event Streams.
    2. Step 2 — Transform into Silver: Use PySpark notebooks.
    3. Step 3 — Model Gold Tables: Use SQL endpoint or notebooks.
    4. Step 4 — Build Semantic Model: Connect Direct Lake to Gold tables.
    5. Step 5 — Publish Dashboards: Power BI reads Delta tables directly.
    6. Step 6 — Add Real-Time Streams: Event Streams → Lakehouse → Direct Lake → Dashboard
    7. Step 7 — Govern Everything: Purview handles Lineage, Sensitivity labels, Access control.
    8. Step 8 — Deploy Across Dev/Test/Prod: Use deployment pipelines.

    This is the modern BI architecture.

    Direct Lake Series Navigation

    This article is Part 3 of 5 in the Direct Lake series.

    Previous: Direct Lake — Why It Matters & How It Compares to Import and DirectQuery

    Next: Direct Lake — Performance Optimization, Limitations & Real-World Use Cases

    Related posts

    📚 Direct Lake Series

    ← Previous: Direct Lake — Why It Matters & How It Compares to Import and DirectQuery | → Next: Direct Lake — Performance Optimization, Limitations & Real-World Use Cases.

    🔗 Go Deeper

    Direct Lake Deep Dive Series

    This is Part 3 of 5 in the Direct Lake Deep Dive Series.

    <!– wp:paragraph –> <p>← Previous: <a href="https://mypbi.org/?p=1209">Direct Lake — Why It Matters &amp; How It Compares to Import and DirectQuery</a></p> <!– /wp:paragraph –> <!– wp:paragraph –> <p>Next →: <a href="https://mypbi.org/?p=1211">Direct Lake — Performance Optimization, Limitations &amp; Real-World Use Cases</a></p> <!– /wp:paragraph –>

    Related Reading

  • OneLake + Delta Lake — The Perfect Combination Powering Every Fabric Workload

    ← Back to Microsoft Fabric — Complete Learning Series

    Why Delta Lake is perfect for OneLake

    • ACID transactions
    • Schema evolution
    • Time travel
    • Partitioning
    • High-performance reads
    • Optimized for columnar analytics
    • Compatible with Spark, SQL, ML, and BI

    Delta Lake is the foundation that makes OneLake fast, reliable, and open.

    SECTION 7 — How OneLake Powers Every Fabric Workload

    OneLake is not a separate service. It is the storage layer for all Fabric workloads.

    How OneLake powers every Fabric workload

    1. Lakehouses — Store files + Delta tables directly in OneLake.
    2. Warehouses — Store SQL tables as Delta in OneLake.
    3. Power BI — Reads Delta tables directly via Direct Lake.
    4. Pipelines — Ingest data into OneLake.
    5. Notebooks — Transform data stored in OneLake.
    6. Event Streams — Write streaming data into OneLake.
    7. ML Models — Train directly on Delta tables in OneLake.
    8. Governance — Purview governs OneLake centrally.

    This is why OneLake is the backbone of Fabric.

    OneLake Series Navigation

    Previous in this series

    OneLake Architecture Deep Dive — How It Works & The Power of Shortcuts

    Next in this series

    OneLake for BI, Engineering, Warehousing, Real-Time & Governance — The Complete Picture

    Related posts

    📚 OneLake Series

    ← Previous: OneLake Architecture Deep Dive — How It Works & The Power of Shortcuts | → Next: OneLake for BI, Engineering, Warehousing, Real-Time & Governance — The Complete Picture.

    🔗 Go Deeper

    ← Back to Microsoft Fabric — Complete Learning Series

My journey from Datum to Data