A Microsoft Fabric lakehouse is more than a place to put Parquet files. It is an analytical architecture that lets engineering, SQL analytics, and business intelligence work against a shared data foundation in OneLake. The important design question is not whether a team can create a lakehouse item; it is how storage, compute engines, data contracts, security, semantic models, and operational ownership fit together so that the same data can support several workloads without becoming an uncontrolled shared folder.<\/p>\n
The current DP-600<\/a> role centers on preparing data, securing and maintaining analytics assets, and implementing semantic models. The adjacent DP-700<\/a> role goes deeper into ingestion, transformation, monitoring, and data-engineering operations. Lakehouse architecture sits between those responsibilities: engineering choices determine what analysts and semantic models can safely reuse, while analytical requirements influence how data should be modeled and served.<\/p>\n A good Fabric lakehouse design therefore starts with responsibilities rather than product menus. Decide what data is authoritative, what level of quality each dataset promises, who may access it, which engine should transform it, and how downstream consumers will discover and trust it.<\/p>\n OneLake is the tenant-wide logical data lake behind Fabric. A lakehouse stores its files and tables there, which allows Fabric workloads to work from a common storage plane rather than moving copies between isolated services for every analytical step. That shared foundation is useful, but it does not mean every workspace or team should treat all tenant data as one undifferentiated pool.<\/p>\n Architecture still needs boundaries. Workspaces, domains, lakehouses, warehouses, shortcuts, and security roles define responsibility around data that physically lives in the same broader platform. A finance team may publish governed datasets for enterprise use while retaining a tightly controlled raw zone. A product team may own operational events while exposing a curated customer-behavior table. Shared storage reduces unnecessary duplication; ownership and contracts prevent shared storage from becoming shared confusion.<\/p>\n Think of OneLake as the substrate and the lakehouse as one managed analytical product on top of it. The substrate makes reuse easier, while the item, workspace, and domain choices make reuse understandable.<\/p>\n A Fabric lakehouse exposes Files and Tables. Files can hold raw or semi-structured objects such as JSON, CSV, images, model artifacts, exports, or source-aligned Parquet. Tables represent structured analytical data, normally using Delta Lake. Treating those areas intentionally makes downstream behavior far more predictable.<\/p>\n Source-aligned files are useful when the organization needs replay, audit evidence, or processing that should preserve the source payload. Tables are better once the data has a defined schema, business grain, quality expectation, and query contract. A table called SalesOrderLine<\/em> should mean more than \u201cthe latest output of some notebook.\u201d Its owner should know what one row represents, which keys are stable, what late updates look like, and what consumers may rely on.<\/p>\n Do not convert every arriving file immediately into a business-ready table just because Fabric makes loading easy. Separate ingestion from conformance. That distinction is part of the broader discipline described in data engineering<\/a>: reliable systems preserve source evidence, apply explicit transformations, and publish datasets with known semantics.<\/p>\n Delta Lake gives Fabric lakehouse tables an open, transaction-aware format built on Parquet plus a transaction log. That matters because analytical tables need more than files that happen to share a folder. They need controlled updates, schema behavior, reliable reads during writes, and metadata that multiple engines can understand.<\/p>\n Architecture decisions still sit above the format. A Delta table can be technically valid and still be a poor data product if its grain changes unexpectedly, keys are unstable, or columns are overloaded with inconsistent meanings. Define update semantics explicitly: append-only event data, merge-based current-state data, slowly changing dimensions, snapshot facts, and correction workflows each require different treatment.<\/p>\n Physical layout matters as data grows. Excessive small files, poor partition choices, repeated full rewrites, or uncontrolled schema drift can increase compute and query costs. Delta provides capabilities for dependable table operations, but it does not remove the need for workload-aware engineering.<\/p>\n One of the lakehouse model’s strongest advantages is that different users can work with the same underlying data through different interfaces. Data engineers can use Spark notebooks for distributed transformations, complex file processing, and Python-based workflows. SQL-oriented analysts can query lakehouse tables through the automatically generated SQL analytics endpoint.<\/p>\n This is not an argument to choose an engine based on personal preference. Choose by workload. Spark is well suited to large-scale transformations, semi-structured processing, feature engineering, and code-centric pipelines. T-SQL is often the better interface for relational exploration, joins, validation queries, and analysts whose downstream work is SQL-first.<\/p>\n Keep business logic from diverging across engines. If a customer-status rule is implemented one way in a notebook and another way in SQL, the shared storage layer has not solved the semantic problem. Put reusable logic into governed transformation steps and published tables, then let engines query the resulting contract.<\/p>\n Fabric supports both lakehouse and warehouse patterns, and mature architectures often use both. A lakehouse is attractive when open Delta storage, Spark, mixed file types, and engineering flexibility matter. A warehouse is attractive when teams need a strongly relational SQL experience, warehouse-oriented modeling, and T-SQL development patterns.<\/p>\n The choice is not ideological. Some domains can remain entirely lakehouse-based. Others may prepare and conform data in lakehouses, then publish a warehouse for a highly relational serving layer. In still other cases, a warehouse may be the primary curated store while OneLake provides integration with the rest of Fabric.<\/p>\n Avoid copying data solely to preserve old architectural habits. Fabric’s value is partly that workloads can interoperate on a common storage foundation. Introduce an additional serving layer when it creates a clearer contract, stronger performance, or better developer experience\u2014not simply because traditional architectures always had one.<\/p>\n Bronze, silver, and gold are useful lakehouse responsibilities when they express real differences in trust. Bronze preserves source-aligned evidence. Silver applies reusable quality and conformance rules. Gold publishes business-ready products such as facts, dimensions, or curated analytical tables. The pattern is valuable because it explains what consumers may assume at each boundary.<\/p>\n A bronze table may legitimately contain malformed or duplicate source values if preserving source truth is part of its job. A silver customer entity should not. A gold sales fact should have an explicit grain and business definition suitable for semantic consumption. When those distinctions are measurable, operators can tell whether a problem originated in ingestion, quality processing, or publication.<\/p>\n Do not force every domain into exactly three physical lakehouses. A small domain may use schemas or table conventions inside one workspace. A regulated domain may need separate workspaces with stronger access boundaries. What matters is the progression from evidence to reusable trust to consumer-ready meaning.<\/p>\n OneLake shortcuts let Fabric expose data stored elsewhere through a logical reference rather than a new full copy. That can reduce duplicated storage and make domain-owned data reusable across workspaces. A shortcut is most valuable when the source is already a trustworthy product with clear ownership and availability expectations.<\/p>\n Do not use shortcuts to hide unstable dependencies. If a downstream finance model depends on a shortcut to an operational dataset, the producing team still needs a contract for schema, freshness, and change communication. Logical reuse does not eliminate organizational coupling; it makes that coupling more visible.<\/p>\n Security also deserves attention. Consumers should not gain broader access simply because a dataset is easier to reference. Evaluate the access path, workspace roles, item permissions, and data-level controls so the shortcut preserves the intended governance model.<\/p>\n Many Fabric lakehouses ultimately support Power BI semantic models. That downstream use should influence table grain, dimensional structure, keys, and physical performance. A lakehouse full of application-shaped tables may be technically queryable but still force every analyst to rebuild the same star schema.<\/p>\n Curated facts and dimensions create a stronger serving contract. The existing discussion of semantic-model design<\/a> becomes especially relevant when Direct Lake is used, because the model can consume OneLake-resident data without a traditional import copy. Upstream table design then has a direct influence on report behavior.<\/p>\nStart with OneLake as the shared storage foundation<\/h3>\n
Use the Files and Tables areas for different data responsibilities<\/h3>\n
Make Delta tables the contract between engineering and analytics<\/h3>\n
Let Spark and SQL serve different strengths against the same data<\/h3>\n
Separate lakehouse responsibilities from warehouse responsibilities<\/h3>\n
Use medallion boundaries to express data quality, not just folder names<\/h3>\n
Use shortcuts to reuse governed data without unnecessary copies<\/h3>\n
Design the lakehouse for semantic models and Direct Lake consumption<\/h3>\n