Si la Parte II resolvía dónde se guarda el dato, esta tercera parte responde a una pregunta anterior y más incordiante: cómo llega hasta ahí. Entre el sistema que genera un registro y la tabla que alimenta un informe hay un recorrido de extracciones, colas, transformaciones, reintentos y validaciones que rara vez aparece en los diagramas de arquitectura y siempre aparece en los partes de incidencia.
La integración de datos concentra una paradoja operativa conocida por cualquier equipo con pipelines en producción: es la capa que menos presupuesto de diseño recibe y más tiempo de mantenimiento consume. Un motor de base de datos bien elegido puede pasar años sin sobresaltos; un pipeline mal diseñado genera guardias, reprocesos nocturnos y cifras que no cuadran entre dos informes que deberían decir lo mismo.
El recorrido de esta parte va de la decisión estructural al detalle operativo. Arranca con los fundamentos que condicionan todo lo demás —eventos frente a lotes, transformar en origen o en destino, qué herramienta hace realmente qué— y desciende después a la mecánica de construir ingesta resiliente, capturar cambios sin castigar los sistemas operacionales, vigilar la calidad del dato en ejecución, orquestar dependencias, testear antes de desplegar y mantener vivo el inventario de lo que existe. Cierra con un caso aplicado que pone todas esas decisiones a la vez sobre la mesa.
¿Para quién es esta parte?
Es la sección de trabajo diario de data engineers, ingenieros de integración y arquitectos que diseñan, construyen y mantienen pipelines. Aquí están los patrones que evitan reprocesos, los anti-patrones que los provocan y los criterios para elegir herramienta sin quedar atrapado en ella.
El CIO y los responsables de área encontrarán el vocabulario para valorar propuestas y estimaciones: por qué un requisito de latencia dispara el coste, qué significa realmente «tiempo real» en una propuesta y qué deuda técnica se está comprando al aceptar el atajo. Analistas y científicos de datos pueden ir directos a los capítulos de calidad, testing y linaje: son los que explican por qué el dato que reciben es como es.
Capítulos de esta parte
Ingesta de datos a escala: pipelines resilientes Próximamente
Idempotencia, backpressure y políticas de reintento. Cómo construir ingesta que sobrevive a picos, duplicados y caídas del origen sin intervención manual.
CDC y replicación: captura de cambios en la práctica Próximamente
Lectura de log frente a triggers, servicios gestionados y réplica nativa. Cómo capturar cada cambio sin penalizar la base de datos que sostiene el negocio.
Calidad de datos en el pipeline Próximamente
Validaciones, observabilidad y acuerdos de servicio sobre el dato. Cómo detectar el registro defectuoso antes de que lo encuentre quien lee el informe.
Orquestación de pipelines: DAGs, reintentos y alerting Próximamente
Quién decide qué se ejecuta, en qué orden y qué ocurre cuando algo falla a las tres de la mañana. Dependencias, políticas de reintento y alertas que alguien atiende.
Testing de pipelines y datos: unitarios, integración y contratos Próximamente
La red que se coloca antes del despliegue, no después del incidente. Cómo se testea la lógica y cómo se testean las asunciones sobre el dato de entrada.
Automatización del linaje y del catálogo de datos Próximamente
El inventario que se mantiene solo porque lo emite el propio pipeline. Del diccionario de datos en hoja de cálculo al linaje extraído de cada ejecución.
Caso aplicado: migración de ETL a ELT en una cadena de retail Próximamente
El capítulo de cierre integra la parte en un rediseño completo: decisiones tomadas, costes, plazos y errores incluidos. Caso ficticio construido con fines didácticos.
El hilo conductor de esta parte
La sección avanza en cuatro movimientos. El primero fija las decisiones estructurales, las que se toman una vez y se pagan durante años: lotes o eventos (cap. 19), transformar antes o después de cargar (cap. 20) y qué herramienta ocupa cada casilla del stack (cap. 21).
El segundo construye el pipeline: ingesta que aguanta (cap. 22) y captura de cambios desde los sistemas operacionales (cap. 23). El tercero es el que separa un pipeline que funciona de uno en el que se puede confiar: calidad en ejecución (cap. 24), orquestación con reintentos y alertas (cap. 25) y testing antes del despliegue (cap. 26). Son tres controles distintos en tres momentos distintos, y confundirlos es una de las causas más frecuentes de falsa sensación de cobertura.
El cuarto movimiento responde a la pregunta de gobierno operativo —¿sabe alguien qué datos existen y de dónde vienen? (cap. 27)— y abre la puerta a la Parte VI. El caso de la cadena de retail (cap. 28) cierra la sección mostrando todas estas decisiones tomadas a la vez, con presupuesto y calendario reales.
Una idea recorre toda la parte: en integración de datos, la latencia es un presupuesto. Cada salto hacia el «tiempo real» multiplica el coste de infraestructura, la superficie de fallo y las horas de guardia. La pregunta correcta nunca es cuánto se puede reducir la latencia, sino cuánta latencia tolera realmente la decisión de negocio que hay al final del pipeline.
Selección de software: rankings de Dataprix
Las decisiones de esta parte acaban materializándose en una herramienta concreta con un contrato detrás. Para acompañar esa elección, Dataprix mantiene un ranking actualizado de la categoría, con criterios de evaluación independientes:
🎓 Formación recomendada para esta parte
Profundiza en ingeniería de datos, pipelines y procesamiento en streaming con estos cursos en español:
Enlaces de afiliado · Dataprix puede recibir una comisión por tus compras.
Continúa tu recorrido por la guía
Guía práctica de arquitectura de datos · Una serie de Dataprix.com · Knowledge is the goal
Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix
