Passa al contenuto principale
Soluzioni

Scalabilità per MHHS: come Octopus Energy ha ottenuto una riduzione dei costi di 50 volte nell'ingegneria dei dati di margine

Come un team di tre ingegneri ha riarchitettato le pipeline di dati di Octopus Energy per gestire un aumento del volume dei dati di 48 volte e ha ridotto i costi di 50 volte nel processo.

di Saad Ali, David Poulet, Daniel Taylor e Ismail Makhlouf

  • Cos'è: Come Octopus Energy ha riarchitettato le sue pipeline di dati sui margini su Databricks per soddisfare la regolamentazione MHHS del Regno Unito.
  • La sfida: MHHS moltiplica il volume dei dati per 48x (due letture del contatore per famiglia al mese → 48 al giorno), con una proiezione di aggiungere circa 1 milione di dollari all'anno ai costi della pipeline nell'architettura esistente a singolo grano.
  • Il risultato: Tre ingegneri hanno ricostruito le pipeline in tre mesi, riducendo il costo per data di liquidazione da 23,63 a 0,48 dollari - 50 volte più economico della proiezione MHHS e 2 volte più economico del sistema legacy nonostante 48 volte più dati. Delta Lake Change Data Feed ha guidato una riduzione del 98,8% delle righe elaborate (25 miliardi → 300 milioni) e ha aumentato la freschezza da settimanale a giornaliera; Databricks Serverless ha consentito la finestra di iterazione rapida.

La transizione energetica ha un problema di dati

La rete energetica del Regno Unito sta attraversando la sua trasformazione strutturale più significativa da decenni. Man mano che le energie rinnovabili come l'eolico e il solare assumono una quota maggiore della generazione di elettricità, l'intermittenza diventa un problema di prim'ordine: l'energia è economica quando c'è il sole e costosa quando non c'è.

Il modello di regolamento esistente - basato su letture mensili dei contatori e profili di consumo medi - non può prezzare quel segnale in modo accurato. E se non puoi prezzarlo accuratamente, non puoi trasmettere il segnale ai consumatori, e la domanda non si sposta mai per corrispondere all'offerta.

Il Market-wide Half-Hourly Settlement (MHHS) è la risposta normativa. Ogni famiglia in Gran Bretagna passa da due letture del contatore al mese a 48 letture al giorno. Non si tratta di un cambiamento incrementale. Per un fornitore come Octopus Energy, che serve oltre 8 milioni di clienti, si tratta di un aumento di 48 volte dei punti dati che guidano ogni calcolo del margine, ogni obbligo di regolamento e ogni decisione commerciale.

L'implicazione dell'ingegneria dei dati è diretta: senza una riarchitettura, il costo dell'infrastruttura per eseguire le pipeline di margine di Octopus Energy era previsto che lievitasse di 1 milione di dollari all'anno.

Perché aumentare la potenza di calcolo non funziona

L'istinto, quando i volumi di dati aumentano di 48 volte, è quello di fornire più infrastrutture. Per il team di dati di margine di Octopus Energy, quell'istinto è stato rapidamente convalidato come insostenibile. Il costo previsto per data di regolamento nell'architettura legacy era di 23,63 dollari, un aumento di 33 volte rispetto alle norme storiche. Moltiplicando questo per le finestre di regolamento, il conto aumenta rapidamente.

Tuttavia, il problema più profondo non era il costo del calcolo, ma la discrepanza architetturale. La pipeline legacy era stata costruita attorno a un singolo grano: mensile. La fatturazione avveniva mensilmente. Il regolamento avveniva mensilmente. L'intera pipeline era monolitica per progettazione.

MHHS ha introdotto una divisione fondamentale. I dati sui costi del settore ora arrivano con granularità semioraria - 48 punti dati per cliente al giorno. I clienti con tariffe intelligenti, con veicoli elettrici e pompe di calore, necessitano di calcoli dei ricavi semiorari. I clienti con tariffe standard si regolano ancora mensilmente. Eseguire tutti e tre attraverso un'unica pipeline monolitica significava elaborare l'intero set di dati ad ogni esecuzione, indipendentemente da ciò che era effettivamente cambiato.

Come ha affermato Saad Ali, Lead del Margin Data Team di Octopus Energy: "Non puoi semplicemente aumentare la potenza di calcolo per un problema come questo. Devi ricostruire e ripensare la tua logica da zero.".

L'architettura: tre flussi, un'unica fonte di verità

