Big Data oder Data Warehouse

Social Media, Internet of Things: Wir leben in einer Ära rasch wachsender Datenberge. Haben konventionelle Data-Warehouse-Lösungen damit ausgedient? Übernimmt Big Data das Zepter? [...]

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 für Controlling.

Durch die Einführung von In-Memory-Techniken innerhalb relationaler Datenbanken in den letzten zwei bis drei Jahren wurden die Einsatzmöglichkeiten in Bezug auf Aktualität und Abfrageperformance sogar noch deutlich verbessert.

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 einzelne 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 Antwortzeiten 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 Tera-byte- 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, ohne die Betriebsfähigkeit spürbar einzuschränken.

Bei der Verarbeitung großer Mengen unstrukturierter oder uneinheitlich strukturierter Daten und hohen Einzeltransaktionsraten 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 in Summe dennoch 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, gleichzeitigen Nutzern 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.

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.

Der Autor Peter Welker ist Partner und Berater für Big Data und Data Warehousing bei Trivadis. Den kompletten Artikel finden Interessierte auf www.itwelt.at.


Mehr Artikel

Die Teilnehmer des Roundtables (v.l.n.r.): Roswitha Bachbauer (CANCOM Austria), Thomas Boll (Boll Engineering AG), Manfred Weiss (ITWelt.at) und Udo Schneider (Trend Micro). (c) timeline/Rudi Handl
News

Security in der NIS2-Ära

NIS2 ist mehr ein organisatorisches Thema als ein technisches. Und: Von der Richtlinie sind via Lieferketten wesentlich mehr Unternehmen betroffen als ursprünglich geplant, womit das Sicherheitsniveau auf breiter Basis gehoben wird. Beim ITWelt.at Roundtable diskutierten drei IT-Experten und -Expertinnen über die Herausforderungen und Chancen von NIS2. […]

Be the first to comment

Leave a Reply

Your email address will not be published.


*