The Four-Layer Architecture of Data Warehouses

In modern data-driven enterprises, building an efficient, stable, and scalable data warehouse lies at the heart of data

In modern data-driven enterprises, building an efficient, stable, and scalable data warehouse lies at the heart of data governance. To manage data in an orderly fashion, transform it reliably, and make it reusable across the organization, the industry commonly adopts a four-layer architecture. This layered design not only clarifies complex data flows but also significantly reduces maintenance costs and improves overall data quality.

This article examines the four layers of a data warehouse from bottom to top: the Operational Data Store (ODS), the Data Warehouse Detail (DWD), the Data Warehouse Summary (DWS), and the Application Data Store (ADS).

Layer 1: Operational Data Store (ODS)

The first layer, often called the source layer or landing layer, is responsible for receiving, backing up, and storing raw data from various business systems—such as MySQL, Oracle, event logs, and third-party APIs—as-is.

Key characteristics include:

  • Source-aligned structure: Data structures remain largely consistent with the source systems, with minimal business logic or cleansing applied at this stage.
  • Historical retention: A certain period of historical data is typically preserved based on business requirements, serving as the foundation for downstream processing.
  • Low intrusion: Construction of this layer should minimize impact on production business systems.

Common operations involve full or incremental synchronization, using tools such as Sqoop, DataX, or Flink to move data from operational databases into the warehouse, often landing in Hive or a similar storage engine.

Layer 2: Data Warehouse Detail (DWD)

Sitting above ODS, the detail layer cleanses, normalizes, and integrates the raw data. This is one of the most time-consuming and critical stages of warehouse construction.

Its core characteristics are:

  • Unified dimensions: Different business systems are aligned under a common dimensional model, standardizing time formats, currency units, user IDs, and other attributes.
  • Data cleansing: Invalid, dirty, or null records are filtered out—for example, removing test accounts or handling anomalous login IP addresses.
  • Fine granularity: Data is usually kept at the finest business grain, such as individual order transactions or single page-view events.

Modeling typically follows dimensional design principles, producing detailed fact tables and dimension tables arranged in star or snowflake schemas.

Layer 3: Data Warehouse Summary (DWS)

While detail data is complete, querying it directly for front-end reports or algorithmic analysis often leads to poor performance. The summary layer addresses this by aggregating DWD data at light or heavy levels.

Core characteristics include:

  • Metric aggregation: Centered around statistical subjects such as users, products, or merchants, this layer builds shared summary metrics—for example, a user’s total order amount over the past seven days or a product’s sales volume over the last 30 days.
  • Reduced redundant computation: Frequently queried metrics are pre-computed and stored, avoiding repeated scans of massive detail tables.
  • Reusability: It provides a common data foundation for upper-layer applications, preventing inconsistent metric definitions across the organization.

For instance, DWD might store that user A purchased $100 worth of goods on October 1, 2023 at 10:00:00. DWS, by contrast, might store a daily consumption summary table with fields such as user_id, date, one-day order count, and one-day order amount.

Layer 4: Application Data Store (ADS)

The application layer is the topmost tier of the warehouse, serving business applications, data products, BI reports, and machine learning algorithms directly. Data here is highly customized for specific business scenarios.

Its defining features are:

  • Scenario-oriented design: It directly supports executive dashboards, user profiles, recommendation systems, financial reports, and other end-user scenarios.
  • Ready for immediate use: After multiple layers of processing, ADS data is typically simple in structure and optimized for fast querying, often being synchronized to ClickHouse, Redis, or relational databases.
  • Metric consistency: It ensures that core metrics such as GMV, daily active users (DAU), and retention rates are calculated with a single, company-wide definition.

Common outputs include final report datasets, risk-control rule bases, and marketing tag tables.

Benefits and Practical Considerations

The ODS → DWD → DWS → ADS flow delivers several major advantages:

  • Decoupling and reuse: Changes in underlying data do not directly affect upper-layer applications, and public metrics computed once in DWS can be reused by multiple ADS applications.
  • Reduced complexity: Complex calculations are broken into manageable steps, making it easier to troubleshoot data issues by tracing lineage from ADS back to ODS.
  • Data quality assurance: Each layer has clear responsibility boundaries, facilitating data lineage analysis and quality monitoring.

In practice, the architecture is not rigid. Startups or small projects may merge DWD and DWS for simplicity, while large enterprises often rely on the strict four-layer model to standardize and industrialize their data assets.