Big Data versus Data Warehouse

Koexistenzperspektive.

Der Einsatz von Big Data erweitert den wirtschaftlichen Nutzen des klassischen Data Warehousing. Doch vorab ist die Verarbeitung und Analyse riesiger Datenmengen eine technische Knacknuss.  

 

* Von Peter Welker

 

Der Begriff «Big Data» steht für den Hype in der Geschäftswelt ebenso wie für die Diskussionen über die Chancen und Gefahren der neuen riesigen Datenmengen. Jenseits dieser emotionalen Hülle geht es zunächst um Technik: 

Das Institut Gartner etwa beschreibt Big Data sinngemäß als höchst umfangreichen, veränderlichen, vielfältigen Informationsbestand, der innovative und kostengünstige Möglichkeiten der Informationsverarbeitung brauche, um neue, tiefgreifende Einsichten zu gewinnen und so bessere Entscheidungen zu ermöglichen (*1

Und McKinsey hebt in einer vielbeachteten Studie (*2 besonders auf den Umfang der Datenbestände ab, der oberhalb der Möglichkeiten herkömmlicher Datenbankwerkzeuge liege und somit neue Ansätze für das Verarbeiten, Speichern, Administrieren und Analysieren benötige.  

Auch der «Vater des Data Warehousing», der US-Informatiker Bill Inmon, schreibt in einem wegweisenden Blog-Eintrag «Big Data or Data Warehouse? Turbocharge your Porsche – buy an Elephant» (*3, Big Data sei lediglich eine Technologie. Data Warehouse hingegen sei eine Architektur. Inmon geht sogar noch weiter und warnt: Jede Führungskraft, die betriebswirtschaftliche Herausforderungen wie etwa Basel II oder SOX Reporting mittels Big Data-Techniken umsetze, behielte ihren Job nicht mehr lange. Auf der anderen Seite springt gleichzeitig Ralph Kimball – Erfinder der dimensionalen Modellierung und neben Inmon wohl der bekannteste Data Warehouse-Protagonist – gemeinsam mit dem Big Data-Softwareproduzenten Cloudera für den Einsatz von Big Data Technologie im Data Warehouse in die Bresche (*4.

Wie passt das alles zusammen? Alle Experten sind sich einig, dass Big Data aus Technik und Methoden besteht, die über das hinausgehen, was herkömmliche, also relationale und multidimensionale, Datenbanken sowie die gängigen Analysewerkzeuge bei vertretbaren Kosten leisten können. 

Über die richtige Nutzung der Technik aber gibt es konträre Meinungen. Darum gilt es, erst einmal die Unterschiede zwischen «herkömmlichen» und Big Data-Techniken zu verstehen, ehe über die Umsetzung der BI-Anforderungen entschieden wird: Data Warehouses werden heute meist auf der Basis relationaler Datenbanken betrieben. Letzteren steht oft zusätzlich eine multidimensionale Datenbank zur Seite. Durch die Vorverdichtung von Daten ist sie für besonders schnelle Zugriffe durch Endanwender optimiert. 

Die Vorteile der relationalen Verfahren liegen neben der durch praktisch alle BI-Werkzeuge unterstützten Datenbanksprache (SQL) auch in der garantierten Konsistenz aller Informationen und in der Fähigkeit, die Daten auch nach deren Speicherung fast beliebig für die Beantwortung von Ad-hoc-Fragestellungen miteinander zu verbinden («Joining»). Das funktioniert auch für sehr große, strukturierte Faktenmengen.

Zusätzlich strukturieren multidimensionale OLAP(*5-Datenbanken die Informationen nach fachlichen Gesichtspunkten und unterstützen damit die BI-Endanwender. Der wesentliche Vorteil dieses Ansatzes ist die zum Beispiel tagesaktuelle Vorberechnung aller möglichen Zwischenwerte. Diese erlaubt sehr viel effizientere und schnellere Analysen als die permanente Neuberechnung aller Zwischenwerte bei jeder Abfrage. Dies gilt prinzipiell und unabhängig von der Technik. 

In Kombination und optimal genutzt ist dieses Duo heute sehr erfolgreich. Eine Alternative müsste also einiges mehr bieten und möglichst auch gleich deren bestehende Nachteile eliminieren.

Dennoch bergen die herkömmlichen relationalen Datenbanken viele Einschränkungen: Neben dem fehlenden Verarbeiten unstrukturierter Daten besteht ein Nachteil auch in der mangelnden Skalierbarkeit über Rechnergrenzen hinweg. Diese hängt maßgeblich mit der Konsistenzsicherung innerhalb des Datenbank-Clusters zusammen und führt nicht selten zu unerfreulichen Wartezeiten. 

Als kritisch gilt allerdings nicht der Datendurchsatz, denn selbst kleinste Datenbankserver können heute hunderttausende Datensätze pro Sekunde verarbeiten. Das Problem ist vielmehr, diesen Durchsatz auch bei besonders kurzen, kleinen Transaktionen aufrecht zu erhalten, wie sie etwa beim Streaming aktueller Social Media-Nachrichten entstehen. 

Diese Grenzen eliminiert auch der aktuelle Trend zu den In-Memory-Datenbanken nicht, der vor rund vier Jahren mit der Lösung SAP HANA begann. Er hat inzwischen in alle großen, kommerziellen Datenbanken Einzug gehalten. Die erhöhte Geschwindigkeit vor allem bei Abfragen ändert aber nichts an den Einschränkungen der In-Memory-Techniken.

Außerdem muss sich ein BI-Entwickler heute schon vor dem Speichern von Daten im Klaren sein, wie er die Daten strukturieren möchte. Dieses sogenannte «Schema on Write»-Paradigma bereitet vor allem dann Probleme, wenn die Daten zunächst nur gesammelt werden und erst bei der Abfrage über die Struktur entschieden werden soll («Schema on Read»).Hohe Lizenz- und Supportkosten vor allem bei umfangreichen Datenbeständen können ein Grund dafür sein, nach günstigeren Big Data-Alternativen zu suchen. 

 

Die Alternativen mit Hadoop & Co...
Auf der Basis dieser Erkenntnisse gibt es für Unternehmen zwei Eckpfeiler der Big Data-Technologien: sogenannte NoSQL–Datenbanken («strukturierte Datenspeicher») und das System Hadoop. 

Viele NoSQL-Datenbanken erlauben das Speichern von Daten ohne fest vordefinierte Spalten und unterstützen damit permanente Strukturänderungen besser als relationale Datenbanken. Zudem wird die Datenkonsistenz meist der Performance «geopfert». Die Echtzeitverarbeitung einzelner Werte skaliert damit annähernd linear und auch über hunderte Rechenknoten hinweg. Dafür ist die Konsistenz aber nicht zu jedem Zeitpunkt hundertprozentig garantiert. 

Anwender müssen also damit rechnen, dass nicht alle gespeicherten Daten sofort für Analysen zur Verfügung stehen und mit einem gewissen Aktualitätsverzug bei Abfragen leben. Für Order-Processing im Handel etwa ist dieses Verfahren daher nicht geeignet, aber durchaus für viele analytische Fragestellungen bei großen Datenmengen mit permanenten Ergänzungen.

Geht es hingegen darum, beliebige Daten auch im Petabyte-Bereich besonders kostengünstig zu speichern und mittels Batchprozessen «en gros» zu verarbeiten, kann Hadoop die richtige Wahl sein. Hadoop ist ein Dateisystem das beliebige Informationspäckchen auf vielen, kostengünstigen kleinen Rechnern verteilt speichert. Programme, die damit arbeiten, verteilen Ihre Arbeit gleichermaßen auf diese Rechenknoten, so dass im besten Fall auch hier linear skaliert wird. 

Das Hadoop-System enthält zahlreiche Funktionalitäten. Diese beinhalten unter anderem passende NoSQL-Datenbanken, Orchestrierungs-, Scripting-, Programmier-, Analyse- und Datenintegrationswerkzeuge. Sie eigenen sich daher als Kern einer unternehmensübergreifenden Big Data-Infrastruktur besonders gut.

 

… und deren Nachteile.
Doch Hadoop und NoSQL bergen auch Herausforderungen: Sie bestehen aus Dutzenden von IT-Werkzeugen. Diese werden oft von unterschiedlichen Entwicklergruppen gepflegt und sind hinsichtlich ihres Reifegrads und der Supportqualität sehr uneinheitlich. Viele der Tools befinden sich zudem in einem sehr frühen Entwicklungsstadium. Die Anbindung an die gängigen BI-Frontends ist zwar möglich. Aber bei Umfang und Effektivität der Integration liegen die neuen Technologien noch weit hinter relationalen und multidimensionalen Data Warehouses. 

Daher benötigen Organisationen, die eine Big Data-Plattform betreiben, nicht nur eine Menge zusätzlichen Know-hows. Sie müssen auch wissen, dass sie das klassische DWH heute und in nächsten Zeit damit nicht einfach ersetzen können. 

Darüber hinaus fehlt es derzeit noch an vielem, was in klassischen IT-Werkzeugen seit Jahrzehnten permanent verbessert wird: guten Optimizern (*7, ausgefuchsten Administrations- und Monitoring-
funktionen oder den einfachen, aber effizienten Möglichkeiten für Ad-hoc-Analysen.

Die Fähigkeiten von Hadoop, NoSQL und Co. gehen heute bei Skalierbarkeit und Flexibilität über die Grenzen relationaler und multidimensionaler Datenbanken hinaus. Das allein qualifiziert sie aber längst nicht als Ersatz für die klassische Data Warehouse-Welt. Reifegrad, Stabilität und Handhabung werden sicherlich besser werden. Aber ihre grenzerweiternden Eigenschaften verringern den Nutzen für zahlreiche grundlegende Business Intelligence-Anforderungen..

 

Plädoyer für hybride Architekturen.
Weil das Ziel das möglichst nahtlose Zusammenspiel aller Plattformen ist, werden Aufgaben und Zuständigkeiten in den neuen, hybriden Systemarchitekturen je nach technischer Eignung und Kosten bestmöglich auf die verfügbaren Technologien verteilt. 

Für Verbindung und Datenaustausch sorgen Konnektoren und Integrationswerkzeuge. So können gigantische Mengen feingranularer Informationen auf Hadoop, weniger detaillierte hingegen fachgerecht aufbereitet in relationalen und multidimensionalen Data Warehouses liegen. 

Bei Bedarf werden beide Datenquellen gemeinsam genutzt. Entsprechend können hochgradig strukturierte Daten anwendergerecht in relationalen Datenbanken angeboten werden, während Data Scientists aus Gründen der Flexibilität ihre Analyseplattform auf Hadoop und NoSQL betreiben und dabei das Data Warehouse als Quelle nutzen. 

Das Ideal ist der «Information Hub», in dem technologieübergreifend alle Informationen des Unternehmens in jeweils geeigneter Form, Aktualität und Performance für jedes IT System und jeden BI-Anwender verfügbar sind.  

 

* Peter Welker ist Senior Principal Consultant und Partner bei Trivadis. Der studierte Medizininformatiker arbeitet seit 20 Jahren im Bereich diverser Datenbanken wie etwa Oracle oder MySQL.

 
_________
 
(*1 http://www.gartner.com/it-glossary/big-data/ 
(*2 http://www.mckinsey.com/insights/business_technology/big_data_the_next_frontier_for_innovation
(*3 http://www.forestrimtech.com/big-data-vs-data-warehouse
(*4 http://www.cloudera.com/content/cloudera/en/resources/library/recordedwebinar/building-a-hadoop-data-warehouse-video.html 
(*5 Online Analytical Processing
(*6 Das „No“ in NoSQL steht heute für “not only”
(*7 Datenbankkomponente, die den schnellsten Datenzugriffsweg berechnet und ausführt 
  

 

Quelle: BUSINESS INTELLIGENCE MAGAZINE, www.bi-magazine.net 
© ProfilePublishing Germany GmbH 2014_2015. Alle Rechte vorbehalten. 
Vervielfältigung nur mit Genehmigung der ProfilePublishing Germany GmbH

Business Intelligence Magazine: Springe zum Start der Seite