Direkt zum Hauptinhalt
Lösungen

Skalierung für MHHS: Wie Octopus Energy die Kosten für Margin-Data-Engineering um das 50-fache senkte

Wie ein Team von drei Ingenieuren die Datenspeicher von Octopus Energy neu gestaltete, um eine 48-fache Datenvolumenerhöhung zu bewältigen – und dabei die Kosten um das 50-fache senkte.

von Saad Ali, David Poulet, Daniel Taylor und Ismail Makhlouf

  • Was es ist: Wie Octopus Energy seine Margin-Datenspeicher auf Databricks neu gestaltete, um die britische MHHS-Regulierung zu erfüllen.
  • Die Herausforderung: MHHS vervierzigfacht das Datenvolumen (zwei Zählerstände pro Haushalt pro Monat → 48 pro Tag), was voraussichtlich zusätzliche Kosten von ca. 1 Million US-Dollar pro Jahr für die Pipelinekosten unter der bestehenden Single-Grain-Architektur verursacht.
  • Das Ergebnis: Drei Ingenieure bauten die Pipelines in drei Monaten neu und senkten die Kosten pro Abrechnungsdatum von 23,63 US-Dollar auf 0,48 US-Dollar – 50-mal günstiger als die MHHS-Prognose und 2-mal günstiger als das Altsystem trotz 48-mal mehr Daten. Delta Lake Change Data Feed führte zu einer Reduzierung der verarbeiteten Zeilen um 98,8 % (25 Milliarden → 300 Millionen) und erhöhte die Aktualität von wöchentlich auf täglich; Databricks Serverless ermöglichte das schnelle Iterationsfenster.

Die Energiewende hat ein Datenproblem

Das britische Stromnetz durchläuft die bedeutendste strukturelle Transformation seit Jahrzehnten. Da erneuerbare Energien wie Wind und Sonne einen größeren Anteil an der Stromerzeugung ausmachen, wird die Intermittenz zu einem erstklassigen Problem: Energie ist billig, wenn die Sonne scheint, und teuer, wenn sie nicht scheint.

Das bestehende Abrechnungsmodell – das auf monatlichen Zählerständen und durchschnittlichen Verbrauchsprofilen basiert – kann dieses Signal nicht genau bepreisen. Und wenn man es nicht genau bepreisen kann, kann man das Signal nicht an die Verbraucher weitergeben, und die Nachfrage verschiebt sich nie, um das Angebot auszugleichen.

Das branchenweite Half-Hourly Settlement (MHHS) ist die regulatorische Reaktion. Jeder Haushalt in Großbritannien wechselt von zwei Zählerständen pro Monat zu 48 Zählerständen pro Tag. Das ist keine inkrementelle Änderung. Für einen Lieferanten wie Octopus Energy, der über 8 Millionen Kunden betreut, bedeutet dies eine 48-fache Erhöhung der Datenpunkte, die jede Margenberechnung, jede Abrechnungsverpflichtung und jede kommerzielle Entscheidung beeinflussen.

Die Implikation für das Data Engineering ist direkt: Ohne eine Neukonstruktion wären die Infrastrukturkosten für den Betrieb der Margin-Pipelines von Octopus Energy jedes Jahr um 1 Million US-Dollar gestiegen.

Warum die bloße Bereitstellung von Rechenleistung hier nicht funktioniert

Der Instinkt bei einer 48-fachen Erhöhung des Datenvolumens ist die Bereitstellung zusätzlicher Infrastruktur. Für das Margin-Data-Team von Octopus Energy erwies sich dieser Instinkt schnell als nicht tragbar. Die prognostizierten Kosten pro Abrechnungsdatum unter der Altsystemarchitektur beliefen sich auf 23,63 US-Dollar – eine 33-fache Erhöhung gegenüber den historischen Normen. Multipliziert man dies über die Abrechnungsfenster, steigen die Kosten schnell an.

