Ir al contenido principal
Soluciones

Escalado para MHHS: cómo Octopus Energy logró una reducción de costos 50 veces mayor en la ingeniería de datos de margen

Cómo un equipo de tres ingenieros re-arquitectó las canalizaciones de datos de Octopus Energy para manejar un aumento de volumen de datos de 48x, y redujo los costos 50 veces en el proceso.

por Saad Ali, David Poulet, Daniel Taylor y Ismail Makhlouf

  • Qué es: Cómo Octopus Energy re-arquitectó sus canalizaciones de datos de margen en Databricks para cumplir con la regulación MHHS del Reino Unido.
  • El desafío: MHHS multiplica el volumen de datos por 48 (dos lecturas de medidor por hogar al mes → 48 al día), lo que se proyecta que agregará ~$1M/año a los costos de las canalizaciones bajo la arquitectura de grano único existente.
  • El resultado: Tres ingenieros reconstruyeron las canalizaciones en tres meses, reduciendo el costo por fecha de liquidación de $23.63 a $0.48 — 50 veces más barato que la proyección de MHHS y 2 veces más barato que el sistema heredado a pesar de 48 veces más datos. Delta Lake Change Data Feed impulsó una reducción del 98.8% en las filas procesadas (25B → 300M) y elevó la frescura de semanal a diaria; Databricks Serverless permitió la ventana de iteración rápida.

La transición energética tiene un problema de datos

La red energética del Reino Unido se encuentra en medio de su transformación estructural más importante en décadas. A medida que las energías renovables como la eólica y la solar ganan una mayor cuota en la generación de electricidad, la intermitencia se convierte en un problema de primer orden: la energía es barata cuando brilla el sol y cara cuando no lo hace.

El modelo de liquidación existente, basado en lecturas mensuales de contadores y perfiles de consumo promediados, no puede valorar esa señal con precisión. Y si no puedes valorarla con precisión, no puedes transmitir la señal a los consumidores, y la demanda nunca cambia para igualar la oferta.

La liquidación semihoraria en todo el mercado (MHHS) es la respuesta regulatoria. Cada hogar en Gran Bretaña pasa de dos lecturas de contador al mes a 48 lecturas al día. Eso no es un cambio incremental. Para un proveedor como Octopus Energy, que atiende a más de 8 millones de clientes, es un aumento de 48 veces en los puntos de datos que impulsan cada cálculo de margen, cada obligación de liquidación y cada decisión comercial.

La implicación para la ingeniería de datos es directa: sin una rearquitectura, el coste de la infraestructura para ejecutar los pipelines de margen de Octopus Energy se proyectaba que se dispararía en 1 millón de dólares al año.

Por qué lanzar cómputo a esto no funciona

El instinto cuando los volúmenes de datos aumentan 48 veces es aprovisionar más infraestructura. Para el equipo de datos de margen de Octopus Energy, ese instinto se validó rápidamente como insostenible. El coste proyectado por fecha de liquidación bajo la arquitectura heredada era de 23,63 dólares, un aumento de 33 veces respecto a las normas históricas. Multiplíquelo por las ventanas de liquidación y la factura se acumula rápidamente.

Sin embargo, el problema más profundo no era el coste de cómputo, sino la desalineación de la arquitectura. El pipeline heredado se había construido en torno a un único grano: el mensual. La facturación se ejecutaba mensualmente. La liquidación se ejecutaba mensualmente. Todo el pipeline era monolítico por diseño.

MHHS introdujo una división fundamental. Los datos de costes de la industria ahora llegan con granularidad semihoraria: 48 puntos de datos por cliente al día. Los clientes con tarifas inteligentes con vehículos eléctricos y bombas de calor necesitan cálculos de ingresos semihorarios. Los clientes con tarifas estándar todavía se liquidan mensualmente. Ejecutar los tres a través de un único pipeline monolítico significaba procesar todo el conjunto de datos en cada ejecución, independientemente de lo que realmente hubiera cambiado.

Como lo expresó Saad Ali, líder del equipo de datos de margen en Octopus Energy: "No puedes simplemente lanzar más cómputo a un problema como este. Tienes que reconstruir y repensar tu lógica desde cero".

