PROYECTOS / DATA ENGINEERING
Salvando Patitas Data Platform
Plataforma de datos end-to-end —ingesta, lakehouse Medallion, transformación, orquestación y BI— construida en dos arquitecturas (GCP serverless y Airflow + PySpark), sobre un dataset sintético que diseñé para modelar una fundación de rescate animal.
El resultado — 5 dashboards de dirección
Del lakehouse a la decisión: financiero, fundraising, gastos, donantes (RFM) y proveedores. Lo que ve el equipo directivo de una ONG cada semana, alimentado por el pipeline que verás más abajo.
Qué construyo
Dashboards de dirección
Pipeline + Dataform
Ingesta en Python y transformación SQLX, versionadas y trazables.
Versión Airflow + Spark
El mismo lakehouse en orquestación distribuida, con tuning de Spark.
El problema
Quería dominar el stack de data engineering de punta a punta sin depender de datos de un cliente. Modelé la operación de una ONG —donaciones, gastos, casos, proveedores—, generé un dataset sintético realista y construí sobre él: ingesta incremental, lakehouse Medallion, orquestación y cuatro dashboards de dirección. Y lo hice dos veces, en dos paradigmas, para saber cuándo usar cada uno.
Arquitectura
Lakehouse en Google Cloud.
Bronze: ingesta desde la API a Parquet en GCS, particionado por fecha (incremental para hechos, snapshot para dimensiones).
Silver: limpieza, deduplicación, casteo seguro y cuarentena de registros inválidos.
Gold: esquema estrella —dimensiones, hechos y features para ML (RFM, LTV)—. Calidad con asserts en cada capa, y el DAG hace cada tabla trazable de origen a dashboard.
Un pipeline, dos orquestadores
El lineage completo del lakehouse, orquestado de dos formas: Dataform (serverless) y Airflow (distribuido). La misma lógica —raw → silver → gold → dashboards— en dos paradigmas. Toca cada DAG para ampliarlo.
Resultados medidos — la comparación que decidió la arquitectura
A ~30k registros, Airflow + Spark costó ~11× más (US$11 vs US$1) y tardó ~4× más (11:40 vs 3 min) — el costo oculto de gestionar una VM (disco, storage, compute) frente a un serverless que “despliegas y te olvidas”. Domar Spark fue el ejercicio; elegir la opción simple, la conclusión.
Decisiones y descartes
Las alternativas que consideré, por qué las descarté y a qué costo. Un sistema se entiende tanto por lo que eligió como por lo que dejó fuera.
Qué haría distinto
- Calcular el volumen antes de migrar. Reconstruí todo en Airflow + Spark para aprenderlo; que Dataform ganara (11× más barato, 4× más rápido) pude haberlo anticipado con un cálculo de escala. A ~30k registros, Spark siempre iba a ser overkill.
- Modelar desde las preguntas, no desde las tablas. Empecé replicando el OLTP en el warehouse; el valor real apareció cuando diseñé la capa Gold desde las preguntas de dirección (¿cuánto cuesta un caso?, ¿qué donante retiene?).
- Tests desde el día uno. Las validaciones (asserts) llegaron tarde; en datos, un test que falla temprano vale más que un dashboard bonito.
Otros proyectos
CRM Data Platform
Ingesta incremental, orquestada y con validación en cada carga.
Plataformas analíticas
Modelo dimensional y métricas certificadas que la dirección puede citar.
IA aplicada (RAG)
Recuperación sobre datos propios, con la fuente citada en cada respuesta.
Automatización de procesos
CI/CD y despliegue serverless: menos intervención manual, menos error.

