Die richtige Wahl

Ganz offensichtlich gibt es in der Welt der Big-Data-Technologien keine Komplettlösung, mit der Datenbank-Architekten alle Grenzen der relationalen oder multidimensionalen Welten einfach und lückenlos überwinden können. Für jeden Problembereich sind bestimmte Werkzeuge und Modellierungsvarianten optimal. Die folgenden Beispiele zeigen mögliche Lösungsansätze mit diesen Technologien sowie die mit einem Einsatz verbundenen Nachteile im Vergleich zu herkömmlichen RDBMS und MOLAP.

unstrukturierte Daten wie Dokumente oder implizit strukturierte Daten wie XML können praktisch mit allen Programmier- und Skriptsprachen verarbeitet werden. Über zentrale Metadaten definierte "Schemata" erlauben darüber hinaus beliebig viele, auch mehrfache und unterschiedliche Sichten auf jede Art von Daten, da die Zugriffsmechanismen und die Transformation in eine andere Darstellung frei implementierbar sind.

Nachteil:Bis auf wenige vordefinierten Formate müssen die Zugriffsmechanismen heute leider noch manuell implementiert werden. Die Zahl neuer, allgemein verfügbarer Formate steigt jedoch stetig an.

Zur zeitnahen Verarbeitung vieler einzelner Transaktionen sind verschiedene Komponenten notwendig und die Möglichkeiten der technischen Umsetzung vielfältig: Ein verteiltes Messaging-System wie Apache Kafka kann beispielsweise zum "Einfangen" von Transaktionen dienen. Mittels einer "Distributed Computing Engine" wie Apache Storm werden die Daten dann über viele Rechenknoten vorverarbeitet, klassifiziert und in eine NoSQL-Datenbank wie HBase geschrieben. Die Verarbeitung einzelner Transaktion kann so innerhalb von Millisekunden durchgeführt werden. Durch die extreme Skalierung über sehr viele Rechenknoten sind damit auch Hunderttausende oder Millionen von Transaktionen pro Sekunde zu bewältigen.

Nachteil: Architektur und Implementierung sind aufwendig und die in den NoSQL-Datenbanken abgelegten Daten sind nicht beliebig verknüpfbar, auch "Joins" gibt es dort oftmals keine. Zudem kann die Datenkonsistenz nicht zu jeder Zeit durchgängig gewährleistet werden. Darüber hinaus sind gängige BI-Werkzeuge oft nicht in der Lage, mit NoSQL-Datenbanken zusammen zu arbeiten.

Auch extrem große Datenmengen, zum Beispiel hunderte von Petabytes können in einem Hadoop- Cluster gespeichert und verarbeitet werden. Backup und Recovery beziehungsweise Hochverfügbarkeit werden hier anders gelöst als in relationalen Datenbanken, unterliegen dabei allerdings auch stärkeren Einschränkungen. Ein vollständig konsistentes Backup wird man praktisch nie erstellen können. Dafür sind auch örtlich weit verteilte Infrastrukturen, so genannte Stretch-Cluster, noch effizient möglich.

Bei Lizenz- und Hardwarekosten sind Lösungen rund um Hadoop sehr günstig, wenn man die Investitionskosten pro Terabyte Nutzdaten betrachtet. Da vor allem weit verbreitete und günstige Hardware verwendet wird, kann man pro Jahr von Aufwendungen weit unter 1.000 Euro pro Terabyte Rohdaten (unkomprimiert) für Speicherung und Verarbeitung ausgehen. Bei Anmietung in einer Cloud-Lösung können diese Preise sogar auf Tage oder Stunden heruntergebrochen werden.

Dazu kommen keine oder geringe Kosten für Softwarelizenzen, da die meisten Tools unter einer Open Source Lizenz nutzbar sind. Betrachtungen der Total Cost of Ownership (TCO) können allerdings zu ganz anderen Ergebnissen führen, wenn Support, Know-how Aufbau und Pflege, Administration, Standkosten, Backup und alle weiteren üblichen Kostenblöcke eingerechnet werden. Dann schrumpft der Vorteil beziehungsweise kann bei unsachgemäßer Nutzung sogar deutlich schlechter ausfallen als bei kommerziellen RDBMS mit lokalem oder netzbasiertem Storage. Um die richtige Entscheidung treffen zu können, gilt es hier den jeweiligen Anwendungsfall zu betrachten.

Welten verbinden

Offenbar lösen die neuen Technologien die klassischen in absehbarer Zeit (noch) nicht ab. Aktuell ergänzen sich beide Welten und erweitern gemeinsam die Grenzen des Machbaren. Folgerichtig etablieren sich heute Werkzeuge, die das Zusammenspiel fördern: Konnektoren und Federation Tools sind die nächsten große Trends. Große RDBMS-Vendoren wie Oracle oder IBM aber auch die Open Source Gemeinde stellen fast im Quartalsrhythmus entsprechende Software für den effizienten Datenaustausch und die Ausführung verteilter Abfragen zur Verfügung.