La arquitectura: tres flujos, una única fuente de verdad

El equipo rearquitecturó en torno a tres flujos especializados, cada uno optimizado de forma independiente para su grano natural:

Liquidación: Granularidad semihoraria para la liquidación regulatoria y la asignación de costes. Los cargos de la industria a 48 puntos de datos por día; este flujo coincide exactamente con ese grano.

Semihorario: Procesamiento semihorario para clientes con tarifas inteligentes: conductores de vehículos eléctricos, usuarios de bombas de calor y productos de tiempo de uso donde la señal de precio semihoraria es toda la propuesta comercial.

Mensual: Procesamiento mensual para clientes con tarifas estándar, sin cambios en el grano, pero ahora conciliable con los datos semihorarios.

Un patrón de orquestación "Job of Jobs" gestiona las dependencias y la ejecución paralela en los tres flujos. Cada flujo es sintonizable de forma independiente: lo que funciona como una optimización de Spark para la liquidación no es necesariamente adecuado para NHH.

Subyacente a los tres está la capa de consumo descendente: una fuente de verdad unificada y multigrano que consolida las lecturas de contadores, los datos de contadores inteligentes y los flujos de la industria a escala de varios terabytes. Esta capa es el puente de conciliación entre la facturación mensual y la liquidación semihoraria, y se convirtió en el sitio de la optimización de mayor apalancamiento del proyecto.

Procesamiento incremental: 98,8% menos filas

El enfoque ingenuo de las tablas de consumo ascendentes, reprocesar todo el conjunto de datos de varios terabytes en cada ejecución, habría significado costes de cómputo insostenibles con el nuevo volumen.

El Delta Lake's Change Data Feed (CDF) hizo viable el procesamiento incremental real a este grano. En lugar de sobrescrituras completas, el pipeline ahora lee solo los registros que han cambiado realmente desde la última ejecución. El resultado: las filas procesadas por ejecución cayeron de 25 mil millones a 300 millones, una reducción del 98,8%.

La frescura de los datos mejoró de semanal a diaria. Para el equipo comercial, ese cambio significa visibilidad del margen en el grano en el que realmente se toman las decisiones de precios: cada mañana, no una vez a la semana.

Nota: los 1 millón de dólares en ahorros anualizados citados a continuación excluyen los ahorros adicionales de este paso al procesamiento incremental en las tablas ascendentes. La ganancia de eficiencia total es mayor.

Optimización de Spark y Delta: y qué eliminar

Con 48 veces más datos fluyendo a través del sistema, el equipo aplicó optimizaciones específicas validadas por mediciones en cuatro categorías:

Reducción de linaje y E/S

  • Linaje simplificado al consolidar datos al principio del pipeline, reduciendo las uniones descendentes y las operaciones de mezcla (shuffle)
  • Poda de datos: se seleccionaron solo las columnas estrictamente necesarias para la liquidación y se podaron filas en la etapa más temprana posible, reduciendo la sobrecarga de E/S antes de transformaciones costosas

Ajuste de uniones y particiones

  • Uniones de difusión (broadcast joins) para tablas de referencia de menos de 500 MB, eliminando operaciones de mezcla costosas en uniones multillave complejas con rangos de fechas
  • Se habilitó la agrupación líquida (Liquid clustering) en varias tablas para columnas utilizadas frecuentemente en filtros y uniones. La agrupación líquida coordina dinámicamente registros relacionados en las claves de agrupación especificadas sin requerir límites de partición fijos. La agrupación líquida evita el problema de los archivos pequeños, el mayor consumo de memoria y la sobrecarga de E/S que provienen de la sobrepartición.

Confiar en el optimizador

  • En varios casos, la Ejecución Adaptativa de Consultas (AQE) de Spark superó la lógica ajustada manualmente. El equipo eliminó el código de optimización personalizado y dejó que AQE hiciera su trabajo.

Este último punto merece énfasis: eliminar operaciones de cómputo injustificadas fue tan impactante como agregar nuevas optimizaciones. Si está ejecutando Z-ordering o ANALYZE sin medir su efecto, pueden costarle más de lo que ahorran.

Serverless como acelerador de desarrollo

