Escalando para MHHS: como a Octopus Energy alcançou uma redução de 50x nos custos de engenharia de dados de margem

A transição energética tem um problema de dados

A rede de energia do Reino Unido está no meio de sua transformação estrutural mais significativa em décadas. À medida que as energias renováveis, como eólica e solar, ganham uma participação maior na geração de eletricidade, a intermitência se torna um problema de primeira classe: a energia é barata quando o sol brilha e cara quando não brilha.

O modelo de liquidação existente - construído com base em leituras mensais de medidores e perfis de consumo médios - não consegue precificar esse sinal com precisão. E se você não consegue precificá-lo com precisão, não consegue repassar o sinal aos consumidores, e a demanda nunca muda para corresponder à oferta.

A Liquidação Meia-Horária em toda a rede (MHHS - Market-wide Half-Hourly Settlement) é a resposta regulatória. Cada residência na Grã-Bretanha passa de duas leituras de medidor por mês para 48 leituras por dia. Isso não é uma mudança incremental. Para um fornecedor como a Octopus Energy, que atende a mais de 8 milhões de clientes, é um aumento de 48 vezes nos pontos de dados que impulsionam cada cálculo de margem, cada obrigação de liquidação e cada decisão comercial.

A implicação de engenharia de dados é direta: sem re-arquitetura, o custo da infraestrutura para executar os pipelines de margem da Octopus Energy foi projetado para disparar em US$ 1 milhão todos os anos.

Por que simplesmente aumentar a capacidade de processamento não funciona

O instinto quando os volumes de dados aumentam 48 vezes é provisionar mais infraestrutura. Para a equipe de dados de margem da Octopus Energy, esse instinto foi rapidamente validado como insustentável. O custo projetado por data de liquidação sob a arquitetura legada era de US$ 23,63 - um aumento de 33 vezes em relação às normas históricas. Multiplique isso pelas janelas de liquidação, e a conta se acumula rapidamente.

No entanto, o problema mais profundo não era o custo de processamento - era a incompatibilidade da arquitetura. O pipeline legado foi construído em torno de um único grão: mensal. A faturação era mensal. A liquidação era mensal. Todo o pipeline era monolítico por design.

O MHHS introduziu uma divisão fundamental. Os dados de custo da indústria agora chegam com granularidade de meia hora - 48 pontos de dados por cliente por dia. Clientes com tarifas inteligentes, com veículos elétricos e bombas de calor, precisam de cálculos de receita de meia hora. Clientes com tarifas padrão ainda liquidam mensalmente. Executar os três através de um único pipeline monolítico significava processar todo o conjunto de dados em cada execução, independentemente do que realmente havia mudado.

Como Saad Ali, Líder da Equipe de Dados de Margem na Octopus Energy, resumiu: "Você não pode simplesmente jogar mais capacidade de processamento em um problema como este. Você tem que reconstruir e repensar sua lógica do zero."

A arquitetura: três fluxos, uma única fonte de verdade

A equipe re-arquitetou em torno de três fluxos especializados, cada um otimizado independentemente para seu grão natural:

Liquidação - Granularidade de meia hora para liquidação regulatória e alocação de custos. Encargos da indústria em 48 pontos de dados por dia; este fluxo corresponde exatamente a esse grão.

Meia-Hora - Processamento de meia hora para clientes com tarifas inteligentes: motoristas de veículos elétricos, usuários de bombas de calor e produtos de uso do tempo, onde o sinal de preço de meia hora é toda a proposta comercial.

Mensal - Processamento mensal para clientes com tarifas padrão, inalterado em grão, mas agora reconciliável com os dados de meia hora.

Um padrão de orquestração "Job of Jobs" gerencia dependências e execução paralela em todos os três fluxos. Cada fluxo é ajustável independentemente - o que funciona como uma otimização do Spark para Liquidação não é necessariamente certo para NHH.

Sustentando todos os três está a camada de consumo downstream: uma fonte de verdade unificada e multi-grão que consolida leituras de medidores, dados de medidores inteligentes e fluxos da indústria em escala de vários terabytes. Esta camada é a ponte de reconciliação entre a faturação mensal e a liquidação de meia hora - e tornou-se o local da otimização de maior alavancagem única no projeto.

Processamento incremental: 98,8% menos linhas

A abordagem ingênua para as tabelas de consumo upstream - reprocessando todo o conjunto de dados de vários terabytes a cada execução - teria significado custos de processamento insustentáveis no novo volume.

O Change Data Feed (CDF) do Delta Lake tornou o processamento incremental real viável nesse grão. Em vez de sobrescritas completas, o pipeline agora lê apenas os registros que realmente mudaram desde a última execução. O resultado: linhas processadas por execução caíram de 25 bilhões para 300 milhões - uma redução de 98,8%.

A atualidade dos dados melhorou de semanal para diária. Para a equipe comercial, essa mudança significa visibilidade da margem no grão em que as decisões de precificação são realmente tomadas - todas as manhãs, não uma vez por semana.

Nota: os valores de economia anualizada de US$ 1 milhão citados abaixo excluem as economias adicionais desta mudança para processamento incremental em tabelas upstream. O ganho total de eficiência é maior.

