El Buen Fin y la plataforma de datos: qué tiene que aguantar

En México, el Buen Fin concentra en cuatro días un volumen que el resto del año no se ve. Y es exactamente el momento en que la plataforma de datos se cae, se ralentiza o entrega los números al día siguiente — cuando ya no sirven para decidir nada.

La lectura fácil es que “hay más datos”. La lectura correcta es más incómoda: el problema no es el volumen, es que todo pasa al mismo tiempo.

Los cuatro cuellos de botella reales

1. Todos consultan a la vez. El resto del año, dirección revisa el reporte en la mañana y los gerentes en la tarde. En temporada, todos quieren ver lo mismo al mismo tiempo, cada hora. En una arquitectura donde el cómputo es compartido, cada consulta compite con las demás y con los procesos de carga.

2. La ventana de proceso se cierra. Los procesos nocturnos están calculados para el volumen normal. Con tres o cuatro veces las transacciones, el proceso que terminaba a las 5 de la mañana ahora termina a las 9 — y a las 9 el reporte ya no importa.

3. La frecuencia que se necesita cambia. Un dato diario alcanza casi todo el año. En temporada, decisiones de reposición y de precio se toman durante el día. La necesidad de frescura sube justo cuando la plataforma está más cargada.

4. Aparecen fuentes que no estaban. Marketplaces, campañas específicas, pasarelas adicionales. Fuentes nuevas conectadas con prisa, sin las validaciones del resto — y es donde se rompen los totales.

Por qué separar cómputo y almacenamiento cambia el problema

Este es el argumento arquitectónico concreto, y no es teórico.

En una base de datos tradicional, cómputo y almacenamiento son la misma máquina. Escalar para el pico significa pagar todo el año por capacidad que usas cuatro días. Y no escalar significa que en el pico se degrada todo: los reportes compiten con las cargas y las cargas con la operación.

Cuando el cómputo está separado del almacenamiento —el modelo de Snowflake— cambian dos cosas:

• Cada carga de trabajo corre en su propio cómputo. El proceso de ingesta no compite con los tableros de dirección, y los tableros de dirección no compiten con los de tienda. El proceso pesado que antes bloqueaba a todos ya no bloquea a nadie.
• Escalas para el pico y regresas. Se dimensiona hacia arriba para la semana del Buen Fin y hacia abajo después, sin migrar nada.

El caso público de KFC Australia ilustra el punto de partida: en su base SQL anterior, el reporte de ventas por canal y por día nunca terminaba de ejecutarse. No era un problema de reportería — era de arquitectura. La lista completa de casos públicos con sus fuentes está en ese artículo.

Lo que sí hay que hacer antes, no durante

La arquitectura resuelve la capacidad. No resuelve la preparación. Cinco cosas, en orden:

1. Identifica qué decisiones se toman en horas. No todo necesita subir de frecuencia. Reposición y precio, sí. Rentabilidad por canal, no — depende de costos que se cierran por periodo. Subir la frecuencia de todo multiplica el costo sin habilitar una sola decisión nueva.

2. Prueba con el volumen del año pasado, no con el de hoy. Es la prueba más obvia y la que casi nadie corre. Si tu proceso tarda dos horas con el volumen de un martes de agosto, no sabes cuánto tarda con el de un sábado de Buen Fin. Multiplica y mide antes.

3. Congela cambios dos semanas antes. Ninguna fuente nueva, ningún cambio de modelo, ninguna migración durante la temporada. El pico no es el momento de descubrir que un conector nuevo trae los montos en otra moneda.

4. Define qué se degrada primero. Si algo tiene que ceder, decide antes qué: ¿el histórico se actualiza más lento y el día en curso se mantiene fresco? Tomar esa decisión bajo presión, a las 11 de la noche del sábado, es cómo se rompen los números.

5. Ten una cifra de control. Un total simple —venta del día— que se pueda comparar contra el punto de venta directamente. En temporada alta la pregunta “¿este número está bien?” aparece cada hora, y necesita una respuesta de dos minutos, no una investigación.

El error más común: escalar la infraestructura y no el modelo

Esto es lo que más vemos.

Se dimensiona el cómputo para el pico, se aumenta la frecuencia de carga, y el reporte sigue llegando tarde — porque el cuello de botella nunca estuvo en la máquina. Estaba en que el modelo recalcula todo el histórico cada vez que corre.

En temporada eso duele el triple. La solución es procesamiento incremental: calcular lo que cambió, no todo. Es el mismo principio que hace o rompe una integración de SAP, y por las mismas razones — lo tratamos en carga incremental de SAP a Snowflake.

Y hay un segundo error emparentado: creer que el problema es el tablero. Si el dato de ventas llega con retraso porque el punto de venta consolida por lote, ningún tablero lo arregla. La secuencia sigue siendo integrar primero, definir después, visualizar al final.

El indicador que dice si estuviste listo

No es el tiempo de respuesta del tablero. Es esta pregunta, hecha el lunes después:

¿Alguien tomó una decisión durante el fin de semana con datos, o todas las decisiones se tomaron con intuición y los datos solo sirvieron para explicar después?

Si la respuesta es la segunda, la plataforma funcionó como sistema de registro, no como sistema de decisión. Y en los cuatro días donde más se decide, esa diferencia es la única que importa.

---

En EGOS BI preparamos plataformas de retail para temporada alta: dimensionamiento sobre Snowflake, ingesta con Fivetran y analítica con Tableau u Omni al nivel de quien decide. Si el Buen Fin pasado te dejó sin números a tiempo, agenda un diagnóstico — o revisa cómo trabajamos con datos en retail.