Ingeniería de datos
Pipelines ELT fiables, modelos de datos claros y tests de calidad para que tus informes y modelos se apoyen en datos en los que se pueda confiar y que se actualicen sin intervención manual.
Actualizado:
Las métricas se calculan en sitios distintos con reglas ligeramente diferentes. Nadie sabe cuál es la buena.
Un pipeline que falla en silencio, tarda demasiado o se reconstruye por completo cada día encarece y retrasa todo lo demás.
Cuando cambia una columna en origen nadie se entera hasta que un informe sale mal.
Las consultas escanean más datos de los necesarios y la factura del almacén sube sin que el negocio gane nada.
El patrón que suelo usar separa responsabilidades en capas. En base (o staging) se carga cada fuente casi tal cual, con nombres homogéneos, tipos corregidos y poco más: es la frontera entre el mundo exterior y el tuyo. En core se modelan las entidades del negocio —clientes, transacciones, productos— con reglas, deduplicación y claves bien definidas. En marts se construyen las tablas listas para cada uso: un cuadro de mando, un modelo predictivo o una exportación. Cada capa tiene sus tests y su documentación, y las dependencias entre modelos las gestiona dbt.
Los tests no son un añadido final. Desde el primer modelo defino pruebas de unicidad y no nulos en las claves, relaciones entre tablas y reglas de negocio (por ejemplo, que un importe no sea negativo salvo devoluciones). Añado comprobaciones de frescura para detectar fuentes que han dejado de llegar y, cuando es posible, concilio totales con el sistema de origen. Los fallos generan avisos concretos en lugar de informes silenciosamente erróneos.
Para ejecutar los pipelines de forma programada utilizo Airflow cuando el proyecto tiene dependencias suficientes para justificarlo; para necesidades más simples, una programación sencilla basta. En BigQuery, gran parte del ahorro viene de tres decisiones: consultar solo las columnas necesarias, particionar y agrupar las tablas grandes según cómo se filtran y evitar reconstrucciones completas cuando una carga incremental es suficiente.
He trabajado con SQL, dbt y BigQuery en un equipo de analítica de una fintech (descrito a alto nivel por confidencialidad) y mantengo un laboratorio personal con más de 250 000 transacciones sintéticas que ilustra la organización por capas, los tests y la orquestación. Lo encontrarás en proyectos.
Ingesta desde tus fuentes al almacén (BigQuery u otro), con cargas incrementales cuando procede y gestión de errores.
Capas base, core y marts con convenciones de nombres, documentación y linaje, listas para analítica y modelos.
Tests de unicidad, nulos, relaciones y reglas de negocio; comprobaciones de frescura y reconciliación con la fuente.
Ejecución programada y dependencias con Airflow u otra herramienta adecuada al tamaño del proyecto, con avisos de fallo.
Revisión de consultas y modelos, particionado, clustering y materializaciones para reducir tiempo y coste de proceso.
Qué datos existen, quién los usa, qué decisiones se toman con ellos y qué cifras deben cuadrar.
Defino entidades, granularidad y métricas con tu equipo antes de escribir transformaciones, para evitar rehacer.
Una fuente y un caso de uso completos antes de ampliar. Cada modelo con sus tests desde el primer día.
Comparo resultados con las cifras que ya conoces y documento las diferencias y su causa.
Orquestación, alertas, documentación y revisión de código para que tu equipo pueda mantenerlo.
Estructura de capas, convenciones y tests desde el inicio, con un primer cuadro de mando sobre datos fiables.
Convertir lógica dispersa en modelos versionados, probados y documentados.
Analizar por qué una carga diaria tarda tanto y pasar de reconstruirlo todo a cargas incrementales cuando los datos lo permiten.
Normalizar estructuras distintas en un modelo común con registros estandarizados.
En ETL los datos se transforman antes de cargarlos al almacén; en ELT se cargan primero y se transforman dentro del almacén con SQL. ELT con herramientas como dbt es hoy lo habitual en almacenes en la nube porque aprovecha su capacidad de cómputo y deja las transformaciones versionadas.
Mi experiencia profesional es con BigQuery y dbt. Los principios de modelado, pruebas y orquestación se trasladan a otros almacenes SQL; si tu entorno es otro te lo diré con claridad antes de empezar.
dbt permite escribir las transformaciones como consultas SQL versionadas, con tests y documentación generada automáticamente. Convierte lógica de datos en código revisable, en lugar de consultas sueltas.
Sí. Una revisión acotada identifica puntos frágiles, consultas costosas y falta de pruebas, y termina con una lista priorizada de mejoras.
En la página de experiencia describo a alto nivel mi trabajo con SQL, dbt y BigQuery en una fintech, y en proyectos tienes un laboratorio personal con datos sintéticos que muestra cómo organizo las capas.
Ingeniería de datosProyecto personal
Laboratorio personal que reproduce un entorno de analytics engineering sobre datos sintéticos de delitos financieros, con capas base, core y marts, tests de calidad y orquestación.
Ingeniería4 min de lectura
Cómo estructurar un proyecto dbt en capas base, core y marts, con convenciones de nombres, materializaciones, tests por capa y errores frecuentes.
Leer másDescubre dónde la IA aporta valor en tu operación y llévala a producción con control humano.
Ver servicioConvierte tareas manuales y repetitivas en flujos programados, trazables y fáciles de mantener.
Ver servicioUn asistente que responde con tus documentos, cita la fuente y respeta los permisos.
Ver servicioPrevisiones y clasificaciones evaluadas con honestidad frente a alternativas simples.
Ver servicioUna primera conversación sirve para saber si tiene sentido y por dónde empezar.