Blame it on the weatherman

Machine Learning & Serverless- Technologien für analytische Wetterdaten-Produkte
Keine Kommentare

Wer kennt das nicht? Wir stehen morgens auf und schauen nach dem Wetter, planen entsprechend unseren Tag und sind je nach persönlich präferierter Wetterlage besser oder schlechter drauf. Wetter ist immer. Das gilt für das alltägliche wie auch für das wirtschaftliche Leben. Einzelhandel, e-Commerce, Tourismus, die Werbewirtschaft und viele mehr – letztendlich gibt es kaum eine Branche, deren Erfolg nicht auch wetterabhängig ist. Zwar wissen viele Unternehmen um den Wettereinfluss, unterschätzen ihn jedoch mangels genauer Berechnungen oder fehlender Lösungen.

Unter der Marke METEONOMIQS nehmen wir von wetter.com den Wetter-Effekt genauer unter die Lupe und haben dafür diverse B2B-Datenprodukte entwickelt. Von der Forecast-Optimierung über wetterbasiertes Werben bis hin zu Standortanalysen – unsere Lösungen helfen Unternehmen, verschiedene Prozesse auf Basis von Wetter- und Geodaten zu optimieren und neue Geschäftspotenziale zu heben. Dafür wurde ein Team an Fachleuten aus Data Science, Machine Learning und IT zusammengestellt und die entsprechende Infrastruktur aufgebaut. Heute betreuen wir zahlreiche namhafte Kunden aus unterschiedlichen Bereichen.

Ausgangslage

Für unsere B2B-Datenprodukte hatten wir zunächst einen Data Lake basierend auf AWS Technologien aufgebaut. Die Quelldaten kamen direkt aus den operativen Backends oder anderen S3 Buckets. Analog zu dem Ansatz von Databricks mit Bronze-Silver-Gold-Daten wurden die Rohdaten zuerst in Parquet Files umgewandelt (RAW), dann weiter aufbereitet und angereichert (CLEAN) und schließlich in mehreren Schritten aggregiert (CALC).

Danach wurden die Daten als Hive-Tabellen basierend auf Parquet Files in S3 gespeichert und die Verarbeitung mit PySpark auf EMR umgesetzt. Für die Ablaufsteuerung der Data Pipelines wiederum entwickelten wir ein kleines Framework aus AWS StepFunctions und Lambdas.

Die Auslieferung an unsere Kunden geschah durch ein API (AWS API Rest Gateway und Lambda) oder aktiv durch Transfers in verschiedene Cloud Storages direkt aus unseren Data Pipelines.

Die AWS-Ressourcen wurden mit Terraform deployt, die Applikationslogik (StepFunctions, Lambdas und PySpark-Skripte) mit dem Framework von serverless.com.

Abbildung 1: Schaubild der Datenanalyse-Architektur bei wetter.com vor dem Einsatz von Delta Lake.

Motivation & Proof-of-Concept

Da im Laufe der Zeit einige Anforderungen hinzugekommen sind, die vor allem ein Löschen (DELETE) oder Ändern (UPDATE) von einzelnen Datensätzen notwendig machten, war die beschriebene Lösung nicht mehr kompatibel für uns. Ein neues Setup musste her.

In einem gemeinsamen Proof-of-Concept zusammen mit Solution Architects von Databricks

  • wurde von Parquet zu Delta-Tabellen migriert und DELETEs und UPDATEs verprobt,
  • testeten die Data Scientists und Engineers die Usability der Databricks Notebooks,
  • wurde MLflow für das Hand-over eines Machine-Learning-Modells zwischen Data Scientist und Engineers exemplarisch umgesetzt,
  • wurde die Wirtschaftlichkeit der zusätzlichen Lizenzkosten gegen Compute-Ressourcen-Ersparnisse durch Arbeiten auf gemeinsamen Clustern und reduzierte Ops-Aufwände durch DELETE/UPDATE-Möglichkeiten bewertet.

Die positiven funktionalen Tests und der positive Business Case hatten uns überzeugt, woraufhin wir die Parquet Files zu Delta Tables und die EMR Cluster zu Databricks-Cluster änderten.

