Entwicklung nach SCRUM und CRISP-DM am Fallbeispiel der Wärmeprognose bei STEAG New Energies

Die benötigten Daten wurden über ein Gateway sicher für die Microsoft Azure Cloud-Plattform verfügbar gemacht und unter Verwendung der Azure Data Factory und geeigneter ETL Pipelines in einem für analytische Fragestellungen optimierten Format auf Azure Datalake Gen2 zur weiteren Verwendung persistiert. Zusätzlich wurden weitere Datenquellen wie bspw. Wetter APIs angebunden, um die existierende Datenbasis um weitere wichtige relevante Attribute für die Prognose anzureichern. Über Azure Synapse Serverless-DB werden durch Views aus den multiplen Datenquellen im Data Lake Datensätze als Input für Machine Learning Modelle erzeugt. Das hier genutzte schema-on-read-Pattern ermöglicht hier eine sehr schnelle und zugleich robuste Datenintegration, die sich auf die relevanten Inhalte fokussiert.  Jupyter Notebooks dienen der initialen Sichtung und einer deterministischen Beschreibung der Datengrundlage auf die erste Datenanalysen wie der Erhebung statistischer Momente denen Cross-Korrelationsanalysen und die Untersuchung der Residuen bereits vorhandener Prognosetools folgen. Die Analysen werden entsprechenden Experimenten in Azure Machine Learning zugeordnet. Die ersten Erkenntnisse werden durch Datenvisualisierung frühzeitig mit Domänenexperten geteilt und diskutiert.  

Auf Basis der aus der Datenanalyse erhoben Erkenntnisse wurden geeignete Strategien entwickelt, um die Datengrundlage zu bewerten und optimieren. Neben dem Umgang mit statistischen Ausreißern oder fehlenden Daten konnte durch die Analyse der Residuen des bereits vorhandenen, aber noch unzureichenden Prognosetools, Artefakte identifiziert werden, die sich in Rücksprache mit Domänenexperten als systematische, bis dato unwissentliche Verunreinigungen mit Sensorsignalen eines Wärmespeichers herausstellten. Eine Bereinigung der Zeitreihen des Wärmebedarfs, um diese Artefakte, bewirkte eine direkte Verbesserung der Prognosegenauigkeit des vorhandenen Prognosemodell um fast 10%. Entsprechende Visualisierungen wurden bereitgestellt und den Stakeholdern präsentiert. Zeitgleich wurde die gewonnen Erkenntnisse aus Schritte 2 und 3 in einem geeigneten Wiki (Azure DevOps) erfasst und hinreichend dokumentiert. Die bereinigten und für das Feature Engineering vorbereiten historischen Daten wurden als Datasets aufbereitet und in Azure Machine Learning Studio als File und Tabular Datasets registriert, um durch eine entsprechende Versionierung auch den Lifecycle der Daten nachverfolgen zu können. 

Die aufgearbeiteten und vorbereiteten Datensets aus Schritt 3 und 4 dienen in Kombination mit dem angeeigneten Domänenwissen der Feature Extraktion und dem Feature Engineering. Neben der Extraktion von Industriefeatures aus Daten der ansässigen Industrien, der Vorbereitung von Date-Time-Features, spielen vor allem auch Features abgeleitet aus den Leitregressoren über den Vorhersagezeitraum, wie z.B. der Temperaturprognose, eine große Rolle. Da diese Regressoren selbst einer Prognose unterliegen, ist ein Umgang mit deren Prognosefehlern elementar und geeignete Features, die diesen Sachverhalt abbilden, zwingend notwendig. Im Kontext des iterativen Vorgehens nach CRISP-DM wurden mithilfe des Expertenwissens und Methoden aus dem Bereich der Data Science für ein schnelles Testing und der Entwicklung eines ersten MVPs zunächst naheliegende Features extrahiert und bereitgestellt, bevor die Modelle in späteren Iterationen mit komplexeren Features angereichert wurden. Die extrahierten Features wurden entsprechend der Datensätze ebenso in Form von File oder Tabular Datasets registriert, persistiert und somit versioniert. 

