Extracción batch vs. CDC en SAP: cuándo usar cargas periódicas y cuándo capturar cambios

Mover datos desde SAP hacia una plataforma analítica o cloud no obliga a que todo viaje en tiempo real. Algunos datos pueden actualizarse una vez al día sin afectar ninguna decisión. Otros necesitan reflejar cambios minutos después de que ocurren.

Por eso la pregunta correcta no es:

¿batch o CDC es mejor?

Sino:

¿qué nivel de frescura necesita este dato y qué costo operativo estamos dispuestos a asumir?

¿Qué es una extracción batch?

Una carga batch ejecuta una extracción en momentos definidos.

• Por ejemplo:
• cada noche;
• cada hora;
• cada cuatro horas;
• cada semana.

Durante la ejecución se consulta un conjunto de datos y se envía al destino. Es un modelo simple y útil cuando la información no necesita actualizarse continuamente.

¿Qué es Change Data Capture?

CDC —Change Data Capture— busca identificar los cambios que ocurren en la fuente y trasladar esos cambios de manera incremental. En lugar de volver a procesar todo el conjunto, el sistema intenta mover únicamente lo nuevo o modificado.

Sachdeva (2026) describe CDC como una forma de mantener datos frescos frente a procesos batch tradicionales. Bonthu (2025) también utiliza CDC en un escenario de integración de múltiples ERP para mantener harmonización incremental.

1. La frecuencia debe partir del negocio

Preguntas útiles:

• ¿qué decisión utiliza este dato?
• ¿qué ocurre si llega mañana?
• ¿qué ocurre si llega una hora después?
• ¿qué ocurre si llega cinco minutos después?

No todos los escenarios requieren la misma latencia.

2. Batch puede ser suficiente

Una carga periódica puede funcionar bien para:

• cierres;
• reportes históricos;
• catálogos poco cambiantes;
• análisis no operativos;
• datos agregados.

En estos casos, aumentar frecuencia puede agregar complejidad sin generar valor.

3. CDC tiene sentido cuando los cambios importan rápido

Puede ser útil cuando:

• la información cambia constantemente;
• los consumidores necesitan alta frescura;
• procesar todo el dataset sería costoso;
• el destino necesita reaccionar ante cambios.

Pero mayor frescura también implica mayor exigencia de integración, monitoreo y recuperación.

4. Volumen y frecuencia deben analizarse juntos

Un objeto pequeño actualizado cada hora es diferente de millones de registros cambiando continuamente.

Conviene revisar:

• volumen inicial;
• tasa de cambio;
• ventana disponible;
• capacidad de origen;
• capacidad del destino.

5. CDC no elimina la necesidad de control

Una extracción incremental todavía puede:

• fallar;
• duplicar;
• perder un evento;
• procesar fuera de orden;
• romperse ante un cambio de esquema.

Por eso requiere controles de integridad y reconciliación.

6. Algunas arquitecturas combinan ambos

No siempre hay que elegir uno para todo.

Puede existir:

• carga inicial completa;
• posteriormente CDC;
• batch para algunos objetos;
• incremental para otros.

La arquitectura puede adaptarse al comportamiento del dato.

Comparación rápida

Criterio	Batch	CDC
Ejecución	Programada	Basada en cambios
Frescura	Depende de frecuencia	Generalmente mayor
Complejidad	Menor	Mayor
Procesamiento	Puede releer conjuntos amplios	Procesa cambios
Monitoreo	Necesario	Especialmente crítico
Uso típico	Analítica periódica	Datos que requieren actualización frecuente

Tiempo real no siempre es requisito

El término “real time” suele sonar atractivo. Pero antes de implementarlo hay que demostrar su necesidad.

Una latencia de 15 minutos puede ser suficiente para un caso y totalmente inaceptable para otro. La arquitectura debería reflejar esa diferencia.

¿Cómo elegir?

Para cada objeto define:

• frescura necesaria;
• volumen;
• frecuencia de cambio;
• consumidores;
• costo de retraso;
• capacidad técnica.

Después decide.

De estrategia de extracción a arquitectura de datos

La decisión batch vs. CDC no debería tomarse aislada. Forma parte del diseño general de extracción, transformación, almacenamiento, monitoreo y recuperación.

¿Necesitas llevar datos SAP hacia Cloud?

SAP2Cloud es una solución de Altamira Technology orientada a la extracción de datos desde SAP S/4HANA hacia entornos cloud. Antes de definir la frecuencia, conviene identificar qué información necesita realmente cada consumidor.

Referencias

Bonthu, C. (2025). Unifying multiple ERP systems: A case study on data migration and integration. Utilitas Mathematica, 122(2).

Sachdeva, S. (2026). The rise of the Lakehouse in SAP ecosystems: Transitioning from SAP BW/4HANA to a unified Databricks Lakehouse architecture. International Journal of Engineering Research & Technology, 15(2).