Ingeniería de datos · en detalle
Proceso, entregables, precios y qué vas a construir de verdad.
Alguien tiene que escribir los pipelines que mueven el dato desde los sistemas origen hasta los dashboards. Este es el trabajo que convierte diagramas de arquitectura en código funcionando — probado, monitorizado y mantenido para el siguiente equipo.
Proceso paso a paso
El trabajo de ingeniería sigue una secuencia de construcción clara.
No puedes transformar datos antes de haberlos ingerido. No puedes optimizar consultas antes de saber cuáles van lentas. Todo pipeline empieza igual.
Conexión con el origen y descubrimiento de esquema
Nos conectamos a tus sistemas origen — SAP, Salesforce, PostgreSQL, APIs — y extraemos sus esquemas. Identificamos claves primarias, claves foráneas, patrones de actualización y tipos de datos. Probamos la lógica de extracción sobre un subconjunto de tablas para validar conectividad, permisos y rendimiento. Esto no es la ingesta completa. Es la prueba de que el pipeline puede funcionar.
Entregable: documentación de conexión y extractos de muestra de cada fuente.
Construcción de la capa Bronze y carga incremental
Construimos pipelines de ingesta que depositan datos en bruto en tu data lake o warehouse. Implementamos carga incremental donde es posible (usando change data capture, watermarks o timestamps) para evitar escaneos completos de tabla. Añadimos logging, gestión de errores y lógica de reintento. Cada tabla tiene su propio pipeline. Cada pipeline corre según un calendario.
Entregable: pipelines Bronze automatizados con monitorización y alertas.
Transformación Silver/Gold y calidad del dato
Transformamos los datos en bruto en tablas limpias, cruzadas y agregadas. Aplicamos lógica de negocio — conversiones de divisa, cálculos de fecha, mapeos de categoría. Añadimos comprobaciones de calidad del dato (tasas de nulos, detección de duplicados, alertas de schema drift). Versionamos cada transformación para que los cambios sean trazables. Esta es la capa que consultan los analistas y los dashboards.
Entregable: pipelines de transformación con tests de calidad del dato y trazabilidad del linaje.
Pruebas, despliegue y entrega
Escribimos tests unitarios para la lógica de transformación y tests de integración para el flujo de datos de principio a fin. Desplegamos los pipelines mediante CI/CD (dev → test → prod) con puntos de aprobación. Documentamos dependencias, calendarios y escenarios de fallo. Al final, hacemos una sesión de entrega técnica con tu equipo para transferir la propiedad.
Entregable: configuración de CI/CD, batería de tests, runbooks y documentación de entrega.
Entregables detallados
Qué recibes realmente
Son pipelines de producción, no scripts de prueba de concepto. Corren a diario, gestionan fallos y registran cada operación. Tu equipo puede mantenerlos sin nosotros.
Pipelines de ingesta Bronze
Procesos de extracción automatizados que sacan datos de los sistemas origen y los depositan en tu data lake o warehouse. Cada pipeline incluye lógica de carga incremental (donde es posible), gestión de errores, políticas de reintento y logging. Los pipelines están parametrizados para poder relanzar rangos de fechas o tablas concretas sin tocar el código.
DAGs de transformación (Silver/Gold)
Lógica de transformación en SQL o Python organizada en grafos dirigidos acíclicos (DAG). Cada transformación declara sus dependencias — qué tablas lee, cuáles escribe, en qué orden. Esto permite recargar datos históricos, depurar fallos y entender el linaje sin leer todo el código.
Tests de calidad del dato
Comprobaciones automáticas que se ejecutan tras cada ejecución del pipeline: umbrales de tasa de nulos, restricciones de unicidad, integridad referencial, validación de esquema, variaciones en el número de filas. Los fallos disparan alertas (email, Slack, PagerDuty) con contexto suficiente para diagnosticar el problema sin tener que entrar por SSH a un servidor.
Configuración de despliegue CI/CD
Pipelines de GitHub Actions, Azure DevOps o GitLab CI que prueban y despliegan código entre entornos (dev, test, prod). Los cambios pasan por pull requests, tests automáticos y puntos de aprobación. Los rollbacks son un solo comando. Esto evita incidentes de producción del tipo «en mi máquina funciona».
Runbooks y guías de resolución de incidencias
Instrucciones paso a paso para los escenarios de fallo habituales: sistema origen caído, cambio de esquema, pico en el número de filas, timeout de consulta. Cada runbook indica dónde revisar los logs, qué métricas mirar y cómo escalar. Esto permite a los ingenieros junior gestionar incidencias sin tener que escalar a los senior.
Dashboards de monitorización
Dashboards de Grafana, Databricks o nativos de la plataforma que muestran tiempos de ejecución del pipeline, filas procesadas, retraso de frescura del dato, tasas de error y coste por tabla. Se ve de un vistazo qué pipelines van lentos, cuáles fallaron por la noche y si el dato está al día.
Caso relacionado
Educación: atribución de marketing y modelado de ROI
Un cliente del sector educativo necesitaba unificar datos de Facebook Ads, Google Ads, Google Analytics, TikTok Ads, Spotify Ads, SEMRush y Google Search Console con datos financieros para calcular el ROI real de marketing y modelar embudos de conversión entre landing pages. Construimos pipelines de ingesta incremental para 7 fuentes de marketing, lógica de transformación que cruzaba el gasto de campaña con el ingreso, y tablas de KPI que seguían el coste por adquisición y el valor de vida por canal — permitiéndoles reasignar €180k/año desde plataformas de bajo ROI a campañas de alta conversión.
Leer el caso completo →Precios y qué los afecta
Contexto de precios transparente
Proyecto base de ingeniería
€40/hora
Estimado 160–240 horas · 4–6 semanas
Qué hace que el precio suba
- Número de tablas/endpoints: ingerir 100 tablas lleva más tiempo que ingerir 10. Cada una requiere lógica de extracción, mapeo de esquema y patrones de carga incremental.
- Transformaciones complejas: los joins y agregaciones simples son rápidos. La lógica multietapa con reglas de negocio, aritmética de fechas y conversiones de divisa requiere más pruebas.
- Requisitos en tiempo real o casi real: los pipelines batch (diarios, horarios) son más sencillos que el streaming (CDC, colas de mensajes, disparadores por evento).
- Sistemas origen legados: extraer de bases de datos on-premise antiguas sin API, con esquemas sin documentar o con acceso de red restringido requiere conectores a medida y configuración VPN.
Qué mantiene el precio bajo
- Conectores estándar disponibles: si tus fuentes tienen Fivetran, Airbyte o conectores nativos de la nube, los usamos en vez de escribir código de extracción a medida.
- Agregaciones simples: sumar, contar, promediar, agrupar — si es todo lo que necesitas, la lógica de transformación es directa.
- Cargas solo batch: los pipelines nocturnos diarios son más sencillos y baratos que la ingesta horaria o en tiempo real.
- Arquitectura ya definida: si ya tienes las capas Bronze/Silver/Gold definidas, estamos implementando, no diseñando desde cero.
Refuerzo de equipo
€37,5/hora
Un ingeniero integrado en tu equipo durante 6+ meses
Mantenimiento de pipelines
€40/hora
Monitorización continua, corrección de errores y gestión de cambios de esquema
Preguntas
Preguntas frecuentes: ingeniería de datos
¿Necesito un ingeniero si ya tengo Fivetran o Airbyte?
No para la ingesta básica. Si tus fuentes tienen conectores ya hechos y solo necesitas datos en bruto en tu warehouse, herramientas como Fivetran lo resuelven. La ingeniería se vuelve necesaria cuando necesitas transformaciones a medida, lógica de negocio, comprobaciones de calidad del dato u orquestación entre varios sistemas que los conectores no cubren.
¿Cuál es la diferencia entre ELT y ETL?
ETL (Extract, Transform, Load) transforma el dato antes de cargarlo en el warehouse — habitual en sistemas on-premise antiguos donde el almacenamiento era caro. ELT (Extract, Load, Transform) carga primero el dato en bruto y lo transforma después en el warehouse usando SQL. Las plataformas cloud modernas (Snowflake, Databricks, BigQuery) están optimizadas para ELT porque el cómputo es más barato que mover datos de un lado a otro.
¿Cómo gestionáis los cambios de esquema en los sistemas origen?
Usamos patrones de evolución de esquema: añadir columnas nuevas no rompe los pipelines existentes, eliminar columnas dispara alertas, renombrar columnas se gestiona con capas de mapeo. Versionamos las transformaciones para que los cambios sean trazables. En las tablas críticas añadimos tests de validación de esquema que fallan si aparecen cambios inesperados, forzando una revisión antes de que el dato se propague aguas abajo.
Siguientes pasos
La ingeniería llega después de la arquitectura.
Si sabes a dónde tiene que ir tu dato y qué forma tiene que tener, aquí es donde construyes los pipelines que lo llevan hasta allí.
O vuelve a todos los servicios