Kommentar von Benjamin Hofmann, Emax digital Schnellere Datenpipelines dank Spark und Structured Streaming

Anbieter zum Thema

QUNIS GmbH

Confluent Germany GmbH

Fivetran Germany GmbH

Wenn beim Arbeiten mit großen Datenmengen über die aktuellen Herausforderungen gesprochen wird, kommt von Unternehmen als erstes zumeist die Frage: „Wie bekomme ich die besten Informationen aus meinen Daten heraus?“ Um diese Frage zu beantworten, sollte jedoch erst einmal geklärt werden, wie eine große Menge an Daten überhaupt zuverlässig von ihrer Quelle abgeholt, gesäubert und angereichert zu einem Data Warehouse oder einem Data Lake transportiert werden kann.

Die Datenquellen sind unter anderem APIs, Sensoren oder andere Services. Dabei handelt es sich oft um externe Quellen, die nicht unter eigener Kontrolle stehen. So können sich beispielsweise die Inhalte oder die Benennung von KPIs innerhalb eines Reports ändern, ohne dass dies der empfangenden Seite mitgeteilt wird.

Eine weitere wichtige Komponente ist die Zeit, die vergehen kann, bis die Werte verfügbar sind. Bei manchen reicht eine tägliche Aktualisierung, während andere in annähernd Echtzeit in Dashboards benötigt werden. Diese Komponente korreliert auch stark mit den Kosten und sollte somit kontinuierlich optimiert werden.

Spark: Infrastruktur für die Verarbeitung großer Datenmengen

Eines der meistverwendeten Produkte, um solche Herausforderungen zu bewältigen, ist Apache Spark. Dabei handelt es sich um ein Framework für Cluster Computing. Es stellt die grundlegende Infrastruktur für verteilte Brechungen und die Verarbeitung von großen Datenmengen. Das Structured-Streaming-Feature ermöglicht eine zuverlässige und eine annähernd Echtzeit-Verarbeitung der eintreffenden Daten. Im Folgenden werden die Möglichkeiten dieses Features erläutert, bewertet und anhand von Beispielen greifbar gemacht:

Spark ermöglicht das Laden von mehreren strukturierten Dateien (z. B. CSV, JSON, …) in einer Ordnerstruktur, die ein gleiches oder ähnliches Datenschema haben. Diese Daten können dann durch Spark SQL über einem Dataframe, ähnlich wie in einer Datenbank, abgefragt und manipuliert werden.

So können beispielsweise alle Temperatur-Daten eines Sensors des laufenden Jahres eingelesenen werden. Durch eine Abfrage werden die Daten in das gewünschte Format gebracht und mit den Luftfeuchtigkeitsdaten angereichert. Schlussendlich werden sie in eine dem Endverbraucher zugänglich Datenbank geschrieben.

Bei dem oben beschriebenen Beispiel könnte diese Aufgabe jede Stunde gestartet werden. Das kontinuierliche Lesen und Schreiben der gesamten Jahres-Daten ist jedoch nicht kosteneffizient. Deshalb muss andauernd überwacht werden, welche Daten schon gelesen und erfolgreich angereichert wurden. Außerdem ist für viele Systeme selbst eine Latenz von wenigen Minuten zu hoch. Ein solches System aufzubauen, erfordert zudem viel Erfahrung, Wissen und Zeit. Vieles davon wird dem Data Architect durch Structured Streaming abgenommen.

Werkzeug Structured Streaming

Bei Structured Streaming handelt es sich um die verteilte Verarbeitung von Streaming-Daten, basierend auf der Spark-SQL-Engine. Structured Streaming ermöglicht einen hohen, robusten und schnellen Durchsatz von Daten. Es erlaubt das chargenweise Säubern, Anreichern und Auswerten der ankommenden Daten. Die Philosophie hinter Structured Streaming ist, dass der Entwickler sich nicht um das Aufbauen der Streams kümmern muss, sondern sich auf die Verarbeitung der Daten konzentrieren kann. Es bietet somit ein robustes und fehlertolerantes System, das mit wenigen Schritten aufgesetzt werden kann und somit viel Einrichtungsaufwand erspart.

Beispiel Structured Streaming

