Carga incremental de SAP a Snowflake: cómo sincronizar sin recargar todo

La carga completa de SAP funciona perfectamente en la prueba de concepto, con tres meses de datos y una tabla. Deja de funcionar cuando entra el histórico completo: la ventana nocturna se desborda, el consumo de cómputo en Snowflake se dispara y el sistema SAP transaccional empieza a sentir la carga de la extracción.

Ese es el momento en que estos proyectos se atascan, y es la parte que casi nunca se presupuesta bien. Esto es cómo se resuelve.

Por qué la recarga completa no escala

Tres costos que crecen juntos y que no se ven en el piloto:

Ventana de proceso. Si extraer un año de partidas contables toma 40 minutos, extraer ocho años toma horas. Y la ventana nocturna no crece.

Cómputo en Snowflake. Pagas cómputo por lo que procesas. Recargar todo lo que no cambió es pagar todas las noches por reescribir datos idénticos. Es el costo que aparece en la factura del tercer mes y sorprende a todos.

Carga sobre SAP. La extracción compite con la operación transaccional. Un proceso pesado sobre tablas grandes puede degradar el desempeño del sistema que la empresa usa para facturar — y eso escala rápido a una conversación incómoda con el equipo de SAP.

La señal de que llegaste al límite: cuando alguien propone “extraer solo los últimos dos años” para que quepa en la ventana. Eso no es una optimización, es empezar a perder datos.

SAP no tiene un solo mecanismo de delta

Aquí está la complicación de fondo, y es específica de SAP: la forma de saber qué cambió depende del objeto, no hay un método universal.

Los mecanismos disponibles, de más a menos confiable:

1. DeltaQ — los DataSources de SAP. SAP tiene extractores propios diseñados para entrega incremental, los mismos que alimentan BW. Cuando existe un extractor estándar para tu objeto de negocio, es el camino más sólido: el delta lo gestiona SAP, incluyendo el registro de qué ya se entregó.

2. ODP — aprovisionamiento operacional de datos. El mecanismo moderno, y el camino natural en S/4HANA. Cubre vistas CDS y objetos de BW/4HANA, con delta gestionado del lado de SAP.

3. Table CDC — captura de cambios a nivel de tabla. Trae solo lo modificado desde la última carga a nivel de tabla, sin depender de que exista un extractor estándar. Es lo que hace viable la sincronización frecuente sobre tablas que no tienen otro mecanismo.

4. Marca de agua por campo de fecha. El enfoque manual: guardar la última fecha y hora procesada y traer lo posterior. Funciona si la tabla tiene un campo de modificación confiable — y muchas no lo tienen.

El problema de los borrados

Este es el que produce las discrepancias que nadie puede explicar, y merece su propia sección porque casi nunca se contempla al inicio.

Un registro eliminado no aparece en un filtro por fecha. Si tu delta pregunta “dame todo lo modificado después de ayer”, un registro que se borró simplemente no está en la respuesta — y por lo tanto se queda para siempre en Snowflake, aunque en SAP ya no exista.

Con el tiempo eso produce el síntoma clásico: Snowflake tiene más registros que SAP y nadie sabe por qué. Y cuando finanzas compara un total contra el sistema origen, no cuadra.

Cómo se maneja:

• Los mecanismos nativos de SAP —DeltaQ, ODP— sí marcan los borrados como parte del delta. Es una razón fuerte para preferirlos.
• Muchos procesos de SAP no borran físicamente, marcan un indicador de anulación o de borrado. En ese caso el registro sí llega en el delta con la marca puesta, y el trabajo es respetarla en el modelado.
• Reconciliación periódica. Una carga completa mensual o una comparación de conteos por periodo que detecte la deriva antes de que alguien la descubra en una junta.

Ese último punto es una recomendación práctica: delta diario, reconciliación periódica. No es redundancia, es el mecanismo que te avisa cuando el delta se desvió.

El patrón de arquitectura que usamos

Independientemente del mecanismo, la forma de estructurarlo en Snowflake:

1. Esquema de aterrizaje, crudo. Los datos llegan tal como salieron de SAP, sin transformar, con una marca de cuándo se cargaron. Cuando aparezca una discrepancia, puedes comparar contra el origen sin volver a extraer.

2. Aplicar los cambios en una capa intermedia. Ahí se resuelven las inserciones, actualizaciones y borrados contra la tabla acumulada. Es donde se decide si conservas historia o solo el estado actual.

3. Modelo de negocio encima. Las métricas y dimensiones que el negocio consume, con una sola definición por indicador.

4. Cada capa reconstruible desde la anterior. Si cambia una regla de negocio, rehaces desde la intermedia sin volver a tocar SAP.

Y una decisión que conviene tomar explícitamente al inicio: ¿necesitas historia o solo el estado actual? Si el negocio va a preguntar “cómo estaba este pedido en marzo”, necesitas conservar versiones, y eso cambia el diseño. Descubrirlo después implica rehacer.

Cuánta frescura necesitas realmente

Antes de perseguir tiempo real, conviene una pregunta incómoda: ¿qué decisión cambia si el dato llega en 15 minutos en lugar de mañana?

Casi siempre la respuesta honesta es ninguna. Y hay una razón estructural para eso en SAP: muchos procesos de negocio cierran por lote. Si la contabilidad se cierra en la madrugada, tener las partidas actualizadas cada 15 minutos no adelanta nada — el dato no está completo antes.

En la práctica:

Frescura	Cuándo se justifica
Diaria	La mayoría de la analítica de negocio: ventas, finanzas, inventario para decisiones de planeación
Varias veces al día	Inventario en operaciones con rotación alta, seguimiento comercial intradía
Casi en tiempo real	Casos operativos específicos donde se actúa en minutos

Perseguir tiempo real donde no se necesita infla el costo de cómputo y la complejidad operativa sin cambiar ninguna decisión.

Los tres errores más caros

1. Dejar el delta para después. Arrancar con carga completa “por ahora” y planear el delta como fase dos. El problema es que la fase dos llega cuando ya hay usuarios dependiendo de la plataforma, así que se hace bajo presión y sin ventana para probar.

2. Construir la lógica delta a mano. Es donde se va la mayor parte del mantenimiento a largo plazo, y donde aparecen las discrepancias silenciosas. Si la herramienta lo resuelve, úsala.

3. No reconciliar nunca. El delta se desvía. Sin una comparación periódica contra el origen, la primera persona que lo detecta es alguien de finanzas en una junta de dirección — y ahí ya perdiste la confianza en la plataforma, que cuesta mucho más recuperar que arreglar el proceso.

En resumen

La carga incremental no es una optimización que se agrega después: es un requisito de diseño desde el inicio si tus volúmenes son reales.

El orden de preferencia es claro: usa los mecanismos delta nativos de SAP cuando existan (DeltaQ, ODP), captura de cambios a nivel de tabla cuando no, y deja la marca de agua manual como último recurso. Y en todos los casos, reconcilia periódicamente.

Los tipos de extracción disponibles y cuál aplica a cada objeto están en cómo funciona Xtract Universal, y el contexto de por qué SAP complica esto más que otras fuentes en por qué extraer datos de SAP es difícil.

---

En EGOS BI diseñamos estas cargas con Theobald hacia Snowflake, incluyendo la reconciliación que evita las discrepancias silenciosas. Si tu carga nocturna ya no cabe en la ventana, platiquemos.

Fuente: Theobald Software — Xtract Universal