Datenintegrationswerkzeuge lesen und schreiben bereits heute Daten in beide Richtungen. Und die Virtualisierung von Daten über Federation Engines integriert Datenquellen aller Couleur für die übergreifende Nutzung. Letzteres klingt fast wie die Patentlösung aller Probleme jedoch hat die Analyse verteilter Daten ein grundsätzliches Problem: Beim Verknüpfen großer Datenmengen über Systemgrenzen hinweg, stehen Netzwerk und Medienbruch der geforderten Performance im Wege. Nicht umsonst stellen sogar extrem spezialisierte Datenbankcluster für gute Skalierung höchste Ansprüche an Konfiguration, Hard- und Software. Beim "virtuellen Zusammenstöpseln" heterogener Daten, Strukturen und Plattformen tritt dieses Problem naturgemäß noch viel deutlicher hervor. Verteilte Datenarchitekturen sind für bestimmte Arten von Fragestellungen nützlich und geeignet - Sie sind jedoch leider kein "Allheilmittel."

Was noch fehlt sind Lösungen, um Antwortzeiten bei praktisch beliebigen Ad-hoc-Benutzerabfragen minimal zu halten ohne deren Vorverarbeitungszeit zu erhöhen. Hier kommen In-Memory- Datenbanken oder entsprechende Datenbankerweiterungen ins Spiel. Diese haben aber in den letzten zwei bis drei Jahren Einzug in fast alle wichtigen RDBMS gehalten und sind daher in vielen DWH-Umgebungen heute schon im Einsatz -oder befinden sich zumindest in der Erprobungsphase.

Fazit

Sensor-, Internet- oder Log-Daten, RFID-, Text- und Netzwerkanalyse: Alles in Echtzeit kostengünstig speichern und auswerten. Das alles zusammen mit über Jahre gesammelten Daten aus hunderten von Quellen - ohne Limitierung auf vordefinierte Strukturen aber dennoch selbsterklärend und einfach in der Nutzung: Eine Utopie? Im Grunde Ja - jedoch eine, die mit der zunehmenden Integration von Data Warehouse- und Big Data Technologien ein kleines Stück näher rückt.

Der richtige Einstieg gestaltet sich schwierig, denn geeignete Business-Cases sind durch die RDBMS-Brille gesehen nicht immer auf den ersten Blick erkennbar. Und doch will fast jeder per Social Media erfahren, was in der Öffentlichkeit über ihn gesprochen wird, welche Kunden die interessantesten sind, wie Produktionsanalagen oder Entwicklungsprozesse optimiert werden können (Predictive Analytics, Semantic Web) oder wie Informationen aus unstrukturierten Daten gefiltert werden (Natural Language Processing).

Ein einfacher Einstieg mit hohem Erkenntnispotential ist der Aufbau einer möglicherweise Cloud-basierten Basisinfrastruktur speziell für IT-affine Analysten - die viel zitierten "Data Scientists". Die Verfügbarkeit einer Big Data-Plattform, bestehend aus einer Hadoop-Distribution, nicht restriktiver Toolauswahl und angereichert mit konventionellen und neuen Datenquellen, ermöglicht schnelle Erkenntnisse durch prototypische Entwicklung neuer Analysemethoden. So können Ideen zeitnah validiert und bei Erfolg in die reguläre Entwicklung übergeben werden. Als Nebeneffekt entsteht wertvolles Big Data Know-how und das richtige Fingerspitzengefühl für Möglichkeiten und Risiken.

Der nächste Schritt kann darin bestehen, die Data-Warehouse-Plattform kostengünstig zu entlasten und gleichzeitig unstrukturierte Daten in den BI-Prozess zu integrieren. Diese Archivfunktion steht gegenwärtig in zahlreichen Unternehmen auf dem Prüfstand und wird vereinzelt auch schon erfolgreich eingesetzt.

Beim "Data-Lake"-Ansatz werden alle möglicherweise relevanten Daten kostengünstig, im Originalformat und in feinster Granularität zentral auf einer Big-Data-Plattform gespeichert. Dort stehen sie für alle Systeme zur Verfügung - inklusive Vorverarbeitung, Verteilungsmechanismen und Zugriffsschutz. Dieser möglicher Folgeschritt Richtung Zukunft wird heute noch heftig diskutiert.

Vom zentralen Information Hub, der übergreifend alle Informationen virtualisiert und performant zur Verfügung stellt und diese unabhängig vom Speicherort und für jeden Zweck passend aufbereitet - dürfen Business-Nutzer wohl noch eine Weile träumen. (bw)