Um auf das oben genannte Beispiel der Wetterdaten zurückzukommen: Mit Structured Streaming kann ein Cluster initialisiert werden, der 24/7 läuft. Dieser kann dann entweder Streams direkt von Datenquellen wie Kafka lesen oder durch Services wie AWS SQS oder ähnliche Systeme informiert werden, welche neuen Reports bzw. Updates im System verfügbar sind. Die Daten-Charge wird dann gesäubert und angereichet und in eine dem Endkunden zugängliche Datenbank geschrieben. So kann sichergestellt werden, dass die Daten dem Endnutzer so schnell wie möglich zur Verfügung gestellt werden.

Rechtzeitigkeit

Dennoch ist zu beachten, dass ein Cluster nur rund um die Uhr laufen sollte, wenn das unbedingt notwendig ist. Wenn die Anforderungen an die Aktualität der Daten richtiggestellt werden, können erhebliche Kosten gespart werden. Benötigt der Endkonsument die Daten nur stündlich aktualisiert, so kann man bei dem Setup des Streams den Trigger auf „once“ setzten. Der Stream beachtet dann nur die Daten, die seit der letzten Ausführung des Streams neu dazugekommen sind. Mit Apache Airflow oder Databricks Workflows kann der Stream dann in einem beliebigen den Anforderungen entsprechendem Intervall ausgeführt werden. Der große Vorteil an dieser Lösung ist: Sollten sich die Anforderungen an das Intervall ändern, kann dieses ohne große Probleme durch wenige Einstellungsparameter angepasst werden.

Fehlertoleranz

Weitere wichtige Aspekte sind Zuverlässigkeit und Fehlertoleranz. Sollte eine API, ein Sensor oder ein Service unsaubere oder unleserliche Daten zurückgeben (zum Beispiel ein Report mit einem anderen Schema), dann sollte der Prozess nicht abgebrochen, sondern die restlichen, leserlichen Daten weiterverarbeitet werden. Dennoch muss sichergestellt werden, dass auch der neue veränderte Report entweder erneut abgeholt oder anders weiterverarbeitet wird. Structured Streaming ist auf der Prämisse des „exactly-once“ aufgebaut. Dafür wird der exakte Fortschritt der Verarbeitung festgehalten. Das ermöglicht das erneute Verarbeiten der fehlgeschlagenen Prozesse.

Dennoch hat auch Structured Streaming seine Tücken. Besonders wenn ein oder mehrere Cluster kontinuierlich laufen, können schnell hohe Kosten entstehen, die unbedingt im Vorfeld berechnet werden müssen. Auch sollte in Betracht gezogen werden, in welche Datenquelle diese schreiben. Speziell bei Datawarehouses wie einer Redshift sind kontinuierliche Update- oder Upsert-Prozesse für die Datenbank aufwendige Operationen, welche die Geschwindigkeit der Abfragen der Nutzer beinträchtigen können. Letztendlich sollte auch beachtet werden, dass während des Schreibens der ankommenden Daten in Parquet oder CSV-Dateien diese nicht konsistent von einem anderen Prozess gelesen werden können. Dies kann jedoch durch eine Verwendung von Formaten wie Delta mitigiert werden.

Fazit und Ausblick

Structured Streaming und speziell dessen Implementierung in Databricks sind ein sehr mächtiges Werkzeug, wenn es darum geht mit geringem Aufwand, flexible, robuste und optimierte Pipelines zu erstellen. Es heißt die Vorbereitung der Daten benötigt 80 Prozent der Arbeitszeit in der Data Science. Structured Streaming setzt genau hier an und versucht den Aufwand der automatisierten Aufbereitung zu reduzieren, zu verbessern und dem Data Scientist so viel wie möglich abzunehmen. Speziell die Implementierungen durch Databricks Auto Loader machen das Aufsetzten nahezu schmerzfrei. Bei richtiger Verwendung bringt Structured Streaming nahezu keine Nachteile mit sich. Es ermöglicht jedoch den Aufbau von robusten und flexiblen Systemen, mit denen selbst die aufwendigsten Vorberechnungen gemeistert werden können. Structured Streaming ist allerdings noch nicht perfekt und wird stetig weiterentwickelt. Neue Lösungen wie Databricks Live Tables könnten hier als nächste Evolutionsstufe gesehen werden.

(ID:48612439)