Warehouse, Data Mart, ODS, Data Lake, Lakehouse, Semantic Layer, and BI Platform: Responsibilities and Boundaries

Learning outcomes

AtlasMart has an ERP database, CRM extracts, inventory snapshots, web-event files, analyst spreadsheets, and dashboards. Calling every destination “the warehouse” hides responsibility: which layer owns raw evidence, integrated historical data, certified metrics, low-latency current state, or user presentation? This lesson separates those boundaries without pretending every organization must deploy every named layer.

1. A warehouse is an analytical responsibility, not merely a large database

A data warehouse is the governed analytical environment that integrates data for historical analysis and repeatable decision support. It should expose stable meaning, traceability, quality controls, and workload isolation appropriate to analytical consumers. The implementation might be a relational MPP engine, a serverless service, a lakehouse query layer, or another architecture.

The word does not guarantee a star schema, a specific vendor, nightly batch, or one physical database. Those are design choices. What makes the responsibility “warehouse-like” is that it turns source evidence into durable, queryable analytical meaning under explicit contracts.

2. Separate the neighboring responsibilities

These are not mutually exclusive boxes. A managed service may host warehouse and semantic responsibilities in one product. A lakehouse can serve as the physical warehouse platform. An ODS can feed a warehouse. The discipline is to keep the contracts distinct even when the infrastructure is shared.

3. Follow one AtlasMart question end to end

Suppose operations asks: “Which paid orders from the last 30 minutes belong to customers currently marked high-priority, and what is the paid merchandise value by region?” The ERP is authoritative for order state; CRM is authoritative for customer priority; neither should become authoritative for the joined analytical answer.

A plausible responsibility chain is:

1. Sources: ERP and CRM commit operational facts.
2. Landing/raw evidence: immutable extracts or change records preserve what ingestion observed.
3. Integration/warehouse: identity, timestamps, quality, and history policies are applied.
4. Mart/presentation: sales-oriented structures make the approved grain and dimensions convenient.
5. Semantic layer: paid_gmv and “high-priority customer” definitions are versioned once.
6. BI: dashboard/exploration renders the answer and its freshness state.

An ODS might be added if a near-current operational process needs integrated current state with lower latency than the historical warehouse path. It is not mandatory just because the acronym exists.

4. Logical boundaries can share hardware

Architecture diagrams often imply one product per box. That can create needless complexity. AtlasMart can preserve clear raw, integration, presentation, semantic, and BI responsibilities while using a single local database in a learning lab or one managed platform in production. Conversely, placing datasets in separate cloud services does not create governance if definitions, lineage, and access controls are unclear.

5. Controlled failure: one “analytics” bucket for everything

A team creates analytics/ and drops ERP CSVs, curated customer tables, dashboard exports, notebooks, and KPI extracts into the same namespace. Analysts cannot tell which file is raw, which is corrected, which formula is certified, or whether a dashboard CSV is an input or an output. Reprocessing can overwrite evidence, and security applied to the dashboard does not protect copied raw PII.

The repair is a contract-first namespace: classify data by responsibility, preserve raw evidence where policy permits, mark certified serving objects, version semantic definitions, and make BI outputs downstream rather than upstream sources unless explicitly governed as such.

6. Hands-on lab — classify the architecture before choosing products

In an empty directory, save this manifest as architecture.json. It is a teaching contract, not a vendor configuration file.

{  "datasets": [    {"name":"erp_orders_raw","responsibility":"raw","owner":"data-platform","freshness":"15m","certified":false},    {"name":"crm_customer_current","responsibility":"integration","owner":"customer-data","freshness":"24h","certified":false},    {"name":"sales_order_line_atomic","responsibility":"warehouse","owner":"analytics-engineering","freshness":"30m","certified":true},    {"name":"sales_mart","responsibility":"mart","owner":"sales-analytics","freshness":"30m","certified":true},    {"name":"paid_gmv","responsibility":"semantic","owner":"finance-data","freshness":"30m","certified":true},    {"name":"executive_sales_dashboard","responsibility":"bi","owner":"bi-team","freshness":"60m","certified":true}  ]}

import jsonfrom pathlib import Pathallowed = {"raw", "ods", "warehouse", "mart", "lake", "lakehouse", "semantic", "bi", "integration"}data = json.loads(Path("architecture.json").read_text(encoding="utf-8"))names = set()for item in data["datasets"]:    assert item["name"] not in names, f"duplicate dataset: {item['name']}"    names.add(item["name"])    assert item["responsibility"] in allowed    assert item["owner"].strip()    assert item["freshness"].strip()print("validated datasets:", len(names))print("certified:", [x["name"] for x in data["datasets"] if x["certified"]])

Run python validate_architecture.py. Expected evidence: validated datasets: 6, followed by the four certified objects. Now deliberately change paid_gmv to responsibility dashboard_formula; the validator must reject the unrecognized responsibility. Restore semantic and rerun.

Verification: every object has one named owner and freshness class; raw data is not certified by default; the semantic metric is distinct from the dashboard; the mart is downstream from the warehouse responsibility. Cleanup: delete only the two files created in this lab directory.

7. Production judgment

Do not ask “warehouse or lakehouse?” before asking what responsibility is missing. AtlasMart may eventually use object storage, an analytical database, open table formats, a semantic model, and a BI service, but each technology should attach to a defined contract. The next lesson compares four architectural styles by where they place integration, transformation, and serving responsibilities.

Knowledge check

Summary and next step

Warehouse, mart, ODS, lake, lakehouse, semantic layer, and BI platform name different responsibilities. Keep those responsibilities explicit even when one platform implements several of them.

Next: Classic Enterprise Warehouse, Dimensional Bus, Modern ELT, and Lakehouse-Centric Architectural Styles.

Authoritative references

• Big Data Academy — course curriculum — Course scope and reserved sequence.
• Kimball Group — Enterprise Data Warehouse Bus Architecture — Technology-independent integration through business processes and conformed dimensions.
• Kimball Group — Enterprise Data Warehouse Bus Matrix — Process/dimension matrix used later to govern incremental delivery.
• dbt Developer Hub — Semantic Layer — One current implementation example of a semantic-layer responsibility; not a course prerequisite.
• Apache Iceberg documentation — Example of an open table-format layer; table format is distinct from semantic modeling and BI serving.