Thought Leadership
Ist Big Data eine „Disruptive Technology“ und löst Business Intelligence (BI) und konventionelle Data Warehouses (DWH) über kurz oder lang ab? Oder ist Big Data für herkömmliche BI völlig ungeeignet und hat in diesem Umfeld nichts zu suchen?
Der Beginn einer wunderbaren Freundschaft?
Am 16. April 2014 schrieb William Harvey Inmon einen bemerkenswerten Blog-Eintrag. Unter der Überschrift „Big Data or Data Warehouse? Turbocharge your Porsche – buy an Elephant“ echauffierte sich der „Vater des Data Warehousing“ über den Cloudera-Werbeslogan „BIG DATA – Turbocharge your Data Warehouse“. Grundsätzlich ärgerte ihn die Vermischung von Architektur (Data Warehouse) und Technologie (Big Data). Insbesondere hob er aber hervor, dass es mit der Hadoop Plattform von Apache schlicht unmöglich sei, eine für Data Warehouses zwingend notwendige umsichtig konstruierte und betreibbare Informationsinfrastruktur bereitzustellen. Jede Führungskraft, die Big Data Technologien für Sarbanes-Oxley oder Basel II Berichtswesen einsetze, behielte ihren Job nicht mehr lange. Das sind deutliche Worte für eine klare Abgrenzung beider Welten. Dabei ist Inmon nicht irgendwer: 2007 zählte ihn Computerworld zu den zehn wichtigsten IT Persönlichkeiten der letzten 40 Jahre.
Exakt zur selben Zeit trat Ralph Kimball, neben Inmon sicherlich der einflussreichste Data Warehouse Protagonist, genau im Umfeld besagter Cloudera Offensive für den Einsatz von Hadoop als Data Warehouse Plattform ein. Dabei lobte er Flexibilität, Performance und Kostenersparnis für zukünftige Hadoop Data Warehouses und prognostizierte diesem Ansatz ein großes Potential.
Nun vertraten Inmon und Kimball schon in den Neunzigern sehr unterschiedliche Ansätze, wie beispielsweise Top-Down vs. Bottom-Up oder Normalform- vs. Dimensionale Modellierung), die sich aber in der Praxis glücklicherweise durchaus nutzbringend ergänzten und damit die meisten aktuellen Data Warehouses stark beeinflusst haben. Der neue Widerstreit von Kimball und Inmon ist gleichermaßen charakteristisch für die aktuelle Diskussion rund um Data Warehouse und Big Data. Und so bleibt zu hoffen, dass er einen gleichermaßen positiven Effekt auf zukünftige Lösungsansätze in diesem Umfeld haben wird wie frühere Auseinandersetzungen.
Um zu verstehen, welche fachlichen Gründe zu diesen offenbar diametral entgegengesetzte Meinungen führten, ist zunächst ein Blick auf „herkömmliche“ Data Warehouses notwendig.
Das klassische Data Warehouse
Data Warehouses werden meist auf einer relationalen Datenbank betrieben. Die darin gespeicherten Daten werden mittels SQL gelesen und verarbeitet. Für die Aufbereitung in Richtung Anwender, den so genannten Data Marts, sind zum Teil auch spezielle multidimensionale OLAP-Datenbanken im Einsatz. Beiden Technologien sind für viele typische Anwendungsfälle eines Data Warehouses bestens geeignet – beispielsweise für betriebswirtschaftliches Berichtswesen als auch Controlling. Relationale Datenbanken bieten durch die Möglichkeit, jederzeit Daten miteinander zu verbinden (Joining) die nötige Flexibilität für Ad-hoc-Abfragen – selbst bei völlig neuen Anforderungen. Zudem ist die Abfragesprache SQL leicht zu erlernen und wird von jeder etablierten BI- und Reporting-Software direkt unterstützt. Relationale Datenbanken gewährleisten außerdem prinzipiell Datenkonsistenz, Hochverfügbarkeit sowie eine meist akzeptable Verarbeitungsgeschwindigkeit auch für große, strukturierte Datenmengen.
Bild 1: Beispiel einer typischen DWH Architektur mit „Inmon-Core“ und „Kimball-Marts“.
Viele Anwender arbeiten mit Daten sehr interaktiv. Sie filtern, summieren und klappen Hierarchieebenen auf und zu, genauso wie sie es beispielsweise von den aus Excel gewohnten Pivot-Tabellen kennen. Geschieht dies aber mittels SQL auf sehr großen Datenmengen und werden dabei zahlreiche Tabellen miteinander verbunden, ist schnell mit Wartezeiten im zwei- und dreistelligen Sekundenbereich zu rechnen. Hier kommen traditionell multidimensionale OLAP-Datenbanken ins Spiel. Sie strukturieren die Daten aus fachlicher Sicht sehr stark vor und bilden somit detailliert kundenspezifische Geschäftsmodelle ab. Sie unterscheiden Kennzahlen von Dimensionen, bilden Hierarchien auf Stammdaten und vor allem: Sie stellen Informationen bereits über viele Verdichtungsstufen vorkalkuliert und auf hohe Abfragegeschwindigkeit optimiert bereit. Zum Beispiel kann so auf Umsätze je Land und Produktgruppe direkt zugegriffen werden ohne die Kennzahlen aus den einzelnen Bestellpositionen für jede Abfrage immer wieder neu zu kalkulieren. Sind keine sekunden- oder minutenaktuelle Daten erforderlich ist beispielsweise eine tagesaktuelle Kalkulation weitaus effizienter als die permanente Neuberechnung aller Summen für jede einzelne Abfrage. Dies gilt unabhängig von der eingesetzten Technik.Viele Benutzer aus den Fachbereichen kommen damit sehr gut zurecht. Der Siegeszug von RDBMS und MOLAP in den vergangenen 20 Jahren war also alles andere als zufällig.
Beide Technologien präsentieren Daten in einem vereinheitlichten und stabilen Modell, was den Anwendern eine jederzeit verständliche und verlässliche Datenbasis für fachliche Fragestellungen bietet und diese Fachlichkeit gleichzeitig durch das Modell unterstützt. Die manchmal beschworene Unzufriedenheit der BI-Anwender ist dabei weniger auf die eingesetzte Technik sondern meist auf ungenügende Modellierung, vernachlässigte Kommunikation, fehlende fachliche Dokumentation oder unzureichende Datenqualität zurückzuführen.Kurz gesagt, der Einsatz von relationalen Datenbanken und MOLAP Data Marts ist für die meisten heute gebräuchlichen Data Warehouse Anwendungsfälle offenbar eine gute Wahl. Durch die Einführung von In-Memory-Techniken innerhalb relationaler Datenbanken in den letzten 2-3 Jahren wurden die Einsatzmöglichkeiten in Bezug auf Aktualität und Abfrageperformance sogar noch deutlich verbessert.
Die Grenzen klassischer Data Warehouses
Konventionelle Data Warehouse Lösungen haben aber trotz allem zahlreiche Einschränkungen. So wird es für RDBMS- und MOLAP-Datenbanken schwierig, wenn es um unstrukturierte Daten wie Dokumente, Filme und Audiodateien (Diese Informationen sind natürlich schon strukturiert, jedoch nicht in einer Form, die herkömmliche, sprich relationale Auswertungen und Abfragen auf die gespeicherten Daten erlaubt.) oder um Daten mit sich häufig ändernder oder nicht vordefinierter Struktur geht. Zu letzteren gehören auch Daten, die ihre Struktur implizit mitbringen, wie zum Beispiel XML. So hat übrigens Bill Inmon selbst in seiner DW2.0 Beschreibung die Bedeutung unstrukturierter Daten für Data Warehouses besonders hervorgehoben. Für einen Teil dieser Anforderungen gibt es seit einiger Zeit jedoch auch sinnvolle RDBMS-Erweiterungen.
Herkömmliche relationale oder MOLAP Datenbanken sind nicht darauf optimiert, zigtausende oder gar Millionen einzelner Transaktionen pro Sekunde zu bewältigen, wie sie zum Beispiel bei der zeitnahen Verarbeitung von Maschinen-, Sensor- oder Social-Media-Daten anfallen können. Dabei ist nicht der Datendurchsatz problematisch, denn selbst auf einem einfachen PC können heute zigtausend Datensätze pro Sekunde in ein RDBMS geladen und mit anderen verbunden werden. Schwierig ist es vielmehr, jeden Datensatz einzeln zu verarbeiten, also die Daten in Echtzeit zu „streamen“. Durch diese Vereinzelung werden zusätzliche Ressourcen verbraucht und die durch Konsistenzregeln bedingten „Flaschenhälse“ sind bei relationalen Datenbanken naturgemäß stark ausgeprägt. Aber auch hier öffnen sich erste Hersteller langsam neuen Verfahren, wie beispielsweise Microsoft mit den SQL-Server 2014 In-Memory OLTP Features.
Falls riesige Datenmengen ausgewertet werden müssen, ist auch mit höheren Antwortzeiten von Benutzerabfragen auf gängigen relationalen Datenbanken zu rechnen. Sind hohe Datenmengen feinster Granularität, wie beispielsweise „Call-Data-Records“ bei Telefondienstleistern, zu verarbeiten, sind mit MOLAP-Lösungen gute Antwortzeit nur noch schwer erreichbar. Darüber hinaus kommt es vor, dass die Zeitnähe von Abfragen eine Vorverdichtung sogar verhindert oder drängende Anforderungen auf großen Beständen Ad hoc umgesetzt werden müssen. Um die daraus resultierenden Antwortzeiten aus von mehreren Stunden auf Minuten oder Sekunden zu reduzieren, sind andere technische Ansätze notwendig.
Die reine Menge an Daten ist nur selten eine unüberwindliche technische Grenze für relationale Datenbanksysteme respektive große Datenbank-Cluster. Allerdings führen sie im hohen Terabyte- oder im Petabyte-Bereich dazu, dass administrative Standardverfahren – wie beispielsweise Backup oder komplexere Migrationen von Datenstrukturen – nicht mehr nach gewohntem Muster durchgeführt werden können ohne die Betriebsfähigkeit spürbar einzuschränken.
Nicht zuletzt spielen die Lizenz-, Support- und Hardwarekosten bei moderner, leistungsstarker RDBMS- oder MOLAP-Software für den Einsatz in Data Warehouse eine erhebliche Rolle. Hier werden gerade bei besonders großen Datenmengen Möglichkeiten zur Kostenersparnis zunehmend attraktiver.
Bei der Verarbeitung großer Mengen unstrukturierter oder uneinheitlich strukturierter Daten, hohen Einzeltransaktionsraten, bei gleichzeitiger Forderung nach kurzen Latenz- und Antwortzeiten bei Ad-hoc-Abfragen stoßen konventionelle DWH-Lösungen an Grenzen. Auch die laufenden IT-Kosten lassen sich durch den bloßen Einsatz von Data Warehouses nur begrenzt senken. Um diesen Anforderungen dennoch in Summe gerecht zu werden, kommen neue Technologien ins Spiel.
Grenzenlose Freiheit …
… sowohl bei Datenstrukturen als auch Datenmengen bieten NoSQL-Datenbanken. Viele dieser Systeme fokussieren auf Daten ohne fest vordefinierte Spalten. Somit wird es möglich, neue Datenstrukturen auch im laufenden Betrieb aufzunehmen. Zudem ermöglichen sie geringe Latenz-Zeiten bei der Verarbeitung hoher Transaktionsmengen. Damit eignen sie sich für Web-Applikationen mit zehn- oder hunderttausenden gleichzeitiger Nutzer ebenso wie für die zeitnahe Verarbeitung großer Datenströme – wie sie beispielsweise in Social-Media-Plattformen, technischen Produktionsanlagen oder dem „Internet of Things” (IoT) entstehen.
Die schnelle Verarbeitung riesiger Mengen beliebig strukturierter Einzeldateien in Batch-Prozessen wird dagegen von Apache Hadoop dominiert. Es handelt sich dabei um ein Framework zur Realisierung verteilter Aufgaben auf verschiedenen Rechnersystemen. Ein Zusammenschluss zahlreicher darauf aufsetzender Softwareprodukte bildet das so genannte „Hadoop-Ecosystem“. Dafür existieren inzwischen zahlreiche, zum Teil auch kommerzielle Distributionen – unter anderen auch die des eingangs zitierten IT-Spezialisten Cloudera. Solche Distributionen beinhaltet neben Hadoop auch NoSQL-Datenbanken, Orchestrierungs-, Scripting-, Programmier-, Analyse- und Datenintegrationswerkzeuge und Vieles mehr.
… oder freie Wahl der Grenzen?
Dass dabei einzelne Komponenten oft unabhängig voneinander entwickelt werden, hat allerdings nicht nur Vorteile: Die Flexibilität der Lösungen ist zwar hoch und es gibt eine große Auswahl an spezialisierten Tools für jeden Einsatzbereich. Deren Zusammenspiel funktioniert aktuell jedoch noch keineswegs nahtlos. Außerdem sind viele Tools gegenwärtig noch in einem relativ frühen Entwicklungsstadium. Die für einen hohen Stabilitäts- und Reifegrad erforderliche Konsolidierung ist daher noch lange nicht abgeschlossen.
Um zu verstehen, warum diese „Big Data“ Technologien im Business-Intelligence-Umfeld zum Teil so hoch gehandelt werden, müssen wir einen Blick auf die besonderen Vor- und Nachteile werfen.
Apache Hadoop ist ein Framework, um auf sehr vielen einfachen, autonomen Rechnern in einem Netzwerk Programme auszuführen, die verteilt an gemeinsamen Aufgaben arbeiten. Hauptziel ist die möglichst lineare Skalierbarkeit auf praktisch unbegrenzt viele, kostengünstige Rechenknoten, oft auf einfacher PC Technik. Hadoop basiert auf einem speziellen Dateisystem namens HDFS (Hadoop File System). Damit werden Dateien auf den einzelnen Knoten verteilt gespeichert, also jeweils nur ein Teil einer Datei auf einem Rechenknoten (Tatsächlich werden alle Dateien aus Sicherheitsgründen auf mehreren Rechnern gespeichert – standardmäßig auf drei Maschinen.) abgelegt. Programme, die diese beliebig strukturierten Daten verarbeiten, tun dies nach speziellen Programmiermodellen für eine verteilte Verarbeitung.
Bild 2: Datenhaltung und Verarbeitung mittels Big Data Technologien aus Sicht des Hadoop-Ecosystems.
Solche Modelle, wie beispielsweise „MapReduce“ geben vor, wie Daten in einem Hadoop-Cluster möglichst effektiv gescannt, interpretiert, verdichtet und zusammengeführt werden.
Rasante Entwicklung
Neben allen Vorteilen neuer Werkzeuge steckt leider vieles, was in den relationalen Datenbanken über Jahrzehnte reifen konnte, noch in den Kinderschuhen. Während beispielsweise in RDBMS die optimalen Ausführungspläne für die Verarbeitung von SQL-Befehlen durch sogenannte „Optimizer“-Komponenten anhand zahlreicher Datenstatistiken automatisch errechnet und ausgeführt werden, bleibt die Zusammenstellung der optimalen Verarbeitungsmethodik unter den neuen Technologien heute zumeist noch dem Programmierer überlassen. Einige Tools, wie der SQL-zu-MapReduce-Konverter HIVE oder die Scripting-Engine PIG generieren zwar bereits optimierte Hadoop-Programme, sind dabei aber bei weitem noch nicht so effizient wie gängige Datenbank-Optimizer. Zudem laufen diese Programme üblicherweise im Minuten- oder Stundenbereich und sind nicht für die interaktive Arbeit gedacht.
Aber die nächste Generation von Big-Data-Programmen steht schon bereit: Neue Tools wie Apache Spark arbeiten direkt mit HDFS-Daten und optimieren sowohl Durchsatz aus auch Antwortzeiten durch effizienteres Prozessmanagement, spezielle Indexierung oder Caching-Mechanismen. In-Memory-Lösungen wie Impala entwickeln sich zu ernsthaften Alternativen für den interaktiven Einsatz im BI-Umfeld und Tools für plattformübergreifende Analysen wie Presto beziehungsweise kommerzielle Optionen wie DataVirtuality ermöglichen die Integration unterschiedlicher Ansätze zu einer gemeinsamen, SQL-kompatiblen Sicht.
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 folgende Liste zeigt mögliche Lösungsansätze mit diesen Technologien an konkreten Beispielen 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 aber leider heute 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 (Yahoo! hatte bereits 2011 Hadoop Cluster mit 42.000 Knoten mit mehr als 180 Petabyte Rohdaten in Betrieb.) 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 deutliche 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.
Schema vs. Schemalos
Freiheit in der Datenstruktur, also der Verzicht auf ein festes „Schema“ hat den wesentlichen Vorteil, viele verschiedene Sichten auf dieselben Grunddaten bereitstellen und diese Sichten auch jederzeit ändern zu können. Diese Freiheit ist aber stets mit der Notwendigkeit verbunden, alle Daten bei jedem Zugriff erneut zu interpretieren und in die gewünschte Sicht zu transformieren. Will man diesen ressourcenintensiven Aufwand nur einmalig beim Befüllen einer Struktur mit Daten betreiben, geht diese Freiheit zwar verloren, man gewinnt dafür aber deutlich an Effektivität und Effizienz bei häufiger Verwendung innerhalb einer bestimmten Sicht – eben eines „Schemas“. Verfechter eines festen Schemas („Schema on write“) verweisen auf die fachliche Orientierung und die Notwendigkeit, alle Anforderungen schon in der Planung intensiv zu durchdenken. Zudem muss die fachliche Interpretation von Daten ohnehin spätestens beim Analysieren geschehen – also auf Planungsseite zumindest ein „Schema-On-Read“-Ansatz verfolgt werden. Ein Pragmatiker hingegen setzt beide Verfahren nach ihrer Eignung ein und wägt Vor- und Nachteile sorgfältig gegeneinander ab. Aufwände und Risiken eines gegebenenfalls nötigen Technologiewechsels müssen bei dieser Herangehensweise mit einkalkuliert werden.
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ßen 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. Verteilten 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, zusammen mit über Jahre gesammelten Daten aus hunderten von Quellen kostengünstig speichern und auswerten – 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 erfahren, was in der Öffentlichkeit über ihn gesprochen wird (Social Media), welche Kunden die interessantesten sind (360 Grad-View), 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.
Abbildung 3: Einstiegsszenarien in die Big Data Informationslandschaft.
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.
Peter Welker, trivadis