Das tiefere Problem war jedoch nicht die Rechenleistung, sondern die Nichtübereinstimmung der Architektur. Die Altsystem-Pipeline wurde um ein einziges Korn aufgebaut: monatlich. Die Abrechnung erfolgte monatlich. Die Verrechnung erfolgte monatlich. Die gesamte Pipeline war monolithisch konzipiert.

MHHS führte zu einer grundlegenden Aufteilung. Branchenkostendaten liegen nun in halb stündlicher Granularität vor – 48 Datenpunkte pro Kunde und Tag. Kunden mit intelligenten Tarifen, Elektroautos und Wärmepumpen benötigen halb stündliche Umsatzberechnungen. Kunden mit Standardtarifen werden weiterhin monatlich abgerechnet. Der Betrieb aller drei über eine einzige monolithische Pipeline bedeutete, dass der gesamte Datensatz bei jedem Lauf verarbeitet wurde, unabhängig davon, was sich tatsächlich geändert hatte.

Wie Saad Ali, Leiter des Margin Data Teams bei Octopus Energy, es formulierte: „Man kann nicht einfach mehr Rechenleistung in ein Problem wie dieses stecken. Man muss seine Logik von Grund auf neu aufbauen und überdenken.“

Die Architektur: drei Streams, eine Quelle der Wahrheit

Das Team hat die Architektur um drei spezialisierte Streams herum neu aufgebaut, die jeweils unabhängig für ihr natürliches Korn optimiert sind:

Abrechnung – Halb stündliche Granularität für die regulatorische Abrechnung und Kostenallokation. Branchengebühren mit 48 Datenpunkten pro Tag; dieser Stream entspricht genau diesem Korn.

Halbstündlich – Halb stündliche Verarbeitung für Kunden mit intelligenten Tarifen: Fahrer von Elektroautos, Nutzer von Wärmepumpen und Produkte mit nutzungsabhängiger Preisgestaltung, bei denen das halb stündliche Preissignal die gesamte kommerzielle Grundlage darstellt.

Monatlich – Monatliche Verarbeitung für Kunden mit Standardtarifen, unverändert im Korn, aber jetzt mit den halb stündlichen Daten abgleichbar.

Ein „Job of Jobs“-Orchestrierungsmuster verwaltet Abhängigkeiten und parallele Ausführung über alle drei Streams hinweg. Jeder Stream ist unabhängig abstimmbar – was als Spark-Optimierung für die Abrechnung funktioniert, ist nicht unbedingt richtig für NHH.

Unterstützt werden alle drei von der nachgelagerten Verbrauchsschicht: einer vereinheitlichten Quelle der Wahrheit mit mehreren Körnern, die Zählerstände, Smart-Meter-Daten und Branchenflüsse im Multi-Terabyte-Maßstab konsolidiert. Diese Schicht ist die Abgleichbrücke zwischen monatlicher Abrechnung und halb stündlicher Verrechnung – und sie wurde zum Ort der einzigen, am stärksten wirkenden Optimierung in dem Projekt.

Inkrementelle Verarbeitung: 98,8 % weniger Zeilen

Der naive Ansatz für die vorgelagerten Verbrauchstabellen – die vollständige Verarbeitung des Multi-Terabyte-Datensatzes bei jedem Lauf – hätte zu nicht tragbaren Rechenkosten bei dem neuen Volumen geführt.

Das Change Data Feed (CDF) von Delta Lake machte eine echte inkrementelle Verarbeitung in diesem Korn möglich. Anstatt vollständiger Überschreibungen liest die Pipeline jetzt nur noch die Datensätze, die seit dem letzten Lauf tatsächlich geändert wurden. Das Ergebnis: Die pro Lauf verarbeiteten Zeilen sanken von 25 Milliarden auf 300 Millionen – eine Reduzierung um 98,8 %.