In den ersten Projektiterationen wurden zunächst einfache Lösungen zur Prognose von stochastischen und deterministischen Zeitreihen getestet bevor komplexere Modellarchitekturen auf Basis neuronaler Netze verwendet wurden, um die ungleich größere Komplexität, die der Modellierung des Wärmebedarfs unterliegt, abzubilden. Das bereits im Einsatz befindliche Auto Regressive Moving Average Modell (ARIMA) bildet dabei die Baseline und konnte bereits durch Bereinigung der Datengrundlage und neuen Features enorm verbessert werden. Da die Komplexität durch das ARIMA Modell gemessen an der Zielsetzung des Business Cases dennoch nur unzureichend erfasst wurde, wurden iterativ neue Modellklassen (z.B. Prophet, Neural Prophet, XGBoost, 1D-CNN, 1D-CNN-LSTM, Bidirectional LSTMs, Attention based Bidirectional Seq2seq Modells) in Experimenten – zunächst mittels Jupyter Notebooks – erprobt. Die vielversprechendsten Modelle wurden frühzeitig hinsichtlich ihrer Hyperparameter optimiert und in Azure Machine Learning Studio als Artefakt mit gleichzeitigem Verweis auf den dem Training zugrunde liegenden Datensatz sowie unter Auflistung der gegenwärtigen Hyperparameter registriert. Die Modelle wurden anschließend zum weiteren Testing im Live-Betrieb als Container Services (REST Service) bereitgestellt. Die Prognosen selbst sowie etwaige Metriken wurden zur Nachverfolgung der Prognosegüte in Power BI dargestellt und dem Team sowie den beteiligten Stakeholdern nach Schaffung eines gemeinsamen Verständnisses zur Interpretierbarkeit der Darstellungen in gemeinsamen Workshops zugänglich gemacht. 

Nach Optimierung der Modellarchitektur und der Hyperparameter stand die Implementierung geeigneter MLOPs und DevOps Prozesse im Fokus. Auf den Use Case abgestimmte DevOps/MLOps Pipelines sind fundmental wichtig, um die Modelle automatisiert bereitstellen und in die bereits vorhandene Big Data Plattform sowie die dort abgebildeten Geschäftsprozesse integrieren zu können. Die Umsetzung von Continuous Integration und Continuous Delivery Pipelines (CI/CD) in Azure DevOps dienten so der Sicherstellung der Integrität der Code Basis und der Bereitstellung der notwendigen ML-Pipelines in Azure Machine Learning Studio.  Die Machine Learning Pipelines umfassen dabei die notwendigen Tasks (z.B. Python Script Steps) zur Modellinteraktion, bilden diese als Workflow ab und stellen eine Umgebung sowie direkte Verknüpfung zu definierten Compute Ressourcen bereit, die eine Ausführung der in Produktion notwendigen ML-Workflows erlauben. Durch das Ansprechen der ML-Pipeline-Endpoints in der Azure Data Factory wird so eine automatisierte Interaktion mit der Code Basis möglich, die genutzt wird, um das Training neuer Modelle zu ermöglichen, bereits im produktiven Einsatz befindliche Modelle durch Online Learning auf die gegenwärtige Datengrundlage zu aktualisieren, sowie die Modelle automatisiert als REST-Service durch die gegebenen Funktionalitäten von Azure Machine Learning Studio (Container oder Kubernetes Service) bereitzustellen. Der Deployment Prozess neuer als auch produktiver Modelle wird zudem durch ein ständiges ML-Life-Cycle Management gestützt. Die Ausführung von ML-Pipelines wird so direkt an Machine Learning Experimente geknüpft und Modelle im Zusammenspiel mit den genutzten Datensätzen versioniert als auch mit entsprechenden Metadaten, wie Hyperparameter, Trainingsmetriken sowie genutzter Fehlerfunktionen, versehen.    

