Proyecto de datos
de punta a punta.
Un proyecto para hacer en una semana y contar en una entrevista: traés datos de una API, los limpiás por capas con dbt y los mostrás en un dashboard.
Por Mauro Prystupa · Actualizado el
Qué vas a
construir.
Una tienda online quiere un tablero que responda tres preguntas. Vos traés los datos, los limpiás y armás el tablero. El objetivo no es aprender cada herramienta por separado: es mostrar que entendés cómo conviven dentro de un mismo flujo.
Para quién es: Juniors que buscan su primer trabajo como Data Engineer, Data Analyst o BI, y cualquiera que quiera ver un flujo de datos completo.
En corto
- Es un proyecto de datos completo: API, ingesta en Python, dbt en cuatro capas (raw, stg, int y mart), tests y un dashboard.
- Se hace en una semana, con una guía día por día y tres preguntas de control al final de cada día.
- Corre en tu computadora con DuckDB, sin cuenta en la nube ni Docker. BigQuery es el paso siguiente, con el mismo código.
- Los datos son sintéticos, con los mismos problemas que los reales: encontrarlos y resolverlos es parte del ejercicio.
- Al final tenés un repo propio, un tablero y un story.md para contar el proyecto en una entrevista.
- Pregunta 1
¿Cómo evolucionan las ventas por mes y por canal?
- Pregunta 2
¿Qué categorías y productos dejan más margen?
- Pregunta 3
¿Qué clientes compran de nuevo y cuánto valen?
El
pedido.
Una tienda online vende en varios canales y quiere un tablero que responda tres preguntas. Los datos están en 4 tablas detrás de una API de solo lectura. Tu trabajo es traerlos, ordenarlos y limpiarlos por capas, y armar el tablero. El día 1 lo pasás a tus palabras: esto es el enunciado, no la solución.
Los datos
| Tabla | Qué es | Columnas | Filas |
|---|---|---|---|
customers | Clientes | customer_id, first_name, last_name, email, city, country, created_at | 1.000 |
products | Catálogo | product_id, name, category, price, cost, created_at | 80 |
orders | Pedidos | order_id, customer_id, status, channel, order_date | 8.025 |
order_items | Líneas de pedido | order_item_id, order_id, product_id, quantity, unit_price, discount | 19.865 |
Los datos son sintéticos y traen los problemas típicos de los reales. Encontrarlos es parte del ejercicio: nadie te los va a listar.
Las cuatro capas
rawCopia fiel de lo que devuelve la API, más la columna _loaded_at. No se modifica.stgLo mismo que raw, con nombres consistentes y tipos correctos. Sin joins ni lógica de negocio.intAcá viven la limpieza y los joins entre tablas.martTablas listas para el tablero. Es lo único que lee el dashboard.
Ventas netas
Suma de quantity × unit_price × (1 − discount) sobre los pedidos que no estén cancelados ni devueltos. El descuento es una proporción entre 0 y 1.
Qué entra
- ✓Ingesta de las 4 tablas desde la API, con respaldo en CSV
- ✓dbt con cuatro capas (raw, stg, int y mart), tests y documentación
- ✓Un dashboard con una visual por pregunta y un filtro por fecha
- ✓Un scheduler que corre todo el flujo una vez por día
Qué no entra
- ✕Orquestadores pesados (Airflow, Dagster) ni streaming
- ✕Docker como requisito
- ✕Infraestructura como código
Cómo sabés que terminaste
- ☐python run.py run corre de punta a punta, desde un clon limpio, sin tocar código
- ☐Las capas raw, stg, int y mart existen con esos nombres exactos
- ☐dbt build pasa con al menos 12 tests en verde
- ☐Las ventas netas de los tres marts coinciden con las calculadas desde int
- ☐El dashboard muestra las tres visuales y lee solo de los marts
- ☐No hay ningún secreto (token, claves) en el repo
El camino
del dato.
Python trae el dato hasta raw. dbt lo transforma en tres capas. El dashboard lee solo la última.
- API Cloudflare Worker
- Ingesta Python
- raw copia fiel
- stg tipos y nombres
- int limpieza y joins
- mart listo para usar
- Dashboard Streamlit
Lo escribís en Python Lo construye dbt
La semana,
paso a paso.
Lo que hacés cada día. El detalle, los errores típicos y las tres preguntas de control de cada día están en la guía del repo.
- Día 1
Entender el problema
Escribís el requerimiento con tus palabras, lo partís en tickets y dibujás el flujo. Todavía sin código.
- Instalá el proyecto y corré python run.py setup
- Escribí el requerimiento con tus palabras
- Partilo en tickets con criterios verificables
- Dibujá el flujo, de la API al dashboard
- Mirá los CSV y anotá lo que te llame la atención
- Día 2
Traer los datos
Un script de Python que pagina la API, respeta el límite de pedidos y carga raw. Con respaldo en CSV.
- Sacá tu token y probá la API a mano
- Paginá cada tabla hasta juntar el total
- Esperá y reintentá cuando la API diga 429
- Escribí las 4 tablas en raw, con _loaded_at
- Comprobá que la API y el CSV den exactamente lo mismo
- Día 3
Ordenar y limpiar
stg con tipos correctos e int con una regla por cada problema que encuentres en los datos, con sus tests.
- Declarás raw como source, con test de frescura
- Armás los 4 modelos stg: tipos y nombres, nada más
- Explorás los datos y anotás cada problema que encontrás
- Escribís una regla de limpieza por problema, en int
- Agregás tests que prueben que la limpieza funcionó
- Día 4
Responder las preguntas
Tres marts, un test que reconcilia las ventas entre capas y la documentación de dbt.
- Un mart por pregunta: decidí qué es una fila
- Escribí las definiciones en el schema.yml
- Usá macros que corran en DuckDB y en BigQuery
- Test de reconciliación: los marts cierran contra int
- Generá la documentación y revisá el linaje
- Fin de semana
Contarlo
Tu README y el story.md: el guion para contar el proyecto en una entrevista.
- Reescribí el README para que otro llegue al dashboard solo
- Completá story.md: contexto, decisiones, qué se rompió, cómo lo resolviste y qué harías distinto
Arrancá en
tres pasos.
- 1
Creá tu copia del repo
Es un template de GitHub: trae la estructura, la instalación y la guía. Lo que es ejercicio viene vacío.
Usar el template ↗ - 2
Sacá tu token de acceso a los datos
Es personal y te da acceso a la API de solo lectura. Con tu email te sumamos también a la Sala de máquinas.
Listo, este es tu acceso. Guardalo ahora: se muestra una sola vez. Si lo perdés, pedí otro y el anterior deja de funcionar.
Pegalo en tu archivo .env
Probalo desde la terminal
- 3
Seguí la guía, día por día
Empezá por el día 1, en
docs/guia/de tu copia. Si la API no responde, el proyecto trae los mismos datos en CSV dentro dedata/seed/.
Cómo responde la API
GET {API_URL}/tables/{tabla}?limit=1000&offset=0
Authorization: Bearer {tu token}
tablas: customers, products, orders, order_items
limit: de 1 a 1000 · offset: desde 0
200 → { "table", "total", "limit", "offset", "rows": [ ... ] }
401 → falta el token o no es válido
429 → pediste demasiado rápido: esperá lo que dice Retry-AfterDos carriles,
un solo proyecto.
Los modelos de dbt son los mismos en los dos. Cambia solo la conexión.
- Camino oficial
Local
- DatosUn archivo DuckDB dentro del proyecto
- TableroStreamlit
- ParaPara todos, sin cuenta en la nube
- Paso siguiente
Nube
- DatosBigQuery, en el sandbox gratis
- TableroLooker Studio
- ParaPara quien terminó el carril local
Lo que te
llevás.
Un proyecto que podés mostrar y, sobre todo, contar.
- ✓Un repo tuyo, con un README que cualquiera puede seguir
- ✓Los tickets que escribiste antes de empezar
- ✓El diagrama del flujo, de la API al dashboard
- ✓Un dashboard que responde las tres preguntas
- ✓Tests que prueban que los números cierran
- ✓Un story.md para contarlo en una entrevista
Preguntas
frecuentes.
¿Cuánto tiempo lleva el proyecto de datos de punta a punta?
Una semana: cinco días de trabajo, de 4 a 6 horas cada uno, y el fin de semana para escribir el README y el story.md. La guía marca qué hacer cada día.
¿Necesito saber dbt para hacerlo?
No hace falta haberlo usado. Sí conviene saber SQL básico (select, join, group by) y algo de Python. La guía explica cada concepto de dbt cuando lo necesitás.
¿Necesito tarjeta de crédito o una cuenta en la nube?
No. El camino oficial corre en tu computadora con DuckDB, que es un archivo dentro del proyecto. El carril de BigQuery es opcional y usa el sandbox gratis de Google, que no pide tarjeta.
¿Los datos son de clientes reales?
No. Son datos sintéticos de un e-commerce (clientes, productos, pedidos y líneas de pedido), armados para tener los problemas típicos de los datos reales: duplicados, valores mal escritos, vacíos y referencias rotas.
¿Qué le muestro a un reclutador cuando termino?
Tu repo con el README, los tickets que escribiste antes de empezar, el diagrama del flujo, el dashboard funcionando y el story.md: contexto, decisiones, qué se rompió, cómo lo resolviste y qué harías distinto.
Aprendamos juntos para dónde
va la tecnología.
Una comunidad para ayudarnos entre todos: ver lo que está saliendo, charlar una vez por semana y armar proyectos de verdad. Gratis, y muy conectada con lo que publico en TikTok e Instagram.
-
Lo que está saliendo
Las herramientas y novedades que importan, probadas y contadas sin humo.
-
Charla semanal
Una vez por semana nos juntamos en vivo a charlar de tecnología. Los temas los proponen ustedes.
-
Proyectos de punta a punta
Proyectos con datos que traen los mismos problemas que los reales, para mostrar en una entrevista. No ejercicios de juguete.