🏛️ Category 06 • Storage Engines, Warehousing & Lakehouse

Data Platforms: Warehouses, Delta Lake & Snowflake

Architecting the single source of truth for analytics. Master Kimball dimensional modeling (Star & Snowflake schemas), Slowly Changing Dimensions (SCD Type 2), Delta Lake ACID transactions & time travel, Snowflake micro-partitions, and PostgreSQL query indexing.

1. Data Platforms Overview: OLTP vs OLAP & The Lakehouse

Core Storage Concepts

Historically, data architectures maintained a strict divide between transactional OLTP databases and analytical OLAP warehouses. Today, the modern Data Lakehouse combines the cost-effective scalability of open cloud object storage (S3/ADLS) with the ACID transaction guarantees, schema enforcement, and sub-second BI performance of traditional warehouses.

OLTP (Row-Oriented)

Optimized for high-concurrency read/write of single records (e.g. user authentication, order checkout). PostgreSQL, MySQL.

OLAP (Column-Oriented)

Optimized for aggregate queries scanning millions of rows across a few columns (e.g. total monthly revenue by region). Snowflake, Redshift.

Open Table Formats

Delta Lake, Apache Iceberg, and Apache Hudi providing ACID transactions, snapshot isolation, and metadata pruning over Parquet.

Decoupled Storage & Compute

Query engines (Snowflake virtual warehouses, Trino, Databricks SQL) spin up and down independently of persistent underlying storage.

Topic 6.1

Kimball Dimensional Modeling: Star vs Snowflake Schemas

Data Modeling

Ralph Kimball's dimensional modeling technique remains the gold standard for intuitive, high-performance analytical schema design.

Fact Tables

Contain numerical measurements of business events (e.g. trade_price, shares_traded, fee_amount). Additive, semi-additive (balances), and non-additive (ratios).

Dimension Tables

Contain descriptive textual context answering "who, what, where, when, why" (e.g. dim_customer, dim_security, dim_date).

Star Schema vs Snowflake Schema

Star schema denormalizes dimensions into single flat tables (fewer joins, faster BI). Snowflake schema normalizes dimensions into sub-dimensions (less storage, more joins).

Conformed Dimensions

Shared dimensions (e.g. dim_date, dim_customer) linked across multiple separate fact tables (e.g. trades, logins, billing) enabling cross-drill analytics.

Topic 6.2

Slowly Changing Dimensions (SCD Type 0 to Type 6)

Enterprise Standard

Customer attributes, risk tiers, and fund managers change over time. SCD strategies define how to capture historical changes.

SCD Type 0 (Fixed Retain)

Never updated. Original historical value is preserved forever (e.g. Original Account Opening Date).

SCD Type 1 (Overwrite)

Overwrites old value with new value. Zero history preserved. Used for correcting typos (e.g. Fixing customer address typo).

SCD Type 2 (Add New Row • Gold Standard)

Inserts a new row with new surrogate key, start_date, end_date (default 9999-12-31), and is_current boolean flag.

SCD Type 3 / Type 6

Type 3 adds a "previous_value" column. Type 6 is a hybrid (1 + 2 + 3) combining historical rows with a current attribute column on all rows.

📄 scd2_delta_merge_pattern.sql
-- Production Delta Lake / Snowflake MERGE for SCD Type-2
MERGE INTO curated_lake.dim_customer_scd2 AS target
USING (
    -- Staging updates unioned with dummy records to trigger inserts
    SELECT 
        s.customer_id, s.tier, s.address, s.update_timestamp,
        s.customer_id AS merge_key
    FROM staging_customer_updates s
    UNION ALL
    -- NULL merge_key bypasses MATCHED clause and forces an INSERT
    SELECT 
        s.customer_id, s.tier, s.address, s.update_timestamp,
        NULL AS merge_key
    FROM staging_customer_updates s
    JOIN curated_lake.dim_customer_scd2 t ON s.customer_id = t.customer_id
    WHERE t.is_current = TRUE 
      AND (s.tier <> t.tier OR s.address <> t.address)
) AS source
ON target.customer_id = source.merge_key AND target.is_current = TRUE

-- 1. Expire current record
WHEN MATCHED AND (target.tier <> source.tier OR target.address <> source.address) THEN
    UPDATE SET 
        target.end_date = CAST(source.update_timestamp AS DATE),
        target.is_current = FALSE

-- 2. Insert new current record
WHEN NOT MATCHED THEN
    INSERT (customer_sk, customer_id, tier, address, start_date, end_date, is_current)
    VALUES (
        UUID_NUMERIC(), 
        source.customer_id, 
        source.tier, 
        source.address, 
        CAST(source.update_timestamp AS DATE), 
        '9999-12-31', 
        TRUE
    );
Topic 6.3

Delta Lake Internals: _delta_log, Time Travel & Compaction

Lakehouse Protocol

Delta Lake is an open storage layer that brings ACID transactions to Apache Spark and big data workloads.

The Transaction Log (_delta_log)

Ordered JSON commit files (000000.json) tracking added and removed Parquet files atomically. Checkpointed every 10 commits into Parquet.

