Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work, opening the data problem and the head fake one hundred words. Your sales team has a spreadsheet, finance has a database support has a pile of CSV exports, and somewhere in SharePoint three versions of the same file are living separate lives. Everyone wants a power BI report, but nobody agrees which number belongs in it. Most teams think they need more storage, but they don't. They need their data to stop living separate lives. Raw files need a place to land, while trusted business tables need a place where people can query them. That's the real tension here. And Microsoft Fabric brings those needs together through the lakehouse. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. The old split data Lake versus Data Warehouse five hundred and fifty words. The old way of handling data created that mess. For years, teams used two different homes for data. One was the data lake, a kind of big storage area where you could drop anything before you knew what to do with it. CSV files, application logs, Json files, sensor readings, images, documents, exports from every system across the business could all land there, and that freedom helps. A data lake doesn't demand that every source arrive in perfect rows and columns. If a new app sends event logs every hour, those logs stay. If a vendor delivers a monthly Excel export, you store it. You keep the original input, which matters. When someone asks, where did this number come from? But raw data gets messy fast. A sales export might name a customer column cust name, while another system calls it customer name. One file stores dates as day, month, year, another as month. Day. Year. Some rows have blanks, others have duplicate orders. And you can't run a report on a column. That means two different things. The data lake can hold all of it, but holding data and trusting data are two different jobs. That's where the data warehouse comes in. It takes selected data, cleans it, shapes it into structured tables, and gets it ready for reporting. Analysts get a controlled space to use SQL connect reports and answer common questions without untangling every source file first. It gives you confidence that when you ask for revenue, you get one answer. Picture a retail company. Each morning it gets sales CSV files from stores. Its customer system holds account records, and its support platform tracks tickets and response times in a data lake. Those sources arrive in their original form. That's useful because the company hasn't thrown anything away or forced everything into the same shape too early. Then the reporting team needs answers. Sales by region. Sales by product. Repeat customers support cases linked to high value accounts. They don't want to open fifteen raw files and guess which column means what. They want tables with clear names. Known data types and agreed rules. So the company copies data from the lake into a warehouse, and the warehouse becomes the clean reporting home. That works well, but it creates a new tension. And that's when trust starts to crack. Now you've got one copy of sales data in the source system, another in the data lake, another in the warehouse, and maybe another extract inside a report or departmental spreadsheet. Each copy refreshes at a different time. Each copy applies slightly different rules. Finance might exclude cancelled orders, but sales includes them until the refund lands. Support uses a customer ID that doesn't match the sales table. Nobody means to create this confusion, it just grows through ordinary work. One team needs a report fast so it exports data. Another team needs a new model so it builds a separate pipeline. Six months later, a meeting turns into an argument about why two dashboards show two different revenue totals. The real cost isn't storage. It's the work around storage. People spend time moving data, checking refresh times, fixing broken handoffs, and explaining why a report changed data. Engineers work on copies, analysts wait for extracts, and business users lose trust because they can't trace a number back to its source or the rules that shaped it. A data lake solves the flexibility problem, and a warehouse solves the reporting problem. Both solve real needs, so if each serves a real purpose, why are we still forcing our data to choose sides? What a fabric lakehouse actually is. Most people think a lakehouse is just another storage bucket, but the real value is how it bridges the gap between raw chaos and structured answers. A fabric lakehouse gives you one working home where files can arrive in their original form, then become tables people can query and use in reports. You don't need to force every document, log or export into a database table on day one. And you also don't need to move clean data into a separate reporting system just to use SQL. Look inside the lakehouse and you'll see two simple areas files and tables. The files area handles data that arrives as files. Maybe a supplier sends a CSV every Friday. Maybe your operation system produces Json logs. Maybe somebody needs to retain a monthly Excel export exactly as it arrived. You can keep that material in files while your team decides how to use it. And while you preserve the original input for checks, later tables are where prepared data becomes easier to work with. A table gives the data a known structure with columns, types, and rows that tools can understand. That means an analyst can query orders customers, or product data without opening raw files first and working out what each field means. Think about a small sales team that receives daily order exports from an online store on Monday. The file contains order IDs, product codes, amounts, and dates. Tuesday's file arrives with a blank amount in a few rows. On Wednesday, a product code changes because the store team renamed it. Those files can land in the lake house first without someone pretending they are clean when they aren't. Then the data team turns that incoming data into a usable orders table. They can check dates, remove duplicates, deal with missing values, and apply the same product naming rules every time the raw files still exist. The prepared table exists to both belong to the same lake house, so the path from source to report doesn't jump between disconnected storage locations. That distinction matters more than you'd think. A lake house isn't a magic data cleaning button. If a source system sends bad customer IDs, the lake house won't somehow know which customer each row belongs to. If finance and sales use different definitions of revenue, they still need to agree on the rule. What the lake house gives them is a shared place to do that work. Keep the original input and publish a table that follows the agreed rule. Here's the head fake. You might think a lake house only matters to data engineers because it can hold raw data, but it also gives analysts a familiar table based view of the data. Once it is ready, that shared view changes the handoff. Instead of an engineer exporting a fresh file. Every time an analyst needs something, the engineer prepares the table in the lake house and the analyst works from that same prepared data. It also means the work can happen in stages without turning into a chain of private copies. One person can bring in data, another can clean it. A third person can use the prepared table for analysis. Each person may use a different fabric experience, but they are working around the same storage concept. This is why the lake house sits near the center of fabric for beginners. It helps you see the whole route. Data comes in, you inspect it, you shape it into tables. People query those tables, then reports use the results. You don't have to learn every tool at once to understand that flow. And you don't have to choose between flexibility and structure before the data even arrives. A lake house lets you keep flexible files where they belong while building structured tables where they help people answer questions. That sounds simple, but the storage layer underneath is why fabric can avoid so much copying one lake and delta tables. The shared foundation, the lake house gives you the experience. But here's where the real magic happens. One lake does the storage work underneath it, Microsoft describes one leg as one drive for data, and that comparison helps if you're new to fabric. Instead of every team building a separate analytics storage space and hoping they stay connected, fabric gives the organization one shared data lake. There is one one lake for each fabric tenant inside it. Workspaces keep work separated by team, project or business area, and each workspace can have its own access rules. So finance doesn't need the same permissions as sales, and a development team doesn't need access to production data just because everything sits under the same larger storage foundation. Your Lakehouse lives in a workspace while its data lives in one lake. That split can sound technical, but it gives you a useful mental model. A workspace controls who can work with the fabric items. One lake holds the data those items use. When you create a lake house in a workspace, you're creating a managed place for data that fits into the tenant wide storage system. This removes a common problem. Teams often create a new storage area for every project because it feels faster at the time. Then the project grows. Another team needs the same customer data. A report needs the same sales data. Soon each group owns a separate copy and nobody can tell which version should win. When numbers disagree, one leg doesn't remove the need for boundaries. It gives you a shared foundation with boundaries built around workspaces, permissions and governance. You still decide who can read, change, or share data. You still need an owner for each table. The storage location can't settle a business argument about what revenue means. Now, inside that one leg foundation fabric Lakehouse tables use Delta Lake format. Don't let the name put you off. A delta table is a table stored as files, usually based on the parquet format, with extra information that lets fabric treat those files like a reliable table. Parquet organizes data by column, which works well when a query only needs a few columns from a large data set. Rather than reading every piece of every row, the engine can focus on the columns the question needs. Delta adds table behavior. On top of that file storage. It tracks changes through transaction information and keeps metadata about the table. In plain terms, that helps the platform manage a table as a table. Even though the data sits in files underneath, your users can work with rows and columns while the platform manages the storage details. Why should you care? Because one data format can support more than one kind of work. A data engineer can prepare a delta table through spark or a notebook, and analysts can query that same table through fabric's SQL tools. Power BI can read the same underlying data for reports in older designs. Those steps often triggered a copy from one system to another. Someone moved data for engineering, then another process moved it for reporting, and another created an extract for a dashboard with a lakehouse. Fabric engines can work from the same delta data in one lake. That doesn't mean every workload behaves exactly the same, or that you can ignore how queries perform. It means the default design points toward shared data instead of automatic duplication. That's a big change in how you plan a data project. You can also use shortcuts when the data already exists somewhere else. A shortcut lets fabric reference data without creating another physical copy in your lakehouse. Think of it as a pointer to data you need to use, rather than a delivery truck that unloads a second version into your storage. For example, a central team might publish a governed product table. Your workspace can use a shortcut to reference that table rather than running a daily copy job just to get product names and categories. If the shared table updates, your work can use the current version subject to the permissions and sharing rules in place. Shortcuts help with a problem that looks harmless at first. Copying data feels safe because you control your own copy. But every copy creates another refresh job, another permission decision, another chance for the copies to drift apart. A shortcut can cut that overhead when a shared data product already meets your needs. Still, a shortcut isn't permission to treat shared data casually. Someone must own the source. Teams need to know what the table means when it refreshes, and whether its access rules fit the people using it. Governance sounds like a heavy word, but it comes down to clear answers who owns this data, who can use it, and which version should people trust? Storage solves only part of the problem, because most teams still need to ask questions in signals. From raw files to trusted tables, the medallion flow. Imagine your team spends weeks building a report, only to discover halfway through that the underlying data can't be trusted. That's the pain the medallion flow exists to solve. You might think it's about naming layers bronze, silver and gold, but here's the head fake. The names don't matter. The traceability does. Bronze is where source data first lands, with almost no changes. If an online store sends daily order exports, they land exactly as received. Duplicate rows, weird date formats, all of it stays. Why would you preserve garbage? Because when something looks wrong three weeks later, say a revenue number doesn't match the source, you can go back to the exact file the store sent you. Avoid guessing whether a pipeline changed something. Maybe the store accidentally sent the same order twice. Maybe a price showed up as text instead of a number. Bronze gives your team a starting point you can actually check. Here's where it gets interesting. Silver. This is the layer where data becomes consistent enough for wider use. Your team validates data types, removes, duplicates, fills or flags, missing values, and standardizes columns. An order date becomes a real date. Amounts become numeric values. Product codes follow one agreed format. Customer names get matching rules if different systems spell or format them differently, Consider the daily sales export again on Monday. It contains an order for one hundred and twenty five pounds, and on Tuesday the same order appears again. Because the source system resent a batch without a rule, your report would count that sale twice. In silver, you define how to identify the order, keep the correct record and document the logic so everyone can see it. You're not just cleaning data for the sake of cleanliness. You're building a data set that behaves predictably every time someone touches it. Gold comes after that, and this is where the business value lives. Gold tables focus on business questions. They shape prepared data into forms that reports semantic models and analysts can use without rebuilding the same joins and rules repeatedly. A gold table might show sales by region and month. Another might combine orders with product categories and customer segments. The source data contains many fields that matter for operations, but don't help a sales manager answer a weekly question. Gold turns the prepared data into a clear business view. Walk through one sales journey from start to finish. A store export lands with order ID, date, product code, store ID, quantity and amount that lands in bronze. Silver checks the types, removes repeated order records, and standardizes product codes. Gold then combines those clean orders with approved product and store information, producing a table that can answer which regions grew this month and which products drove the change. Each layer has a job bronze preserves silver. Prepares gold, helps people act. You don't need all three layers for every small project. A simple data set may only need a light clean up before reporting, but the medallion pattern gives growing teams a way to avoid mixing raw source data with business ready data in the same table, when someone asks where a gold number came from, the path doesn't depend on one person's memory. Fabric gives you several ways to run that path. A data pipeline can copy data from a source and schedule the process data flows. Gen two can bring data in and apply local transformations. Notebooks and spark job definitions give data engineers a code first route for larger work. You can also upload files directly while learning or testing an idea. The tool changes. The flow stays clear. pipelines matter when the job repeats. Nobody wants to download a new file every morning, rename it, move it into a folder, run a cleanup script, and hope they didn't skip a step. A pipeline lets you define those actions once, run them on a schedule or trigger and track whether the process completed that repeatability protects trust. If a report changes, you can look back through the process. Which source file arrived, which checks ran? Which table fed the business view? People still need to agree on the meaning of sales or active customer, but once they do, the lakehouse gives them a process that applies those rules the same way each time. SQL analytics endpoint and power BI using the data. Once a table reaches gold fabric gives people who don't write code a familiar way to explore it. Every fabric lakehouse includes a built in SQL analytics endpoint, the SQL facing view of your lakehouse tables, where analysts can ask questions using the language they already know. That matters. Because SQL still sits behind a huge amount of reporting work, an analyst might want to filter orders by region, join sales to products, or compare this month with last month. They don't need to open a notebook or touch the raw input. They connect to the SQL analytics endpoint and query the prepared tables directly. A simple query might ask for total sales by country. Another might find customers who haven't placed an order in ninety days. The question can be simple or complex, but the path stays familiar. Choose the table, write the SQL, inspect the result, then use it in a report. Here's a boundary worth knowing early. The SQL analytics endpoint is for reading and querying lakehouse tables. It isn't where you normally insert, update, or delete Lakehouse data. Those changes happen through the engineering path a notebook, spark process, pipeline, or data flow. That separation protects the process you built earlier. Imagine an analyst finds one order that looks wrong in a report. It might feel tempting to open SQL and change that row directly, but then the next scheduled load would overwrite the edit and nobody would know why the report changed. Instead, you fix the source or the transformation rule, then let the prepared table refresh in a traceable way that gives each role a clearer job. The data engineer builds and maintains the path that produces trusted tables. The analyst uses SQL to inspect those tables and answer questions. The business user sees the result in a report without needing to know how the data moved through fabric. Power BI sits naturally at the end of that path. When you connect power BI to Lakehouse data, you can build visuals from tables that already went through the preparation work. You're not asking every report author to clean product codes, remove duplicate orders, or invent a revenue definition from scratch. The business rules live in the prepared data and the semantic model that sits between the data and the report. A semantic model gives reporting data its business shape. It defines relationships between tables, measures like total sales, and names that make sense to the people reading reports. Fabric can create an automatically generated semantic model for a lakehouse, which gives you a starting point for power BI reporting. That doesn't mean you should accept every auto generated model without checking it. You still need to confirm relationships, hide technical fields, and make sure measures match how the business talks about the numbers. But it removes a lot of setup when you're learning, and it keeps power bi close to the tables in the lakehouse. Fabric also supports Direct Lake for power BI over one lake. In practical terms, power BI can query lakehouse tables directly without importing a separate copy into the report model or waiting for a dedicated semantic model refresh. The goal isn't to memorize every connection mode right now, it's to understand the direction reports. Use the same data foundation rather than another extract someone must maintain. Picture the full hand of a data engineer prepares clean sales and customer tables. An analyst opens the SQL analytics endpoint, checks a sudden drop in sales, and builds a measure. Comparing this week with the previous week, a sales leader opens the power BI report and sees the result from the same prepared data. No emailed CSV, no hidden spreadsheet formula, no separate copy. Quietly refreshing on a different schedule. Does that end every disagreement? No. People can still define active customer differently, and a polished dashboard can still answer the wrong question. But when the data path is shared, the conversation changes. Instead of asking which spreadsheet is current. Teams inspect the same table, the same model, and the same rule. The real tension here is that a lakehouse looks like storage at first in fabric, it becomes the common data home that connects engineering work, SQL analysis, and power BI reporting without treating each step as a separate data project. Why beginners should start with the lakehouse. Here's the problem most people face when they first open fabric. You see data factory, data engineering, data science, real time intelligence, and power BI. And you freeze the mental load hits before you've done anything useful. The real tension here is that you assume you have to pick an identity before you can start. AM I an engineer? AM I an analyst? But the truth is, you don't need to choose anything yet. You need a shared starting point. That starting point is the lakehouse. And it works because the mental model stays simple. Data comes in. You keep the original, you build cleaner tables out of it, and people use those tables to answer questions. That's a path you can hold in your head without a single line of spark code or a power BI modeling rule. You start with things you already recognize, folders for files, tables for prepared work, SQL for querying, refreshes for repeatable processes, and reports for the people who need answers. Now, here's where it gets interesting. You might think you need to master the platform's many roles first, but the lakehouse gives them a shared destination. A practical first project can stay tiny. Pick one data set. You understand a sales export, a service desk report a list of project tasks. Create a lakehouse in a workspace. Load that data, look at where the file lands and turn a cleaned version into a table. Open the SQL analytics endpoint. Run a basic query that checks rows, dates, and totals, then build one power BI report off that table. Don't try to build the Executive dashboard on day one. Instead, ask one real question which region produced the most sales? Which request type takes the longest? Which projects slipped past their planned date? A small question gives you a finish line, and finishing one full path teaches more than watching ten separate demos. You'll also start to see where the work changes depending on your role. If you love shaping and moving data, you'll gravitate towards pipelines, data flows, or notebooks. If you live in business questions, SQL and power BI become your main tools, but you're no longer learning isolated products. You're learning how each tool touches the same core data work. Does a lake house cover every scenario? No fabric also has warehouses and other item types for specific workloads. Some teams need a warehouse first design because their work centers on relational SQL patterns. Others need real time tools. But start with the lake house anyway because it teaches the storage story underneath everything. Once you understand how files become trusted tables and how those tables feed analysis, every other choice becomes easier to judge. Copies feel safe at first. Every team keeps its own version. That safety disappears when five reports show five different answers to the same question. Conclusion one place, one shared story. A fabric lakehouse connects raw data and report ready tables on a single path. Teams spend less time chasing copies and more time agreeing on the number. That's the whole point. One shared story instead of five competing versions of the truth, hit subscribe to M365 FM for practical fabric lessons that connect the tools to how people actually work. Then watch the next video and build your first Lakehouse from raw file all the way through to a power BI report.