De 2 horas a 9 minutos: rehacer un proceso de datos empresarial

Este trabajo es anterior a Datasmarts. Es experiencia del fundador en un proyecto empresarial previo, entregada como ingeniero de software senior dentro de un equipo interno, no un proyecto con un cliente de Datasmarts. Aparece aquí porque es el ejemplo más claro del tipo de trabajo de bases de datos que Datasmarts sigue tomando, y está escrito en primera persona porque la capa de base de datos fue mi aporte propio dentro de un esfuerzo de equipo más grande.

El reto

Un proceso de datos crítico tardaba dos horas en correr, para un cliente cuyo negocio se medía en miles de millones. Dos horas no es apenas lento. Fija el piso de cada cuánto puede correr el proceso, lo que a su vez fija el piso de qué tan fresca puede llegar a ser la información que depende de él, y convierte cualquier falla en un reintento de dos horas.

El enfoque

Fui por la capa de consulta y no por el modelo de datos. En un sistema que ya está en producción a esa escala, cambiar el esquema significa coordinar una migración con todo lo que depende de él, y el costo de esa coordinación suele ser mayor que el costo del proceso lento. La capa de consulta, en cambio, se puede reescribir y validar contra los datos existentes sin ningún cambio de contrato aguas abajo.

Esa restricción es lo que volvió abordable el trabajo: la ganancia tenía que salir de cómo se le pedían los datos a la base, no de cómo estaban guardados.

La solución

Rehice las consultas SQL complejas que estaban en el corazón del proceso, optimizando la capa de base de datos en su lugar. El proceso conservó las mismas entradas, las mismas salidas y el mismo esquema. Lo que cambió fue el trabajo que la base de datos tenía que hacer para producirlas.

Resultados

El proceso de datos crítico pasó de 2 horas a 9 minutos. Los mismos datos, el mismo resultado, el mismo esquema, y un tiempo de ejecución que dejó de dictar cómo se programaba el resto del sistema.

Qué lo hizo difícil

Las restricciones eran la dificultad. Era un sistema en producción para un cliente de varios miles de millones de dólares, así que el proceso no se podía bajar para experimentar, y el modelo de datos no se podía mover. Cada mejora tenía que ser demostrablemente equivalente a lo que reemplazaba, porque un proceso más rápido que devuelve una respuesta un poco distinta no es una mejora, es un defecto con mejores números de rendimiento.

Una cosa que no voy a hacer aquí es reconstruir el diagnóstico. Mis notas de la época registran la restricción, el trabajo y el resultado, no la secuencia de hipótesis que me llevó hasta allá, y una reconstrucción que suene plausible sería ficción. Los hechos medidos son los dos tiempos de ejecución.