Big-Data-Technologien sind nicht die einzige Lösung, wenn es um viele Daten geht. Es gibt mehrere Kriterien, die über die Art der Datenverarbeitung entscheiden.
von Peter Welker
Technisch gesehen geht es beim Trendbegriff „Big Data“ um Daten, die durch ihre schiere Menge (Volume), den benötigten Datendurchsatz und die maximale Verzögerung (Velocity) sowie durch Komplexität und Variabilität (Variety) besondere Techniken für die Datenverarbeitung und Speicherung benötigen.(1) Der Einsatz traditioneller Technologie, wie relationaler Datenbanken, stößt bei solchen Anforderungen architekturbedingt irgendwann an seine Grenzen. Dasselbe gilt für nicht konsequent auf Parallelisierung ausgelegte Programmierparadigmen zur Verarbeitung der Daten.
Zu Beginn der Big-Data-Ära um 2010 konnte man es auf vielen IT-Konferenzen und in zahlreichen Publikationen spüren: Die neuen Lösungen rund um Hadoop und NoSQL sollten vor allem die althergebrachten analytischen Applikationen (z. B. Data-Warehouse) revolutionieren und ersetzen.
Die Investitionen in klassische analytische Anwendungen haben aber keineswegs darunter gelitten. (2) Relationale Datenbanken und klassische Datenintegrationswerkzeuge sind auch nicht so limitiert, wie es die Verfechter neuer Technologie gerne proklamieren. Das Laden, Transformieren und die optimierte Aufbereitung mehrerer hundert Millionen Datensätze pro Tag ist heute auch mit kostengünstiger Hardware kein Problem. Dennoch: Auch wenn die größten relationalen DWH-Datenbanken im zweistelligen Petabyte-Bereich liegen,(3) ist in den meisten Fällen im zwei- bis dreistelligen Terabyte-Bereich Schluss. Häufig wegen Lizenz- und Supportkosten für benötigte kommerzielle Software, nicht etwa weil die Grenze der technischen Leistungsfähigkeit erreicht wäre.
Es sind vielmehr neue Anforderungen, die mit neuen Techniken implementiert werden. Zur Verdeutlichung der Entscheidungskriterien pro oder contra Big-Data-Technologie betrachten wir drei Anwendungsfälle.
Process-Data-Warehouse
Data Warehouses müssen keineswegs nur Finanzdaten aufbereiten. Ein Übertragungsnetzbetreiber aus der Energiebranche lädt täglich 60 Millionen Mess- und Applikationswerte in ein relationales DWH und speichert sie dort für zehn Jahre, um beispielsweise schadhafte Bauteile zu analysieren oder die Zuverlässigkeit von Verbrauchsprognosen zu prüfen. Dafür müssen die Daten spätestens 20 Minuten nach ihrer Erzeugung für Zeitreihen- und andere Analysen optimiert bereitstehen (Latenz). Die wichtigsten auf diesen Daten basierenden Auswertungen benötigen dann jeweils weniger als fünf Sekunden und sind somit interaktiv durchführbar.
Es sprechen erste Kriterien für Big-Data-Technologie. Überraschenderweise ist es aber keineswegs die Datenmenge, denn trotz vieler Datensätze bewegt sich das Volumen noch im unteren Terabyte-Bereich. Allerdings sind Wide-Column-NoSQL-Datenbanken besser für Zeitreihenanalysen geeignet als ihre relationalen Pendants. Dennoch entschied sich der Betreiber aufgrund des traditionellen Know-hows seiner Mitarbeiter, der Stabilität und sicheren Verfügbarkeit relationaler Tools für die klassische Lösung mit hohem Investitionsschutz und vergleichsweise niedrigen Kosten. Und das funktioniert. Die Anwendung skaliert bei Bedarf und stärkerer Hardware auch noch um den Faktor zehn.
Messdatenlandschaft
Es wäre ein Fehler, rein fachliche Kriterien für einen Technologieentscheid zu nutzen. In einem zweiten, ganz ähnlich gelagerten Fall befüllt ein Autozulieferer zwecks Analyse der Produktionsprozesse Dutzende örtlich separierte, aber gleichartige relationale Datenbanken mit Messdaten. Inzwischen bewegt sich das Gesamtvolumen deutlich im dreistelligen Terabyte-Bereich. Alle Informationen sind innerhalb einer Stunde – ebenfalls vorwiegend für Zeitreihenanalysen – fertig aufbereitet.
Im Zuge einer Zusammenführung dieser Datenbanken und eines zunehmend operationalen Monitorings müssen nun sehr zeitnahe Analysen ermöglicht werden. Darum ist es erforderlich, die Latenz auf maximal fünf Minuten zu reduzieren. Jetzt stellen sich neue Fragen: Wie repliziert man Daten aus unterschiedlichen Orten so schnell wie möglich in ein zentrales System, wenn Hunderte von Transformationsprozessen nötig sind und ebenso viele Benutzer gleichzeitig die Daten analysieren?
Wann soll ich Big-Data-Technologien einsetzen?
Wichtige Indikatoren für den Einsatz von Big-Data-Technologien lassen sich also zum einen aus den drei „V“ ableiten: Volume, Velocity und Variety. Wenn man für ein Vorhaben also eine oder mehrere der folgenden Fragen mit Ja beantwortet, ist demnach zumindest eine genauere Technologiebetrachtung angesagt:
Verarbeitungslatenz
Wie lange nach der Entstehung von Daten müssen Muster erkannt und daraus Aktivitäten abgeleitet werden? Habe ich Anforderungen im Minuten- oder Sekundenbereich – oder sogar noch darunter?
Datenvolumen
Wie groß ist die Datenmenge, die insgesamt vorgehalten werden muss? Komme ich weit in den Terabyte-Bereich oder darüber hinaus?
Skalierbarkeit
Muss die Verarbeitung „elastisch“ sein? Also: Werden starke Schwankungen bei der Last erwartet und soll die gewählte Lösung auch noch um den Faktor 10, 100 oder 1 000 nach oben skalierbar sein? Hilft mir eventuell der Einsatz von Cloud-Diensten?
Flexibilität
Wie vielfältig ist mein verfügbares Datenmaterial? Weiß ich jetzt schon, was ich später damit machen möchte?
Andererseits spielen natürlich auch nicht-technische Kriterien eine wichtige Rolle: Das Know-how der Mitarbeiter oder die Bereitschaft einer Abteilung oder eines Unternehmens, sich für reale Fragestellungen auf neue Wege einzulassen zum Beispiel. Ein gutes Erwartungsmanagement und ausreichend Budget für Implementierungsaufwände können ebenfalls wichtige Kriterien sein: Bei ersten Fragestellungen sind nicht immer revolutionäre Antworten zu erwarten und Big-Data-Anwendungen sind nicht einfacher oder kürzer (und damit billiger) als herkömmliche Projekte.
Relationale Datenbanken und klassische Datenintegration alleine erweisen sich dabei aufgrund der nötigen Latenz irgendwann als Flaschenhals. Besser eignen sich Vorgehensweisen aus dem Internet of Things – einer Domäne für Big-Data-Anwendungen: An jedem Standort werden neue (Sensor-)Daten innerhalb von Sekunden vorbereitet und für erste Analysen eine Weile im Hauptspeicher lokaler Rechner – ähnlich einem Gateway – vorgehalten. Die Datenströme fließen gleichzeitig in einen Event-Hub in der Cloud. An diesem bedienen sich alle weiteren Transformationsprozesse, die ihre Ergebnisse in einem großen, ebenfalls cloudbasierten NoSQL-Datenbankcluster ablegen.
Hier kommen zahlreiche Big-Data-Techniken zum Einsatz: Stream-Analytics und Transformationslösungen wie Spark, Event-Hubs wie Kafka und NoSQL-Datenbanken wie Cassandra. Sie wurden ursprünglich von Facebook, LinkedIn und dem APMLab der University of California ins Leben gerufen:
- Im Gegensatz zu traditionellen Tools sind sie konsequent auf Skalierbarkeit ausgelegt. Die meisten Lösungen laufen ohne nennenswerten Overhead auf Clustern mit Hunderten oder Tausenden Rechnern.
- Viele Tools werden von großen Entwicklergemeinden als Open-Source-Programme weiterentwickelt.
- Hinter den meisten Produkten stehen zudem Unternehmen, die Enterprise-Level-Support und kommerzielle Varianten mit erweitertem Funktionsumfang anbieten.
- Sie wurden als Open-Source-Software entwickelt und an die Apache Software Foundation weitergereicht. Inzwischen gibt es dafür auch rein kommerzielle Alternativen, beispielsweise in der Microsoft Azure Cloud (Event-Hubs, Stream-Analytics).
Bewegungsdaten
Ein weiteres Kriterium für den Einsatz neuer Technologien ist neben Datenmenge und Durchsatz bzw. Latenz auch die Datenvielfalt. Während in relationalen Datenbanken stark strukturierte Daten genutzt werden, gilt das nicht für Big-Data-Anwendungen. Auch Texte, Videos, Bilder, Geodaten oder XML- und JSON-Dateien aus Web-Click-Streams oder Applikationslogs sind relevant.
In unserem dritten Fall nutzt ein Mobilfunkbetreiber neben Geodaten und GSM-Daten aus dem Funknetz auch zahlreiche weitere Quellen für analytische Anwendungen. Da inzwischen fast jeder ein angeschaltetes Handy mit sich führt, kann der Netzbetreiber je nach Netzausbau und Art des Funkverkehrs den Aufenthaltsort eines Teilnehmers recht genau orten. Zudem können Endgeräte und zum Teil auch die Teilnehmer identifiziert werden. Die dabei anfallenden Datenmengen sind sehr groß und bedürfen umfangreicher Interpretation. Dann aber lassen sich detaillierte Bewegungsprofile erzeugen.
Natürlich dürfen aus Datenschutzgründen die Daten aller Teilnehmer nur anonymisiert verarbeitet werden, sodass keine Rückschlüsse auf Personen möglich sind. Dennoch bleiben die Möglichkeiten vielfältig. So kann man mit diesen Verfahren sehr einfach zuverlässige Aussagen über den gegenwärtigen Straßenverkehrsfluss machen, Pendlerströme visualisieren, um typische Einzugsgebiete zu erkennen, oder Transit- von regionalem Verkehr unterscheiden.
Die dabei anfallenden Datenmengen überschreiten schon in kurzer Zeit die PetabyteGrenze und sind durchaus vielfältig. Wichtig sind historische Daten, aber manche Anwendungsfälle, wie die Verkehrsbetrachtung, benötigen auch zeitnahe Werte. Zudem will man beim Speichern der Daten eine Unabhängigkeit von den Datenstrukturen sicherstellen (Variety). Während bei der Speicherung in relationalen Datenbanken im Allgemeinen die Datenstruktur vorab bekannt sein muss, ist das bei der Datenablage in File-Systemen wie Hadoop nicht der Fall. Hier genügt es, erst beim Lesen der Daten über deren Struktur Bescheid zu wissen. Das ermöglicht auch das vorausschauende Speichern von Daten, für die heute noch keine ausgearbeiteten Einsatzzwecke vorliegen, die aber mit hoher Wahrscheinlichkeit eines Tages von Bedeutung sein werden.
Alle Indikatoren zeigen also in Richtung der neuen Technologien. Und folgerichtig werden hier beispielsweise Hadoop für die langfristige Speicherung von strukturierten und unstrukturierten Daten und Spark für die Transformation und Analyse dieser Daten eingesetzt. Damit ist neben einer kostengünstigen Ablage von Massendaten auch die Skalierbarkeit für zukünftige Fachanforderungen gesichert.
Quellen:
(1) https://blogs.gartner.com/doug-laney/files/2012/01/ad949-3D-Data-Management-Controlling-Data-Volume-Velocity-and-Variety.pdf, abgerufen am 02.11.2016
(2) https://tdwi.org/Articles/2015/03/31/Dimensional-Data-Warehouses-Get-Job-Done.aspx, abgerufen am 02.11.2016
(3) https://www.guinnessworldrecords.com/world-records/largest-data-warehouse, abgerufen am 02.11.2016
Der Text ist unter der Lizenz CC BY-SA 3.0 DE verfügbar.
Lizenzbestimmungen: https://creativecommons.org/licenses/by-sa/3.0/de/