Otimização de Spark & Delta - e o que remover

Com 48 vezes mais dados fluindo pelo sistema, a equipe aplicou otimizações direcionadas validadas por medição em quatro categorias:

Redução de linhagem e I/O

• Simplificou a linhagem consolidando dados no início do pipeline, reduzindo junções downstream e operações de shuffle
• Poda de dados: selecionou apenas as colunas estritamente necessárias para a liquidação e podou linhas no estágio mais inicial possível, reduzindo a sobrecarga de I/O antes de transformações caras

Ajuste de junção e partição

• Junções de broadcast para tabelas de referência com menos de 500 MB, eliminando operações de shuffle caras em junções complexas de chaves múltiplas com intervalos de datas
• O cluster líquido foi ativado em várias tabelas para colunas frequentemente usadas em filtros e junções. O cluster líquido co-localiza dinamicamente registros relacionados nas chaves de cluster especificadas sem exigir limites de partição fixos. O cluster líquido evita o problema de arquivos pequenos, o maior consumo de memória e a sobrecarga de I/O que vêm do particionamento excessivo.

Confiança no otimizador

• Em vários casos, a Execução Adaptativa de Consultas (AQE - Adaptive Query Execution) do Spark superou a lógica ajustada manualmente. A equipe removeu o código de otimização personalizado e deixou a AQE fazer seu trabalho.

Este último ponto merece ênfase: remover operações de computação injustificadas foi tão impactante quanto adicionar novas otimizações. Se você está executando Z-ordering ou ANALYZE sem medir seu efeito, eles podem estar custando mais do que economizando.

Serverless como acelerador de desenvolvimento

O Databricks Serverless tornou a janela de entrega de três meses viável. O tempo zero de inicialização de cluster significou que a equipe pôde iterar rapidamente - escrever, executar, medir, ajustar - sem esperar que a infraestrutura fosse provisionada.

A interface do usuário do Serverless permitiu comparações lado a lado de execuções, tornando prático isolar o efeito de otimizações individuais.

Nas palavras da própria equipe: "O processo de teste e desenvolvimento não poderia ter sido feito sem o serverless. Usar a interface do usuário do serverless nos ajudou a identificar gargalos e fazer comparações fáceis entre diferentes execuções."

Resultados

Os US$ 0,48 por data de liquidação não são apenas uma redução de 50x do custo projetado do MHHS - são 2x mais baratos do que o sistema legado jamais foi, apesar de processar 48 vezes mais pontos de dados. A re-arquitetura entregou conformidade regulatória e tornou o sistema materialmente mais eficiente do que aquele que substituiu.

O que isso significa além da energia

O MHHS é uma regulamentação do setor de energia do Reino Unido. No entanto, o padrão que ele representa - um evento regulatório ou de negócios que multiplica o volume de dados em um grão mais fino - não é exclusivo do setor de energia. Sempre que um sistema passa de mensal para diário, de diário para em tempo real, ou de agregado para transacional, as mesmas dinâmicas se aplicam.

Quatro lições transferíveis da experiência da Octopus Energy:

1. O desalinhamento de grão é o impulsionador oculto de custos. Quando um pipeline processa tudo no grão mais fino, independentemente da necessidade de negócios, você paga por isso em capacidade de processamento, atualidade e complexidade de manutenção. Identifique os grãos naturais em seus dados e alinhe o processamento a eles.
2. O processamento incremental transforma a economia do pipeline. A redução de 98,8% nas linhas veio da lógica incremental baseada em CDF, não do ajuste do Spark. Comece por aí - e lembre-se que as economias totais são maiores do que o número principal.
3. Remova antes de adicionar. Audite as escolhas de otimização existentes antes de assumir que você precisa de mais capacidade de processamento. Z-ordering, ANALYZE e lógica de shuffle personalizada aplicados sem medição podem estar custando mais do que economizando.
4. Confie no otimizador. O AQE superou a lógica codificada manualmente em vários casos. Antes de escrever otimizações personalizadas, verifique se o Spark já lida com o seu caso.

O quadro geral

Nas palavras de Saad: "Ao tornar nossos sistemas mais rápidos e eficientes, podemos oferecer tarifas mais inteligentes que ajudam nossos clientes a usar energia quando ela é mais barata e mais limpa."

A base de custo reduzida faz algo específico: remove a barreira econômica para o processamento de dados de alta frequência. Isso torna o balanceamento da rede viável como um produto. Isso torna as tarifas inteligentes comercialmente sustentáveis. É assim que a engenharia de dados em escala se conecta à transição energética - não como um overhead de infraestrutura, mas como a base comercial para ela.

A conformidade com o MHHS foi o mandato. Tornar a energia sustentável a opção acessível é a missão. A engenharia de dados é o que conecta os dois.

Aprofunde-se

• Documentação do Delta Lake Change Data Feed
• Databricks Serverless compute
• Apache Spark performance tuning on Databricks

———

Saad Ali é Líder da Equipe de Dados de Margem na Octopus Energy. Ismail Makhlouf, David Poulet e Daniel Taylor são Arquitetos de Soluções na Databricks.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original