Abbildung 2: Schaubild der Datenanalyse-Architektur bei wetter.com mit dem Einsatz von Delta Lake und MLflow.

Migration

Während die Konvertierung der bestehenden Parquet-Daten in Delta Tables sowie die entsprechenden Anpassungen in den PySpark-Skripten kaum Aufwand erzeugte, musste die Ablaufsteuerung etwas mehr überarbeitet werden. Denn: Während die EMR Cluster am Anfang der Pipeline bzw. StepFunction erzeugt wurden und mehrere PySpark-Skripte nacheinander auf dem Cluster liefen, war dies mit den Databricks Job Clustern so nicht möglich. Diese wurden mit jedem Job deployt und danach gleich wieder zerstört. Die Lösung: Mehrere in Python implementierte „Workflow Blöcke“, welche jeweils auf einem Job Cluster ausgeführt wurden.

Die Verwendung der Databricks Notebooks hatte folgende Verbesserungen mit sich gebracht:

  • In den Notebooks sind lokal die gleichen Packages verfügbar wie auf dem Cluster. Dies ist bei EMR nicht der Fall gewesen und hat z.B. bei Visualisierungen mit folium zu unschönen Workarounds geführt.
  • Die Notebooks sind direkt nach dem Login verfügbar. Man kann also schon anfangen zu arbeiten, während das Cluster noch hochfährt. EMR Notebooks mussten manuell gestartet werden, was ein laufendes Cluster voraussetzte.
  • Code Completion sowie das schnelle Visualisieren von SQL-Ergebnissen erleichtern das tägliche Arbeiten.

Für die Data Pipeline werden keine Notebooks, sondern PySpark-Skripte genutzt. Diese lassen sich über Databricks Connect mit dem Driver lokal auf dem Laptop starten und remote auf dem Cluster ausführen. So konnten wir die Entwicklung gut beschleunigen.

Zwischenfazit: Die neue Funktionalität der Delta Tables hat nicht nur einige operative Änderungen ermöglicht, sondern auch die generelle Verarbeitungslogik vereinfacht. Hier muss man allerdings durch regelmäßiges OPTIMIZE oder entsprechende Tabellen-Parameter dafür sorgen, dass nicht zu viele „small files“ entstehen.

Durch Timetravel lassen sich manche Probleme besser verstehen, wobei man aber beim Machine-Learning-Modell beachten muss, dass ohne eine VACUUM alte Daten nicht gelöscht werden.

Und dank der Möglichkeit, gemeinsam auf dem gleichen Cluster mit Auto-Scaling zu arbeiten, konnten wir zudem den Verbrauch an EC2-Ressourcen spürbar reduzieren.

Wetter-Indizes mit MLflow

In unserem Team berechnen wir täglich über hundert so genannte Wetter-Indizes für den aktuellen sowie die kommenden Tage. Diese beschreiben den Einfluss des Wetters auf das Absatzverhalten verschiedener Konsumgütergruppen, von Eiscreme über Oberbekleidung bis zu Gartenmöbeln. Da das Wetter überall unterschiedlich ist, passiert dies für jede Postleitzahl in Deutschland und in Kürze auch in anderen Ländern.

Hierfür kommt MLflow wie folgt zum Einsatz: Die Machine-Learning-Modelle werden von den Data Scientists erstellt und in MLflow gespeichert. Von dort können die Data Engineers sie einfach in die Data Pipelines zum Forecast übernehmen. Das Hand-over hat sich so deutlich vereinfacht und zudem macht sich das produktive Ownership der Data Scientist und die verbesserte Zusammenarbeit positiv bemerkbar.

Fazit

Durch die Umstellung des Data Lakes auf ein „Data Lakehouse“ basierend auf Delta Tables wurden die Data Ops und Entwicklungsaufwände reduziert und vereinfacht. Dazu tragen auch die bessere Usability der Notebooks sowie der Einsatz von Tools wie Databricks Connect und MLflow bei. Die so gewonnene Zeit können wir in die Weiterentwicklung unserer METEONOMIQS-Datenprodukte investieren.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -