Biblioteca
Guías, artículos, repositorios y recursos gratuitos sobre ingeniería y arquitectura de datos. La biblioteca está disponible sin registro.
Recorridos por colección
Las colecciones ordenan los artículos como series temáticas para leer de principio a fin.
Modelado
Diseño de modelos analíticos, dimensional, Kimball, grano y métricas
Guía definitiva de funciones ventana en SQL
Sintaxis, PARTITION BY, ORDER BY, LAG, NTILE y ventanas deslizantes con ejemplos prácticos.
Modelado dimensional: técnicas y mejores prácticas
Proceso de diseño de Kimball, dimensiones, hechos, arquitectura bus y dimensiones de cambio lento.
Modelado dimensional: técnicas avanzadas
Dimensiones degeneradas, role-playing, junk dimensions, mini-dimensiones y tablas puente.
Dimensiones lentamente cambiantes: guía práctica
Tipos de SCD (0-4), implementación SQL paso a paso y consideraciones de diseño.
Claves subrogadas
Comparación entre enteros incrementales y hashes, ventajas, desventajas y ejemplos de implementación.
Modelado de datos: fundamentos y mejores prácticas
Modelos conceptual, lógico y físico. Normalización y formas normales explicadas.
sql_modelado_dimensional
Repositorio con ejercicios prácticos de modelado dimensional usando SQL.
OLTP vs OLAP: no es solo una diferencia de performance
La diferencia entre OLTP y OLAP no es técnica, es de propósito: uno registra transacciones, el otro responde preguntas de negocio. Confundir esto lleva a modelos que no sirven para ninguna de las dos cosas.
El modelo como norte de la transformación
El error común es resolver primero los pipelines y después ver cómo se modela. Pero para ese momento ya hay decisiones tomadas que condicionan el modelo. La alternativa es pensar el modelo primero: qué preguntas de negocio hay que responder, qué dimensiones, qué hechos. La transformación existe para darle vida a un modelo ya pensado.
SCD Tipo 2: cómo mantener historia en dimensiones sin volverte loco
SCD Tipo 2 es el patrón estándar para mantener historia en dimensiones, pero tiene complejidad operativa real. Hay que entender cuándo vale la pena y cuándo no.
Cada métrica en la tabla de hechos debe ser coherente con el grano definido
El grano de una tabla de hechos define qué representa cada fila. Cualquier métrica que agregues debe poder calcularse a ese nivel de detalle. Si la métrica requiere un grano distinto, pertenece a otra tabla.
Transformación
Cómo se transforma el dato: materializaciones, DAG, abstracción y ELT
Transformación de datos: estructura de proyectos en dbt
Capas staging, intermediate y marts. Convenciones de nomenclatura y mejores prácticas de dbt Labs.
Transformación de datos: pruebas en dbt
Tests genéricos y singulares: unique, not_null, relationships, accepted_values y store_failures.
Transformación de datos: entornos en dbt Core
Configuración de targets, perfiles, variables de entorno y esquemas de desarrollo vs producción.
Transformación como disciplina: SQL declarativo, linaje y versionado
La transformación de datos no es escribir SQL suelto; es una disciplina que requiere código versionado, dependencias explícitas y un grafo que se pueda razonar.
Views, tablas e incrementales: tres formas de persistir transformaciones
La elección de materialización (view, table, incremental) tiene trade-offs de costo, latencia y complejidad. No hay respuesta universal; depende del caso de uso.
Datos externos vs datos versionados en tu proyecto
Un source marca datos que vienen de afuera y no controlás. Un seed es un archivo que versionás con tu proyecto. La diferencia es de responsabilidad y control, no solo de ubicación.
El templating es código: aplican las mismas reglas de siempre
Las herramientas de transformación permiten abstraer lógica con templating y macros. Esa capacidad es valiosa, pero el templating es código y aplican las mismas reglas de calidad de siempre: nombres claros, funciones que hacen una cosa, evitar anidamiento excesivo.
Diseñar pipelines para reprocesar desde el inicio
Las suposiciones del diseño cambian con el tiempo; el reproceso es parte del trabajo, no un accidente. Diseñar para reprocesar desde el inicio evita parches costosos después.
Ingesta
Cómo entra el dato: full, incremental, CDC y contratos de esquema
Guía práctica para la ingesta de datos
Patrones de ingesta, batch vs streaming, CDC, APIs y consideraciones de diseño para pipelines.
Conceptos básicos de dlt
Introducción a la biblioteca Python dlt: sources, resources, schemas y configuración de pipelines.
Docker para ingeniería de datos
Contenedores, imágenes, volúmenes, buenas prácticas y ejemplo de pipeline containerizado.
Orquestación de datos
Fundamentos de pipelines, determinismo, idempotencia, runbooks y errores comunes a evitar.
CI/CD en datos: de DevOps a DataOps
Pre-commits, unit tests en dbt, integración continua y despliegue continuo aplicado a datos.
curso-ingesta
Tutorial práctico de ingesta de datos con ejemplos de código.
especializacion-ingenieria-de-datos
Proyecto completo de ingeniería de datos con múltiples componentes.
Full, incremental y CDC: tres mecanismos, tres presupuestos de confianza
Full refresh, incremental y CDC son tres estrategias de extracción con diferentes presupuestos sobre la fuente. Elegir mal genera problemas de consistencia o costos innecesarios.
Orquestar es simple, operarlo no
El concepto de orquestación es acotado: etapas, dependencias, paralelismo. Pero operarlo en producción tiene complejidades que no aparecen en el tutorial: colas, reintentos parciales, componentes que interactúan, base de metadata.
Arquitectura
Decisiones de stack, almacenamiento, orquestación, escala y plataforma
Consumo y serving de datos
BI, APIs de exposición, Reverse ETL, capa semántica y GenBI con LLMs.
Arquitectura medallion en producción
Capas bronze, silver y gold. Diseño, implementación y consideraciones para entornos productivos.
lakehouse-aws-athena
Implementación de arquitectura Lakehouse con Athena y dbt.
Medallion es moda: lo que importa es el criterio de cada capa
Los nombres de las capas (bronce/plata/oro, raw/staging/consumo) importan menos que definir criterios explícitos de qué datos viven en cada una y por qué
El orquestador coordina, no transforma
El orquestador define dependencias y dispara tareas; meter transformaciones o lógica de negocio adentro es un error de diseño que escala mal
La inmutabilidad del object storage explica por qué existen los lakehouse
El object storage no está pensado para modificar objetos parcialmente; esa restricción física explica por qué existen los lakehouse para resolver updates sobre archivos
Data warehouse clásico: cómputo y almacenamiento acoplados te hacen pagar de más
Los data warehouses tradicionales acoplan cómputo y almacenamiento, lo que genera costos innecesarios cuando uno escala más que el otro. Entender este acoplamiento explica por qué surgieron las arquitecturas modernas.
La promesa del data lake y el descontrol sin gobierno
El problema del data lake fue acumular datos sin gobierno ni problema de negocio claro.
Herramientas modulares vs plataformas integradas
Un stack de herramientas de propósito específico te permite reemplazar piezas sin rehacer todo. Las suites integradas ofrecen conveniencia a cambio de acoplamiento.
Batch, micro-batch o streaming: la latencia define la arquitectura
La latencia que necesita el negocio define qué estrategia de procesamiento usar. Batch, micro-batch y streaming tienen costos operativos y de consistencia muy distintos.
Elegir la herramienta según el problema, no al revés
Spark, Polars, pandas, motores SQL distribuidos: cada herramienta tiene un rango de problemas donde brilla. Elegir antes de entender el problema es la forma más rápida de sumar complejidad innecesaria.
Gobierno
Calidad, testing, linaje, ownership, documentación y políticas
Gobierno y calidad de datos
Dimensiones de calidad, reglas de validación, linaje de datos y catálogos.
Desnormalizar está bien, duplicar definiciones no
Repetir datos en un modelo analítico está bien si hay linaje claro y una sola definición del concepto. Lo que genera problemas es que el mismo concepto se calcule de forma distinta en dos lugares sin control.
El linaje como contrato: por qué importa más que el SQL
Las dependencias explícitas entre transformaciones son más valiosas que el SQL que escribís, porque habilitan gobierno, análisis de impacto y ejecución ordenada sin intervención manual.
Calidad de datos no es un módulo aparte, es una decisión transversal
Tratar la calidad como una etapa separada del pipeline garantiza que se postergue y que cuando se atienda ya sea tarde; la calidad se decide en cada etapa del flujo, desde la ingesta.
Testing en transformaciones: validar suposiciones, no solo código
Los tests en datos validan suposiciones sobre los datos, no solo que el código corra. Testear que una columna sea única o no nula es validar un contrato con la fuente.
Cuando el dueño del dato es 'el equipo', nadie es responsable
Si el dueño del dato es 'el área de ventas' en lugar de una persona con nombre y apellido, cuando hay problemas de calidad nadie se hace cargo y el problema termina en el inbox de ingeniería.
Cuándo frenar el pipeline por un fallo de calidad
Frenar el pipeline ante un fallo de calidad es una decisión drástica que depende de la criticidad del dato, la madurez del proceso y la capacidad de respuesta del equipo. No es un detalle técnico menor.
Monorepo vs multi-repo en transformación: el dilema de las dimensiones conformadas
Partir el proyecto de transformación en múltiples repositorios reduce la complejidad percibida, pero choca con las dimensiones conformadas que necesitan compartirse entre dominios.
Documentación que agrega valor: escribir para quien no conoce el contexto
La documentación que agrega valor es la que permite a alguien que no conoce el contexto entender qué significa un dato, de dónde viene y para qué sirve. Documentar lo obvio es contraproducente.
Carrera
Crecimiento profesional, habilidades, comunicación, aprendizaje y portfolio
Cómo desbloquear tu carrera
Conversación con Antony Henao sobre tomar iniciativa, buscar responsabilidades y tener conversaciones que impulsen tu carrera.
La carrera en ingeniería de datos ya no funciona como antes
Conversación con Ian Saura sobre proyectos con contexto, entrevistas, comunicación en equipos técnicos y el rol de la comunidad.
Por qué los fundamentos importan más que las herramientas
Con fundamentos sólidos, una herramienta nueva se puede aprender en días para una entrevista; perseguir cada release sin base conceptual es una carrera que no se gana.
El retorno marginal de profundizar solo lo técnico tiene techo corto
Hay un punto donde seguir profundizando solo en lo técnico tiene retornos decrecientes. Las habilidades que escalan después son otras: comunicación, entender el negocio, influencia.
Comunicar impacto y decisiones es parte del rol de datos, no un extra
Quien trabaja con datos debe poder comunicar impacto y decisiones. Es responsabilidad del rol hacerse entender, no un skill opcional que se desarrolla si sobra tiempo.
La medida de éxito de un proyecto de datos es si lo usa la gente
Un proyecto de datos técnicamente impecable que nadie usa es un fracaso. La adopción real es la única métrica que importa al final.
El portfolio útil es la narrativa de problemas, alternativas y trade-offs
Un portfolio cosmético importa menos que poder contar qué resolviste, con qué alternativas y qué trade-offs. Esa narrativa conecta los fundamentos, la comunicación y el impacto real.