Alvin Hans
Case Study // Case Study 01

Retail Price Intelligence Pipeline

A traceable retail price pipeline that turns heterogeneous product pages into validated, analytics-ready price history.

Retailers4
DAG Branches8
Quality Checks49 + 12

The Data Problem

The Operating Context

"Price intelligence depends on comparable historical observations, not a single scrape. This project makes the collection-to-mart path inspectable so analysts can trust where price records came from, how they were transformed, and which run produced them."

Comparable retail prices are distributed across heterogeneous product pages, where source-specific extraction, incomplete attributes, and changing page structures can quietly corrupt downstream analysis. The workflow needed to preserve what was collected, reject invalid records, and publish repeatable price history rather than one-off snapshots.

  • The Reliability Trade-offs: Each workflow balanced data preparation effort, downstream usefulness, and measurable reliability under practical constraints.
  • Constraint 01: Source variation: Four retailers expose product data through different page structures, so extraction and normalization must remain source-aware while producing one comparable schema.
  • Constraint 02: Evidence and recovery: Raw payloads and manifests must be retained before transformation so failed parsing, source changes, and rejected records can be investigated without re-collecting blindly.
Pipeline Blueprints

The Data Flow

How the retail price pipeline works end to end

Step 01
Sources4 retailers
Comparable product pages
Step 02
IngestPython adapters
Scrape and parse
Step 03
BronzeMinIO
Raw evidence and manifests
Step 04
ValidatePydantic
Schema and price checks
Step 05
WarehousePostgreSQL + dbt
Landing to Gold marts
Step 06
AnalyticsMetabase
Price intelligence outputs
RejectedInvalid records remain inspectable

How the pipeline is orchestrated in Airflow

Airflow DAGerpm_daily_pipeline
4 retailers2 categories8 branches
Per branch
ingestbuild_silverload_landing
dbt build
dim_productsfct_pricesMetabase

How data quality is enforced across the pipeline

Step 01
FetchPython
Collect source payloads
Step 02
BronzeMinIO
Keep raw HTML and manifests
Step 03
ReplayPython
Rebuild from preserved evidence
Step 04
ValidatePydantic
Apply schema and price checks
Step 05
SilverParquet
Write typed accepted records
Step 06
LandingPostgreSQL
Load validated observations
Evidence is retained before Silver is rebuilt
Architecture Map: A staged workflow that moves data from source preparation to usable downstream outputs.

Pipeline Rationale

Data Flow

Built an Airflow-orchestrated daily batch pipeline with eight independent retailer-category branches. Each branch extracts source data, stores raw evidence and manifests in MinIO Bronze, validates and writes typed Parquet into Silver, loads run-scoped records into PostgreSQL, then fans into dbt staging and Gold marts.

Downstream Outcome

A production-shaped local data platform where reruns remain traceable through run IDs, retries are explicit, rejected records stay inspectable, and price observations accumulate without overwriting history.

Orchestration

Airflow schedules a daily DAG with eight independent source-category branches across four retailers and two product categories.

Bronze evidence

Retailer adapters collect raw product evidence and manifests into MinIO so each ingestion run remains traceable before transformation.

Pipeline Evidence

Validation Results

Evidence 01

Orchestration evidence: One Airflow DAG coordinates 8 independent source-category branches, then waits for each landing load before the dbt build fan-in.

Evidence 02

Quality evidence: The repository includes 49 pytest checks and 12 dbt tests across extraction, parsing, loading, and warehouse modeling.

Evidence 03

Reliability evidence: Run IDs, retries, rejected-record handling, and idempotent source-category loads make failures and reruns inspectable rather than silent.

Pipeline Delivery & Reflections

Evidence before transformation: Retaining Bronze payloads and manifests makes a source change diagnosable and gives downstream tables a traceable origin.

Data contracts matter: Typed validation and a rejected-record path keep malformed retailer data from leaking into warehouse models just because a scrape completed.

Idempotency is a delivery feature: Run-scoped loads and append-only price observations let the pipeline be rerun without erasing or duplicating the history analysts need.

Project Repository & Pipeline Notes