Ingeniería de datos
Pipelines a los que tu negocio puede apostar.
Datos que llegan completos, a tiempo, siempre: de los sistemas que tu empresa ya usa a los lugares donde generan valor, sin un rescate semanal.
Qué construimos
- Pipelines e integraciones, en batch y en streaming
- Conectores a los sistemas que realmente están en uso (bases de datos, ERPs, CRMs, APIs)
- Ingeniería de confiabilidad: monitoreo, reintentos, alertas y backfills limpios
- Diseño consciente del costo: tu factura debería seguir tu uso, no las ambiciones de tu proveedor
Pruebas
Oxford Economics
Análisis guiado por eventos, entregado mientras todavía importa: el pipeline desde los sistemas en los que trabajan los economistas hasta la plataforma que leen sus clientes, reconstruido para que publicar dejara de esperar a ingeniería.
Leer el caso- Sistemas → pipeline → plataforma
- Publicar sin una cola de ingeniería
Cuándo nos buscan los equipos
- Reportes armados a mano cada semana
- Datos que se rompen en silencio y se descubren aguas abajo
- Cada pregunta nueva convertida en un ticket de ingeniería
El rescate semanal
Preguntar a un equipo cómo va su pipeline de datos suele tener como respuesta honesta el nombre de una persona: la que el lunes nota que los números se ven mal, vuelve a correr el job, parcha el archivo a mano y saca el reporte antes del mediodía. Funciona, en el sentido de que el reporte llega. También significa que el pipeline no tiene idea de que falló, que nadie más que esa persona puede arreglarlo y que los tres días de datos malos que ya pasaron aguas abajo nunca se van a corregir.
Eso no es un problema de confiabilidad; es un diseño que nunca consideró la falla. Un pipeline al que se le puede apostar sabe cómo se ve una corrida completa y lo dice cuando no lo es, antes de que alguien aguas abajo lea el resultado. Se puede volver a correr para cualquier día sin duplicar filas ni perderlas, porque cada paso es idempotente y cada partición tiene fecha. Y tiene un nombre encima, un runbook y una alerta que llega a alguien que puede actuar. Nada de eso es exótico. Es la diferencia entre un flujo que se armó y un flujo que se hizo con ingeniería.
Cómo lo construimos
Mapear fuentes y consumidores
dónde viven los datos, quién los necesita
Diseñar para la falla
reintentos, alertas y backfills limpios desde el día uno
Entregar de forma incremental
primero el flujo de mayor valor
Operar y ajustar
confiabilidad y costo, revisados como código
Qué significa “poder apostar”
Completo o ruidoso
un pipeline que entrega la mitad de las filas y no dice nada es peor que uno que falla y avisa. Cada flujo que construimos sabe cómo se ve una corrida completa y lo dice cuando no lo es.
Reejecutable
cuando algo aguas arriba estuvo mal tres días, el arreglo es un backfill limpio, no un fin de semana. Los pasos idempotentes y las particiones con fecha son aburridos, y son toda la diferencia.
Con dueño
cada flujo tiene un nombre encima, un runbook y una alerta que va a una persona que puede actuar. Que los datos se rompan en silencio y se descubran aguas abajo es una decisión de diseño, y es la que no tomamos.
Con precio por uso
batch donde batch alcanza, streaming donde una decisión lo necesita. Tu factura debería seguir tu uso, no las ambiciones de tu proveedor.
El rescate semanal no es un problema de personas. Es un pipeline que nunca se diseñó para fallar bien.
Funciona bien con
Preguntas frecuentes
¿Batch o streaming?
Lo decide el caso de uso. Streaming en todas partes es cómo explotan las facturas.
¿Pueden trabajar con nuestras fuentes legacy?
Los ERPs viejos y las APIs raras son nuestro caso normal, no la excepción.
¿Quién lo mantiene después?
Construido para entregar: documentación, alertas, runbooks, o lo operamos con ustedes.
¿Cómo empiezan sin detener lo que funciona hoy?
Mapeando primero: qué fuentes alimentan a qué consumidores y qué flujo cuesta más cuando se rompe. Ese se reconstruye primero, en paralelo con el viejo, y el viejo se apaga solo cuando el nuevo corrió limpio un tiempo. A nadie le falta el reporte del lunes.
¿Esto es lo mismo que datos listos para IA?
Es la base que va debajo. Estar listo pregunta si un caso de uso concreto puede alcanzar datos confiables en la forma que necesita; la ingeniería es lo que hace que "confiable" sea verdad para todo lo que está aguas abajo, la IA incluida. Dimensionados juntos, son una sola inversión.
¿Necesitamos una plataforma de datos primero?
No. La mayoría del trabajo de pipelines empieza por el flujo que más duele —el reporte semanal armado a mano, la integración que se rompe en silencio— y deja los datos donde ya van hoy. Si después llega una plataforma, los pipelines están construidos para alimentarla; si no llega, siguen en pie por sí solos.