Time Travel

Querying historical snapshots using VERSION AS OF 42 or TIMESTAMP AS OF '2026-10-01' for auditability and instant rollback.

Schema Enforcement & Evolution

Prevents accidental corrupted writes. Use .option("mergeSchema", "true") to safely append new columns without table rewrites.

OPTIMIZE, Z-ORDER & Liquid Clustering

Compacts small files into 1GB files and co-locates multidimensional data along space-filling curves for high-speed file skipping.

Topic 6.4

Snowflake: Multi-Cluster Shared Data & Micro-Partitions

Cloud Data Warehouse

Snowflake's multi-cluster shared data architecture separates storage, compute (Virtual Warehouses), and cloud services.

Micro-Partitions

Snowflake automatically divides tables into immutable 50MB–500MB micro-partitions. Stores min/max metadata for automatic query pruning.

Zero-Copy Cloning

Creates instant snapshots of tables, schemas, or entire databases using metadata pointers without copying underlying physical bytes.

Streams & Tasks (Automated CDC)

Streams track row-level change data capture (CDC). Tasks execute on schedules or stream triggers to automatically merge CDC data into downstream tables.

Snowpipe (Continuous Ingestion)

Serverless event-driven ingestion loading micro-batches from S3/Azure Blob within seconds of file arrival via SQS/EventGrid.

Topic 6.5

PostgreSQL for Data Engineers: Partitioning, Indexing & BRIN

Relational Serving

PostgreSQL serves as the operational serving layer for data marts, caching, and transactional APIs.

Declarative Partitioning

Range partitioning (by trade_date), List partitioning (by region), and Hash partitioning to bound query execution scans.

BRIN (Block Range Index)

Stores min/max values for ranges of physical disk blocks. 99% smaller than B-Tree indexes, making it ideal for append-only timestamp series.

GIN & GiST Indexes

Generalized Inverted Indexes for querying JSONB documents and full-text search columns at high speed.

Foreign Data Wrappers (FDW)

Querying external S3 Parquet files or remote MySQL/Oracle databases directly from PostgreSQL using SQL.

2. Lakehouse Dimensional Architecture

Enterprise Blueprint
[Source Transactions • WebSockets • SFTP Batches] ↓ [Bronze S3 Lakehouse] (Raw JSON / Parquet • Append-Only) ↓ [Silver S3 Lakehouse (Delta Lake)] • ACID Merge • Deduplication • SCD Type-2 Dims ↓ [Gold Dimensional Layer (Kimball Star Schema)] • Fact: fact_investment_trades • Dim: dim_security (SCD2) • Fact: fact_daily_nav • Dim: dim_portfolio • Dim: dim_date ↓ ↓ [Snowflake / Redshift Serving] [PostgreSQL High-Speed Relational Mart]
Hands-On Lab

Lab 06: Implement an SCD Type-2 Dimension Pipeline in Delta Lake

Lab Guide
1

Initialize Delta Table

Create dim_security_scd2 in Delta Lake with columns security_sk, ticker, sector, rating, start_date, end_date, is_current.

2

Ingest Incremental Updates

Process a simulated batch of credit rating downgrades and sector reclassifications.

3

Execute Atomic MERGE Statement

Run the SCD-2 merge pattern to expire updated records and insert new current rows atomically in a single ACID transaction.

4

Time-Travel & Integrity Verification

Verify that point-in-time historical queries return correct past ratings using Delta Lake VERSION AS OF 0.

3. Data Platforms & Modeling Interview Questions

Modeling Scenarios
Q1: When would you choose a Star Schema over a 3rd Normal Form (3NF) relational schema? ▲

Answer: 3NF minimizes data redundancy and prevents update anomalies in transactional OLTP systems (e.g. updating a customer's address once). However, querying 3NF for analytical reporting requires joining 15–25 normalized tables, creating CPU bottlenecks and complex SQL.
Star Schema is preferred for OLAP and analytics because it denormalizes descriptive attributes into dimension tables connected directly to central facts. This yields: (1) Far fewer joins; (2) Fast aggregation performance in columnar databases; (3) Intuitively understandable data structures for BI analysts using Power BI or Tableau.

Q2: How does Snowflake's Zero-Copy Cloning work under the hood without doubling storage costs? ▼

Answer: Snowflake separates metadata from immutable micro-partition storage files in S3/Azure Blob. When you run CREATE TABLE clone_table CLONE source_table;, Snowflake does not copy any physical files. It merely copies the metadata pointers referencing the existing micro-partitions in the cloud services layer. This completes in seconds with zero additional storage cost. As new DML (INSERT, UPDATE, DELETE) executes on the cloned table, new micro-partitions are written, and only the modified delta files incur storage fees.

4. Related Tracks

Explore Next

Master Workflow Orchestration & Data Governance

Discover how Apache Airflow, MWAA, CI/CD testing, and Great Expectations orchestrate robust production pipelines.

⚙️ Explore Orchestration Track →
Open Lakehouse & warehouse interview questions →