Zur Sicherstellung der fachlichen Integrität, Funktionalität sowie der Gewährleistung der Ausfallsicherheit im operativen Betrieb, sind geeignete Maßnahmen zu treffen. Ein umfassendes Monitoring der Modelle im produktiven Betrieb – vor allem bei kritischen Prozessen, zudem auch die Vorhersage des Wärmebedarfs im Kontext der Energieversorgung zählt – ist elementar. Mit Hilfe von geeigneten Logging–Tools auf Code-Ebene und der Verwendung der Azure Application Insights wird der Gesundheitszustand der bereitgestellten Modelle als auch der ML-Pipelines permanent überwacht, indem Log-Files auf den Datalake Gen2 geschrieben werden. Von dort werden die Log-Dateien durch den Azure Monitoring Service gelesen/konsumiert und entsprechende Metriken, wie z.B. Antwortzeiten der REST-Services oder das Fehlschlagen von ML-Pipeline-Runs, dargestellt. Schwellenwerte, die auf diese Metriken definiert sind, erlauben die Realisierung eines automatischen Alertings, um bei Bedarf schnell zu intervenieren und Maßnahmen einzuleiten. Weitere Metriken insbesondere zur fachlichen Bewertung der Prognosegüte und des Modelltrainings werden in Power BI dargestellt. Die hohe Verfügbarkeit und Ausfallsicherheit der zugrundliegenden Ressourcen werden durch eine multiregionale Bereitstellung und Redundanz sichergestellt. Der Betrieb von sog. Shadow-Models im Hintergrund, die im hier skizzierten Use Case durch einfache deterministische und stochastische Modelle wie dem ARIMA-Modell vertreten werden, können im Notfall einen fachlichen Ausfall der komplexeren Modelle auf Basis von Neuronalen Netzen kompensieren und Prognosen gewährleisten, sollten Metriken durch etwaige Fehler im Modelltraining oder laufenden Betrieb verletzt werden.  Eine besondere Herausforderung beim Betrieb von neuronalen Netzen – insbesondere im Hinblick auf Zeitreihenprognosen – stellt das sog. Online Learning dar, bei dem Modelle mit der Verfügbarkeit neuer Trainingsdaten stetig nachtrainiert werden, um bestmögliche Prognoseergebnisse zu erzielen. Eine geeignete Validierung als auch Überwachung der Datenqualität ist deshalb unabdingbar. Neben dem Monitoring der Modelle wurde aus diesem Grund ebenso ein Monitoring der Daten umgesetzt, sodass diese auf Basis statistischer Momente und deterministischer Erhebungen stetig nach ihrer Qualität bewertet werden. Eine Trainingsiteration findet entsprechend nur statt, sofern eine ausreichende Datenqualität gegeben ist. Das Monitoring der Datenqualität und deren Visualisierung in Power BI erlaubt es den Domänenexperten darüber hinaus, direkte Rückschlüsse auf die Anlagenqualität zu ziehen. Sichtbar wird zudem der enorme Concept-Drift in der historischen und gegenwärtigen Datengrundlage, verursacht durch die derzeitigen globalen Ereignisse (Covid-19 und Ukraine–Konflikt), die sich enorm auf das Konsumentenverhalten von Industrien und Privathaushalten niederschlägt. Durch das Monitoring werden solche Drifts schnell identifiziert und können durch Anpassung der Fehlerfunktion an den geschäftlichen Kontext oder das Einbringen von Domänenwissen kompensiert werden. Die Summe an gelisteten Maßnahmen ermöglichen so eine dauerhafte Wartung und Support im operativen Betrieb. Neue Erkenntnisse können so stetig erhoben werden, auf deren Grundlage die Phasen nach CRISP-DM in weiteren Zyklen durchlaufen werden, so dass iterativ die Modell- und damit die Prognosequalität kontinuierlich verbessert werden können.