Home / Projects
DE · 08Live

Modular ETL Pipeline Engineering

A small, testable Python ETL pipeline: Excel workbooks in, governed Parquet and Excel out, with every stage independently unit-tested and a CLI runner that logs each run. No orchestrator, no cloud — a deliberately narrow demonstration of stage isolation, deterministic I/O and fail-loud error handling done right.

Data source50 sample absenteeism workbooks (synthetic, workshop-provided), 500 rows total
ArchitectureExtract (Excel) → Transform (clean, normalize) → Parquet → Load → Excel report, each stage stage-tested
StorageLocal Parquet + Excel files — no database, no cloud target
StackPythonpandasPyArrowpytestPoetry
StatusLive: 4/4 tests green and the full pipeline reproduced end-to-end from a clean clone, evidence committed

Context

Built during Workshop 01 of Jornada de Dados (the same bootcamp series behind AE-05), this project predates the portfolio workspace. It was brought in, renamed to the portfolio's ID convention, and re-verified end-to-end on new hardware rather than just carrying over its original claims.

Business Problem

Organizations often consolidate operational data from spreadsheets and legacy systems by hand — duplicated effort, inconsistent definitions, and no real traceability from source file to published number. This pipeline demonstrates the small, repeatable alternative: ingest every workbook, apply explicit and tested transformations, and publish analysis-ready Parquet and Excel artifacts.

Architecture

Excel workbooks Extract Transform Parquet Load Excel report

Each stage is a pure function over a DataFrame in its own module (extract.py, transform.py, load.py). The CLI runner (app/main.py) only orchestrates and logs — it never processes data itself — running the matching pytest module after every stage, then a final end-to-end integration test, and writing a timestamped log. Workbook discovery and Parquet loading both sort file paths explicitly, so two runs on the same input never silently diverge in row order, and output writers propagate exceptions instead of reporting a false success.

Challenges

Why this isn't DE-01

The portfolio already reserves a slot for an ETL project: DE-01, specifically an API-sourced, cloud-warehouse, Airflow-orchestrated pipeline — and the only track item flagged as the portfolio's biggest orchestration gap. This project has none of that: a local Excel source, no cloud target, no scheduler. Folding it into DE-01 would have papered over the gap instead of closing it, so it became its own entry (DE-08) instead — a scope call worth stating plainly rather than stretching a spec to fit whatever code is on hand.

Proving it, not just running it

A polished README is not evidence. Getting this project portfolio-ready meant a clean clone, a from-scratch environment, and an actual end-to-end run — not a re-statement of the original repo's claims. That run is what produced the row counts below and the committed evidence in docs/evidence/.

Results

From a clean clone: uv venv --python 3.11pip install -r requirements.txtpytestpython -m app.main.

StageResult
Tests4/4 passed (extract, transform, load, full-pipeline integration)
Extract50 workbooks → 500 rows, 7 columns, 0 null rows
Transform500 → 500 rows (nothing to drop), expands to 9 columns (splits the ausence timestamp, formats currency, normalizes numerics)
LoadParquet and Excel outputs both round-trip to the identical (500, 9) shape

Full run log and pytest output committed at docs/evidence/ in the repo — every number above traces back to that artifact, not to a re-typed summary.

Tech Stack

CategoryTool
LanguagePython 3.11
Data handlingpandas, PyArrow (Parquet), openpyxl (Excel)
Testingpytest, 4 modules (unit + integration)
PackagingPoetry (locked), pip fallback via requirements.txt

View the code on GitHub ↗

← Previous
Big Data Engines Benchmark