w26M2

strukturierten Formaten und überschaubaren Mengen.
Die Herausforderungen bei der Integration in ein Data
Warehouse sind daher in erster Linie logischer und nicht
technischer Natur.
Big Data verändert auch im Anwendungsgebiet ETL so
manche liebgewonnene Vorgehensweise und sorgt für
neue Herausforderungen, wie auch neue Chancen.
ETL-Herausforderungen durch Big Data
Die Big-Data-Herausforderungen für ETL-Prozesse liegen
auf der Hand: Die teils sehr großen Datenmengen und vor
allem die Geschwindigkeit, mit der neue Daten generiert
werden, erfordern eine hoch performante Plattform für
ETL-Prozesse. Dies betrifft in erster Linie die Operationen
des Bereinigens und des Umformens der Daten, um sie
für Analysen zu erschließen 136 . Software, die für eine SMP-
Ablaufumgebung, also die Ausführung auf einzelnen
Standardservern, entwickelt wurde, kann hier Probleme
bekommen, ausreichend zu skalieren.
Sollen beispielsweise Sensorik-Daten aus einer technischen
Großanlage 137 verarbeitet werden, dann kommen
leicht mehrere hunderttausend Datensätze pro Sekunde
als Eingangsmenge zustande. Solch ein Datenvolumen
kann von konventionellen ETL-Tools bei weitem nicht
mehr online verarbeitet werden. Die Daten werden daher
einfach im ursprünglichen Format abgespeichert – ein
typisches Big-Data-Vorgehen.
Natürlich verschiebt sich durch dieses Verfahren das
Integrationsproblem einfach nur zeitlich nach hinten:
Irgendwann müssen die gespeicherten Daten erschlossen
werden und auch die Verarbeitung der ruhenden Datenbestände
muss in einem sinnvollen Zeitraum erledigt
sein.
Gleichzeitig stellen die neuen nicht-, semi- und multistrukturierten
Datenquellen herkömmliche Werkzeuge
vor neue Herausforderungen. Klassische ETL-Werkzeuge,
sind dafür entwickelt worden, mit strukturierten Daten
umzugehen. Für diesen Anwendungsfall sind sie hoch
optimiert. Die Processing-Pipelines setzen voraus, dass
die Input-Datenstrukturen präzise definiert sind (Fixed
Schemas), was in einer Big-Data-Aufgabenstellung häufig
nicht möglich ist. Selbst, wenn Datenschemata prinzipiell
vorhanden sind, so sind diese nicht selten unvollständig
definiert oder inkonsistent. Big-Data-ETL-Werkzeuge müssen
daher Daten mit lose definierten und sich ändernden
Schemata verarbeiten können. Die Definition einer Datenstruktur
kann häufig erst am Ende einer Verarbeitungskette
passieren (Late Schemas, vgl. Abschnitt 5.9).
Beispiel Sensorik-Daten
Diese Schwierigkeiten lassen sich wiederum gut am
Beispiel von Sensorik-Daten nachvollziehen: Besteht die
Aufgabenstellung beispielsweise darin, Diagnosedaten
von Kraftfahrzeugflotten zu analysieren, so hat man es
mit unterschiedlichsten Formaten aus den verschiedenen
Steuergeräten und Wertespeichern der Aggregate zu tun.
Diese Formate sind häufig schlecht dokumentiert, je nach
Zulieferer gibt es Varianten und je nach Firmware-Stand
eines Steuergeräts können sich Änderungen des Schemas
von einem zum anderen Auslesezeitpunkt ergeben.
Eine weitere typische Klasse von Big-Data-Daten – Social-
Media-Daten – sind sehr strukturiert, wenn es um die
Metainformationen geht (Datum, User, Standort etc.). Es
werden gut dokumentierte, einfache XML- oder JSON-
Formate verwendet. Die Inhalte dagegen (Tweets, Posts,
Blogeinträge) sind unstrukturierte Texte, die durch Textanalyseverfahren
erschlossen werden müssen. Bestenfalls
erleichtern (Hash-)Tags diese Arbeit.
Big-Data-Denkweise – neuer Umgang mit Daten
Doch nicht nur die Datenmengen und Strukturen sind
es, die ein Umdenken notwendig machen. Auch der
Umgang mit Daten ändert sich im Zuge der Big-Data-
Denkweise. In der neuen Welt der Big Data Analytics mit
136
Das ist das T in ETL: Transform.
137
z. B. einem Kraftwerk oder einem Windpark
94