Databricks Serverless hizo viable la ventana de entrega de tres meses. El tiempo de inicio cero del clúster significó que el equipo pudo iterar rápidamente: escribir, ejecutar, medir, ajustar, sin esperar a que se aprovisionara la infraestructura.

La interfaz de usuario de Serverless permitió comparaciones de ejecución lado a lado, haciendo práctico aislar el efecto de optimizaciones individuales.

En palabras del propio equipo: "El proceso de prueba y desarrollo no podría haberse realizado sin serverless. Usar la interfaz de usuario de serverless nos ayudó a identificar cuellos de botella y hacer comparaciones fáciles entre diferentes ejecuciones".

Resultados

MétricaAntesDespuésCambio
Filas procesadas por ejecución25 mil millones300 millonesReducción del 98,8%
Coste por fecha de liquidación (MHHS proyectado)23,63 $0,48 $Reducción de ~50x
Coste por fecha de liquidación (vs heredado)0,71 $0,48 $2 veces más eficiente
Ahorros por ejecución de fin de mes-~83.000 $vs proyección no optimizada
Evitación de costes anualizada-~1.000.000 $excluye ahorros ascendentes
Frescura de los datosSemanalDiariaMejora de 7x
Tiempo de compilación-3 mesesEquipo de tres

Los 0,48 dólares por fecha de liquidación no son solo una reducción de 50 veces respecto al coste proyectado de MHHS, sino que son 2 veces más baratos que el sistema heredado, a pesar de procesar 48 veces más puntos de datos. La rearquitectura proporcionó el cumplimiento normativo y hizo que el sistema fuera materialmente más eficiente que el que reemplazó.

Lo que esto significa más allá de la energía

MHHS es una regulación energética del Reino Unido. Sin embargo, el patrón que representa -un evento regulatorio o comercial que multiplica el volumen de datos en un grano más fino- no es exclusivo de la energía. Cada vez que un sistema pasa de mensual a diario, de diario a tiempo real, o de agregado a transaccional, se aplican las mismas dinámicas.

Cuatro conclusiones transferibles de la experiencia de Octopus Energy:

  1. La desalineación del grano es el impulsor oculto de costes. Cuando un pipeline procesa todo en el grano más fino, independientemente de la necesidad del negocio, lo paga en cómputo, frescura y complejidad de mantenimiento. Identifique los granos naturales en sus datos y alinee el procesamiento con ellos.
  2. El procesamiento incremental transforma la economía de los pipelines. La reducción del 98,8% de las filas provino de la lógica incremental basada en CDF, no del ajuste de Spark. Empiece por ahí, y recuerde que los ahorros completos son mayores que la cifra principal.
  3. Elimine antes de añadir. Audite las opciones de optimización existentes antes de asumir que necesita más cómputo. El Z-ordering, ANALYZE y la lógica de mezcla personalizada aplicados sin medición pueden costarle más de lo que ahorran.
  4. Confía en el optimizador. AQE superó la lógica codificada a mano en varios casos. Antes de escribir optimizaciones personalizadas, comprueba si Spark ya maneja tu caso.

El panorama general

En palabras de Saad: "Al hacer nuestros sistemas más rápidos y eficientes, podemos ofrecer tarifas más inteligentes que ayuden a nuestros clientes a usar la energía cuando es más barata y limpia".

La reducción de la base de costos hace algo específico: elimina la barrera económica para el procesamiento de datos de alta frecuencia. Eso hace que el balanceo de la red sea viable como producto. Eso hace que las tarifas inteligentes sean comercialmente sostenibles. Así es como la ingeniería de datos a escala se conecta con la transición energética, no como un gasto de infraestructura, sino como la base comercial para ella.

El cumplimiento de MHHS fue el mandato. Hacer de la energía sostenible la opción asequible es la misión. La ingeniería de datos es lo que conecta ambas.

Profundiza

———

Saad Ali es el líder del equipo de datos de margen en Octopus Energy. Ismail Makhlouf, David Poulet y Daniel Taylor son arquitectos de soluciones en Databricks.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original

Recibe las últimas publicaciones en tu bandeja de entrada

Suscríbete a nuestro blog y recibe las últimas publicaciones directamente en tu bandeja de entrada.