Il team ha riarchitettato attorno a tre flussi specializzati, ciascuno ottimizzato in modo indipendente per il proprio grano naturale:

Regolamento - Granularità semioraria per il regolamento normativo e l'allocazione dei costi. Gli addebiti del settore a 48 punti dati al giorno; questo flusso corrisponde esattamente a quel grano.

Semiorario - Elaborazione semioraria per i clienti con tariffe intelligenti: conducenti di veicoli elettrici, utenti di pompe di calore e prodotti time-of-use in cui il segnale di prezzo semiorario è l'intera proposta commerciale.

Mensile - Elaborazione mensile per i clienti con tariffe standard, invariata nel grano ma ora riconciliabile con i dati semiorari.

Un modello di orchestrazione "Job of Jobs" gestisce le dipendenze e l'esecuzione parallela tra tutti e tre i flussi. Ogni flusso è regolabile in modo indipendente: ciò che funziona come ottimizzazione Spark per il regolamento non è necessariamente giusto per NHH.

Alla base di tutti e tre si trova il livello di consumo downstream: una fonte di verità unificata e multi-grano che consolida le letture dei contatori, i dati dei contatori intelligenti e i flussi del settore su scala multi-terabyte. Questo livello è il ponte di riconciliazione tra la fatturazione mensile e il regolamento semiorario - ed è diventato il sito dell'ottimizzazione a più alto effetto leva del progetto.

Elaborazione incrementale: il 98,8% in meno di righe

L'approccio ingenuo alle tabelle di consumo upstream - rielaborare l'intero set di dati multi-terabyte ad ogni esecuzione - avrebbe significato costi di calcolo insostenibili con il nuovo volume.

Il Change Data Feed (CDF) di Delta Lake ha reso praticabile l'elaborazione incrementale reale a questo grano. Invece di sovrascritture complete, la pipeline ora legge solo i record che sono effettivamente cambiati dall'ultima esecuzione. Il risultato: le righe elaborate per esecuzione sono scese da 25 miliardi a 300 milioni, una riduzione del 98,8%.

La freschezza dei dati è migliorata da settimanale a giornaliera. Per il team commerciale, questo cambiamento significa visibilità del margine al grano in cui vengono effettivamente prese le decisioni sui prezzi - ogni mattina, non una volta alla settimana.

Nota: i risparmi annuali di 1 milione di dollari citati di seguito escludono i risparmi aggiuntivi derivanti da questo passaggio all'elaborazione incrementale sulle tabelle upstream. Il guadagno di efficienza completo è maggiore.

Ottimizzazione Spark & Delta - e cosa rimuovere

Con 48 volte più dati che fluivano attraverso il sistema, il team ha applicato ottimizzazioni mirate convalidate dalla misurazione in quattro categorie:

Riduzione della lineage e dell'I/O

  • Lineage semplificata consolidando i dati all'inizio della pipeline, riducendo le join downstream e le operazioni di shuffle
  • Potatura dei dati: selezionate solo le colonne strettamente necessarie per il regolamento e potate le righe nella fase più precoce possibile, riducendo l'overhead di I/O prima delle trasformazioni costose

Ottimizzazione di join e partizione

  • Broadcast join per tabelle di riferimento inferiori a 500 MB, eliminando costose operazioni di shuffle su join multi-chiave complesse con intervalli di date
  • Liquid clustering è stato abilitato su più tabelle per colonne frequentemente utilizzate nei filtri e nelle join. Liquid clustering co-localizza dinamicamente i record correlati sulle chiavi di clustering specificate senza richiedere confini di partizione fissi. Liquid clustering evita il problema dei piccoli file, l'elevato consumo di memoria e l'overhead di I/O derivanti da un eccesso di partizionamento.

Fiducia nell'ottimizzatore

  • In diversi casi, l'Adaptive Query Execution (AQE) di Spark ha superato la logica ottimizzata manualmente. Il team ha rimosso il codice di ottimizzazione personalizzato e ha lasciato che AQE facesse il suo lavoro.

Quest'ultimo punto merita enfasi: la rimozione di operazioni di calcolo ingiustificate è stata tanto impattante quanto l'aggiunta di nuove ottimizzazioni. Se stai eseguendo Z-ordering o ANALYZE senza misurarne l'effetto, potrebbero costarti di più di quanto risparmino.

Serverless come acceleratore di sviluppo

