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- versus 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. Beide 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.

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 oder um Daten mit sich häufig ändernder oder nicht vordefinierter Struktur geht. Die Informationen sind natürlich schon strukturiert, jedoch nicht in einer Form, die herkömmliche relationale Auswertungen auf die gespeicherten Daten erlaubt.
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 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 zu Beeinträchtigungen. So können 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 Latenzzeiten 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[1] Rechenknoten abgelegt. Tatsächlich werden alle Daten aus Sicherheitsgründen auf mehreren Rechnern gespeichert. Programme, die diese beliebig strukturierten Daten verarbeiten, tun dies nach speziellen Programmiermodellen für eine verteilte Verarbeitung.

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 als 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.