Data Mart — Data Platform Architecture Pattern

Problem

Exposing an entire enterprise data warehouse directly to business users buries them in irrelevant tables and complex global schemas. Without curation, analysts waste time deciphering structures they don't need, query performance degrades under mixed workloads, and trust in the platform erodes.

Solution

Build Data Marts—domain-specific, highly curated subsets of data modeled specifically for a single business unit (e.g., Sales or Finance) to simplify access and improve performance.

Cloud Paradigm

Domain-Oriented Data Modeling
Dimensional Modeling (star/snowflake schemas)
Curated Data Subsetting
Semantic Abstraction Layer
Physical Data Isolation (schema-scoped access control)
Read-Optimized Analytical Storage

Solution Flow

The Enterprise Data Warehouse (EDW) holds the conformed, integrated single version of truth across all domains, but its breadth makes it unwieldy for a single team.
The ETL/transformation layer selects only the tables, columns, and grain relevant to one business unit, applying domain-specific filters, aggregations, and business rules.
The dimensional modeler shapes the subset into a star or snowflake schema—narrow fact tables surrounded by conformed dimensions—optimized for the questions that department actually asks.
The Data Mart persists this curated slice in its own schema or database, physically or logically isolated so query complexity and blast radius stay small.
The semantic/BI layer maps friendly business names onto the mart, hiding technical keys and join logic.
Business analysts and dashboards query the mart directly, getting fast responses against a schema they can navigate without a data dictionary.

When to Use

A department (Sales, Finance, HR) repeatedly needs a stable, performant subset of enterprise data.
Analysts are overwhelmed by hundreds of EDW tables irrelevant to their function.
Query performance on the full warehouse degrades under departmental reporting load.
You want to enforce domain-scoped access control at the schema level.

When NOT to Use

Cross-domain analytics that require joining many business units—querying the full EDW or a lakehouse is better.
Highly exploratory data science needing raw, un-aggregated granularity.
Tiny datasets where a curated view or saved query already suffices.
Rapidly changing schemas where maintaining separate marts creates heavy ETL overhead.

Trade-offs

Simpler, faster analyst experience vs the cost of building and maintaining additional ETL pipelines.
Isolated performance and security vs potential data duplication and storage overhead.
Domain-tailored modeling vs risk of metric drift if conformed dimensions aren't shared.
Faster time-to-insight vs added latency from an extra hop between EDW and mart.

Real-World Example

A national grocery retailer runs a large EDW consolidating point-of-sale, inventory, supply-chain, and HR data. The Merchandising team only cares about sales, promotions, and stock levels, so the data team builds a Sales Data Mart: a nightly pipeline extracts POS facts and product, store, and time dimensions into a dedicated star schema. Merchandising analysts point Power BI at this mart, get sub-second responses on "units sold by category by region," and never encounter payroll or logistics tables—while conformed date and product dimensions keep their numbers reconcilable with Finance's separate mart.

Additional Details

Conformed dimension governance: Marts stay reconcilable only if date, product, and customer dimensions share surrogate keys and definitions across marts; publish them from a single conformed-dimension pipeline rather than letting each mart build its own, or metrics silently diverge.
Refresh consistency: A mart is a lagged copy—decide between full reload and incremental/CDC loads, and load fact and dimension tables in dependency order so late-arriving dimensions don't orphan facts. Snapshot the load with a batch ID so partial failures can be truncated and replayed idempotently.
Schema evolution: Additive columns are safe, but grain changes or dimension restructures break downstream dashboards; version the mart schema and coordinate BULK re-aggregation with report owners before cutover.
Performance tuning: Cost is driven by rebuild frequency and storage duplication; partition fact tables by date, maintain aggregate/summary tables for common rollups, and refresh statistics or indexes after each load.
Observability: Track load duration, row counts, and freshness lag per table, and reconcile fact totals against the EDW source as a data-quality gate that blocks publish on drift.
Maintenance chores: Schedule vacuum/compaction and index rebuilds on high-churn marts, and prune obsolete columns as departmental questions change to keep the curated surface small.

Security Controls

Schema-level access control: Grant departmental roles permission only to their mart, isolating each business unit's data footprint.
Column and row masking: Apply masking policies in the ETL layer so sensitive fields (e.g., margins, PII) never land in a mart that doesn't need them.
Lineage tracking: Maintain end-to-end lineage from EDW source tables to each mart so audits can trace every derived metric.
Pipeline credential isolation: Run each mart's ETL under a scoped service account with read-only access to the EDW and write access to only its target schema.
Encryption at rest and in transit: Encrypt mart storage and all EDW-to-mart data movement to protect duplicated sensitive data.
Change auditing: Log all schema and access-grant changes to marts to detect unauthorized scope expansion.