Die Datenaktualität verbesserte sich von wöchentlich auf täglich. Für das kaufmännische Team bedeutet dieser Wechsel eine Margentransparenz im Korn, in dem Preisentscheidungen tatsächlich getroffen werden – jeden Morgen, nicht einmal pro Woche.

Hinweis: Die unten genannten jährlichen Einsparungen von 1 Million US-Dollar schließen die zusätzlichen Einsparungen aus dieser Umstellung auf inkrementelle Verarbeitung vorgelagerter Tabellen aus. Der vollständige Effizienzgewinn ist größer.

Spark & Delta Optimierung – und was zu entfernen ist

Bei 48-fach mehr Daten, die durch das System flossen, wandte das Team gezielte Optimierungen an, die durch Messungen in vier Kategorien validiert wurden:

Lineage- und E/A-Reduzierung

  • Vereinfachte Lineage durch frühe Konsolidierung von Daten in der Pipeline, wodurch nachgelagerte Joins und Shuffle-Operationen reduziert wurden
  • Datenbereinigung: Nur die für die Abrechnung unbedingt erforderlichen Spalten wurden ausgewählt und Zeilen so früh wie möglich bereinigt, wodurch der E/A-Overhead vor teuren Transformationen reduziert wurde

Join- und Partitionstuning

  • Broadcast Joins für Referenztabellen unter 500 MB, wodurch teure Shuffle-Operationen bei komplexen Mehrfach-Schlüssel-Joins mit Datumsbereichen eliminiert wurden
  • Liquid Clustering wurde über mehrere Tabellen hinweg für Spalten aktiviert, die häufig in Filtern und Joins verwendet werden. Liquid Clustering platziert verwandte Datensätze dynamisch auf den angegebenen Clustering-Schlüsseln, ohne dass feste Partitionsgrenzen erforderlich sind. Liquid Clustering vermeidet das Problem kleiner Dateien, den höheren Speicherverbrauch und den E/A-Overhead, der durch Überpartitionierung entsteht.

Dem Optimierer vertrauen

  • In mehreren Fällen übertraf die Adaptive Query Execution (AQE) von Spark die manuell abgestimmte Logik. Das Team entfernte benutzerdefinierten Optimierungscode und ließ AQE seine Arbeit machen.

Der letzte Punkt verdient Betonung: Die Entfernung ungerechtfertigter Rechenoperationen war genauso wirkungsvoll wie das Hinzufügen neuer Optimierungen. Wenn Sie Z-Ordering oder ANALYZE ohne Messung ihrer Wirkung durchführen, kosten sie Sie möglicherweise mehr, als sie einsparen.

Serverless als Entwicklungsbeschleuniger

Databricks Serverless machte das dreimonatige Lieferfenster möglich. Die Startzeit von Null Clustern ermöglichte es dem Team, schnell zu iterieren – schreiben, ausführen, messen, anpassen – ohne auf die Bereitstellung der Infrastruktur warten zu müssen.

Die Serverless-Benutzeroberfläche ermöglichte den direkten Vergleich von Läufen und machte es praktikabel, die Auswirkung einzelner Optimierungen zu isolieren.

Mit den Worten des Teams: „Der Test- und Entwicklungsprozess wäre ohne Serverless nicht möglich gewesen. Die Verwendung der Serverless-Benutzeroberfläche half uns, Engpässe zu identifizieren und einfache Vergleiche zwischen verschiedenen Läufen anzustellen.“

Ergebnisse

MetrikVorherNachherÄnderung
Zeilen pro Lauf verarbeitet25 Milliarden300 Millionen98,8 % Reduzierung
Kosten pro Abrechnungsdatum (prognostiziert MHHS)23,63 $0,48 $~50x Reduzierung
Kosten pro Abrechnungsdatum (vs. Altsystem)0,71 $0,48 $2x effizienter
Einsparungen pro Monatsende-Lauf-~83.000 $vs. unoptimierte Prognose
Jährliche Kostenvermeidung-~1.000.000 $ohne vorgelagerte Einsparungen
DatenaktualitätWöchentlichTäglich7x Verbesserung
Build-Zeit-3 MonateTeam von drei Personen

