Caso de uso — Retail con modernización analytics vía Connect CDC

Contexto

Industria: cadena de retail con ~400 puntos de venta físicos + e-commerce. Plataforma central: IBM Power S1024 con IBM i 7.5 TR3. Core de gestión de inventario, ventas, clientes y proveedores en RPG + DB2 for i, ~5 TB. Plataforma analytics: Snowflake corporativo; equipo de data engineering nuevo, sin experiencia en IBM i. Volumen: ~200.000 transacciones/día, picos de 50/seg en horas pico.

Situación inicial

El equipo de data engineering quiere construir un data warehouse moderno en Snowflake. Hoy hacen un dump nocturno desde IBM i:

•Tarda 5 horas.
•Choca con la ventana de backup.
•Se rompe ~2 veces por mes.
•Datos llegan al dashboard con latencia de 24 horas — el negocio quiere insights intraday.

El CDO (Chief Data Officer) pide soluciones. La conversación con preventa empieza así: "¿Cómo metemos los datos del IBM i en Snowflake en tiempo real sin que mi equipo tenga que aprender RPG?".

Discovery

Preguntas aplicadas

(Ver Connect CDC — Para Comercial.)

| Pregunta | Respuesta | |---|---| | ¿Qué fuentes prioritarias? | IBM i (core), MySQL (e-commerce), Salesforce (CRM). Hoy sólo se carga IBM i. | | ¿Qué destino tienen operativo? | Snowflake con varias bases corporativas. Quieren consolidar todo ahí. | | ¿Qué herramientas usan? | Hoy un script SQL + sftp + Snowpipe nocturno. Frágil. | | ¿Qué herramientas evaluaron? | Algunos ETL (Talend, Informatica), nada CDC todavía. | | ¿Quieren near-real-time? | Sí, idealmente latencia < 5 minutos para reporting intraday. | | ¿IBM i es la fuente "difícil"? | "Nadie en mi equipo entiende qué es DSPFFD". | | ¿Tienen iniciativa de data lake? | Snowflake hace de lake + warehouse para ellos. |

Datos técnicos relevados

•IBM i 7.5 TR3, sin Connect CDC instalado.
•50 tablas core en scope (de ~800 totales). El 80% del valor analítico está en ese 20%.
•Estado de journaling: las 50 tablas core están journaled, pero con imagen *AFTER solamente. Connect CDC requiere *AFTER o *BOTH. ✓ OK.
•Volumen estimado de cambios: 2 GB/día de receivers en horas pico.
•Snowflake account corporativa con database/schema preparados.
•Network: salida a internet vía proxy corporativo, latencia a Snowflake ~50 ms.

Solución propuesta

Arquitectura

[IBM i — core retail]
    journals DB2 for i (*AFTER)
        ↓
    Agente Connect CDC en IBM i
        ↓
    IBM i Data Queues
        ↓
    Motor Connect (Linux VM en sitio principal)
        ↓
    [Snowflake corporativo — base RETAIL_LAKE]

(Fuente arquitectura: Precisely Help — Connect CDC IBM i Installation Guide)

Productos en scope

•Connect CDC (Precisely): agente IBM i + motor.
•Existing: Snowflake account, IBM i 7.5 con journaling activo.

Diseño de pipelines

•
50 tablas en scope, agrupadas en 5 subscriptions por dominio:
1. •Ventas.
2. •Inventario.
3. •Clientes.
4. •Proveedores.
5. •Maestros.
•Mapping simple columna a columna; conversión de packed decimal y EBCDIC a tipos Snowflake estándar.
•Soft-delete: en Snowflake los deletes se marcan, no se borran (caso típico de analytics).
•Schema evolution semiautomático: nuevas columnas se agregan a Snowflake con script generado por el motor; cambios de tipo requieren ventana coordinada.

Sizing

•Motor Connect: VM Linux con 8 cores, 32 GB RAM, 200 GB disco. Headroom para crecimiento.
•Throughput sostenido objetivo: 1.000 cambios/seg. Picos de 5.000.
•Latencia end-to-end objetivo: < 5 minutos desde commit en IBM i hasta dato visible en Snowflake.

Plan de implementación (alto nivel)

•
Fase 0 — Validación de prerequisitos (1 semana)
- •Confirmar journaling con imagen *AFTER en las 50 tablas.
- •Setup del motor.
•
Fase 1 — Pipeline piloto (3 semanas)
- •Una subscription (Ventas) end-to-end.
- •Carga inicial.
- •CDC operando.
- •Validaciones de count y hash con el equipo de data.
•
Fase 2 — Roll-out de las 5 subscriptions (4 semanas)
- •Una subscription nueva por semana.
- •Cada una con su validación.
•
Fase 3 — Cutover del proceso nocturno (2 semanas)
- •Dashboards apuntan a Snowflake actualizado en tiempo real.
- •Apagado del proceso nocturno legacy.
•
Fase 4 — Operación + capacitación (2 semanas)
- •Capacitación del equipo de data en troubleshooting básico (track L1 acotado).
- •Runbook para soporte.

Tiempo total estimado: 12 semanas.

Riesgos y mitigaciones

| Riesgo | Mitigación | |---|---| | Equipo del cliente sin experiencia IBM i | Capacitación específica + runbook de incidentes típicos | | Schema evolution mal coordinada | Proceso formal con ventana acordada | | Picos de carga > 5.000/seg sostenidos | Sizing del motor con margen + paralelismo en subscriptions | | Cambios de credenciales Snowflake sin aviso | Vault corporativo + rotación coordinada | | EBCDIC mal traducido | Validación end-to-end con muestreo en piloto |

Resultado al cierre del proyecto

•Latencia medida end-to-end: promedio 90 segundos, p99 < 5 minutos.
•Proceso nocturno legacy apagado.
•Dashboards intraday operativos para gerencia comercial.
•Equipo de data autónomo en operación normal; soporte solo para cambios de schema.

Lecciones para preventa

•El discurso es de modernización, no de IBM i. El cliente no quiere "comprar Connect CDC", quiere "modernizar analytics".
•El obstáculo más común es journaling con imagen incompleta — la pregunta debe estar en el discovery.
•Cuidado con prometer "todas las tablas": priorizar el 20/80 en el piloto. Demostrar valor rápido.
•Schema evolution es donde se pierden los proyectos. Vender el proceso, no solo el producto.
•La capacitación al equipo del cliente es entregable: ellos van a operar, no nosotros para siempre.

Productos relacionados

•Connect CDC — central.
•Quick EDD — eventual: si el cliente quiere agregar HA después.
•Flash For i — eventual: si la ventana de backup nocturna sigue creciendo.