Data warehouse architecture describes how data moves from source systems to the reports and dashboards that consume it, and what shape it takes at each step. Most warehouses are built in layers: a source layer of operational systems you don't control, a staging layer where raw extracts land untouched, an ODS or integration layer where data is cleaned and conformed, and a presentation layer of data marts that analysts query. Each layer has one job, and keeping them separate is what lets you reload, debug, and reshape the warehouse without breaking everything downstream.

The layers

Source systems - order entry, CRM, billing, event streams - are the systems of record. The warehouse never modifies them; it copies from them. The staging area is the landing zone where those copies arrive as faithful extracts, so transformation can fail and rerun without touching the source again. From staging, data is integrated: deduplicated, type-cast, conformed to shared keys and definitions. An operational data store (ODS) can sit here when the business needs current-valued, integrated data for operational reporting before it's rolled into the historical warehouse.

Where the data lands for analysts

The presentation layer is what users see - usually dimensional star schemas organized by subject area. This is where the enterprise data warehouse versus data marts question gets settled: one centralized normalized store feeding marts, or marts assembled directly from conformed dimensions. The hub-and-spoke architecture is the canonical answer to "how do the layers connect" - a normalized EDW hub feeding dimensional marts as spokes, the design Bill Inmon prescribes in the Inmon method, set against Ralph Kimball's bus architecture of conformed dimensions.

Modeling across the layers

The same data wears different clothes at different layers, and that is the point of separating a logical model from a physical one. The logical model says what entities exist and how they relate - normalized in the integration layer, dimensional in presentation. The physical model decides how those entities are stored: data types, indexes, partitioning, distribution keys, the choices that make a query fast on a specific engine.

Why layers

The layered design buys you isolation. When a source schema changes, you fix staging and the extract, not the marts. When a mart's grain is wrong, you rebuild it from the integration layer instead of re-pulling source data. When you need a new subject area, you add a spoke without disturbing existing ones. The cost is more storage and more moving parts; the return is a warehouse you can reason about one layer at a time.