Die 0,48 US-Dollar pro Abrechnungsdatum sind nicht nur eine 50-fache Reduzierung gegenüber den prognostizierten MHHS-Kosten – sie sind 2x günstiger als das Altsystem jemals war, obwohl 48-mal mehr Datenpunkte verarbeitet wurden. Die Neukonstruktion sorgte für die Einhaltung der Vorschriften und machte das System materiell effizienter als das System, das es ersetzte.

Was das jenseits der Energiebranche bedeutet

MHHS ist eine britische Energieregulierung. Das Muster, das es darstellt – ein regulatorisches oder geschäftliches Ereignis, das das Datenvolumen in einem feineren Korn vervielfacht – ist jedoch nicht auf den Energiesektor beschränkt. Jedes Mal, wenn ein System von monatlich auf täglich, von täglich auf Echtzeit oder von aggregiert auf transaktional umstellt, gelten die gleichen Dynamiken.

Vier übertragbare Erkenntnisse aus der Erfahrung von Octopus Energy:

  1. Fehlausrichtung des Korns ist der versteckte Kostentreiber. Wenn eine Pipeline alles im feinsten Korn verarbeitet, unabhängig vom Geschäftszweck, zahlen Sie dafür in Rechenleistung, Aktualität und Komplexität der Wartung. Identifizieren Sie die natürlichen Körner in Ihren Daten und richten Sie die Verarbeitung daran aus.
  2. Inkrementelle Verarbeitung verändert die Pipeline-Ökonomie. Die Reduzierung der Zeilen um 98,8 % wurde durch CDF-basierte inkrementelle Logik erzielt, nicht durch Spark-Tuning. Beginnen Sie dort – und denken Sie daran, dass die vollständigen Einsparungen größer sind als die Schlagzeilenzahl.
  3. Entfernen, bevor Sie hinzufügen. Überprüfen Sie bestehende Optimierungsentscheidungen, bevor Sie davon ausgehen, dass Sie mehr Rechenleistung benötigen. Z-Ordering, ANALYZE und benutzerdefinierte Shuffle-Logik, die ohne Messung angewendet werden, kosten Sie möglicherweise mehr, als sie einsparen.
  4. Vertrauen Sie dem Optimierer. AQE hat in mehreren Fällen handcodierte Logik übertroffen. Testen Sie, ob Spark Ihren Fall bereits behandelt, bevor Sie eine benutzerdefinierte Optimierung vornehmen.

Das Gesamtbild

Mit den Worten von Saad: „Indem wir unsere Systeme schneller und effizienter machen, können wir intelligentere Tarife anbieten, die unseren Kunden helfen, Energie dann zu nutzen, wenn sie am günstigsten und saubersten ist.“

Die reduzierten Kosten senken etwas Bestimmtes: Sie beseitigen die wirtschaftliche Hürde für die Hochfrequenzdatenverarbeitung. Das macht Netzstabilisierung als Produkt rentabel. Das macht intelligente Tarife kommerziell nachhaltig. So verbindet Data Engineering im großen Maßstab die Energiewende – nicht als Infrastruktur-Overhead, sondern als deren kommerzielle Grundlage.

Die MHHS-Konformität war das Mandat. Nachhaltige Energie zur erschwinglichen Option zu machen, ist die Mission. Das Data Engineering verbindet die beiden.

Weiter gehen

———

Saad Ali ist Leiter des Margin Data Teams bei Octopus Energy. Ismail Makhlouf, David Poulet und Daniel Taylor sind Solutions Architects bei Databricks.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag

Erhalten Sie die neuesten Beiträge in Ihrem Posteingang

Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.