Databricks Serverless ha reso possibile la finestra di consegna di tre mesi. Il tempo di avvio zero del cluster ha permesso al team di iterare rapidamente - scrivere, eseguire, misurare, aggiustare - senza aspettare il provisioning dell'infrastruttura.

L'interfaccia utente Serverless ha consentito confronti affiancati delle esecuzioni, rendendo pratico isolare l'effetto delle singole ottimizzazioni.

Nelle parole del team: "Il processo di test e sviluppo non avrebbe potuto essere realizzato senza serverless. L'utilizzo dell'interfaccia utente serverless ci ha aiutato a identificare i colli di bottiglia e a fare confronti facili tra diverse esecuzioni.".

Risultati

MetricaPrimaDopoCambiamento
Righe elaborate per esecuzione25 miliardi300 milioniRiduzione del 98,8%
Costo per data di regolamento (MHHS previsto)$23,63$0,48~50x riduzione
Costo per data di regolamento (vs legacy)$0,71$0,482 volte più efficiente
Risparmi per esecuzione di fine mese-~$83.000vs proiezione non ottimizzata
Evitamento costi annualizzato-~$1.000.000esclusi i risparmi upstream
Freschezza dei datiSettimanaleGiornalieroMiglioramento di 7 volte
Tempo di build-3 mesiTeam di tre persone

I 0,48 dollari per data di regolamento non sono solo una riduzione di 50 volte rispetto al costo previsto da MHHS, ma sono 2 volte più economici di quanto fosse mai stato il sistema legacy, nonostante l'elaborazione di 48 volte più punti dati. La riarchitettura ha garantito la conformità normativa e ha reso il sistema materialmente più efficiente di quello che ha sostituito.

Cosa significa questo oltre l'energia

MHHS è una regolamentazione del settore energetico del Regno Unito. Tuttavia, il modello che rappresenta - un evento normativo o aziendale che moltiplica il volume dei dati a un grano più fine - non è unico per l'energia. Ogni volta che un sistema passa da mensile a giornaliero, da giornaliero a in tempo reale, o da aggregato a transazionale, si applicano le stesse dinamiche.

Quattro insegnamenti trasferibili dall'esperienza di Octopus Energy:

  1. La disallineamento del grano è il driver di costo nascosto. Quando una pipeline elabora tutto al grano più fine indipendentemente dalle esigenze aziendali, paghi in termini di calcolo, freschezza e complessità di manutenzione. Identifica i grani naturali nei tuoi dati e allinea l'elaborazione ad essi.
  2. L'elaborazione incrementale trasforma l'economia delle pipeline. La riduzione del 98,8% delle righe è derivata dalla logica incrementale basata su CDF, non dall'ottimizzazione Spark. Inizia da lì - e ricorda che i risparmi completi sono maggiori della cifra principale.
  3. Rimuovi prima di aggiungere. Controlla le scelte di ottimizzazione esistenti prima di presumere di aver bisogno di più calcolo. Z-ordering, ANALYZE e logica di shuffle personalizzata applicati senza misurazione potrebbero costarti di più di quanto risparmino.
  4. Fidati dell'ottimizzatore. AQE ha superato la logica codificata manualmente in più casi. Prima di scrivere ottimizzazioni personalizzate, verifica se Spark gestisce già il tuo caso.

Il quadro generale

Nelle parole di Saad: "Rendendo i nostri sistemi più veloci ed efficienti, possiamo offrire tariffe più intelligenti che aiutano i nostri clienti a utilizzare l'energia quando è più economica e pulita."

La riduzione della base dei costi fa qualcosa di specifico: rimuove la barriera economica all'elaborazione di dati ad alta frequenza. Ciò rende il bilanciamento della rete praticabile come prodotto. Ciò rende le tariffe intelligenti commercialmente sostenibili. È così che l'ingegneria dei dati su larga scala si collega alla transizione energetica, non come un overhead infrastrutturale, ma come la sua base commerciale.

La conformità MHHS è stata il mandato. Rendere l'energia sostenibile l'opzione conveniente è la missione. L'ingegneria dei dati è ciò che collega le due cose.

Approfondisci

———

Saad Ali è Lead del Margin Data Team presso Octopus Energy. Ismail Makhlouf, David Poulet e Daniel Taylor sono Solutions Architects presso Databricks.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale

Ricevi gli ultimi articoli nella tua casella di posta

Iscriviti al nostro blog e ricevi gli ultimi articoli direttamente nella tua casella di posta.