Raschwachsende Datenmengen stellen Unternehmen sowohl imoperativen ITBetrieb als auch bei BI-Analysen und anderen Formen des DataWarehousing vor neue Herausforderungen. Die technischen Lösungen sollten auf die Spezifika dieser Bereiche zugeschnitten sein.

Wo Tauben sind, fliegen Tauben hin, sagt der Volksmund. So mancher CIO denkt beim Datenmanagement vielleicht an dieses Sprichwort: Die Datenexplosion trifft vor allem die Unternehmen, die ohnehin hohe Bestände verwalten müssen. So hat das Marktforschungsunternehmen IDC im vergangenen Jahr festgestellt, dass große Datenbanken besonders schnell wachsen: 72 Prozent der Unternehmen mit Datenbanken von 1,5 Terabytes oder mehr haben Zuwachsraten von 20 Prozent pro Jahr, 45 Prozent von ihnen sogar mehr als 40 Prozent.

Die Ursachen der Datenexplosion

Die Ursachen liegen im Transaktionswie im Data-Warehouse-Bereich. Die operativen Anwendungen müssen immer größere Datenmengen verarbeiten. So werden beispielsweise in Telekommunikations-Unternehmen alle Informationen, die ein Telefonat beschreiben wie Nummer, Adressat, Dauer etc. in CDR-Tabellen (Call Detail Records) erfasst, die ohne weiteres einige Milliarden Datensätze enthalten können. Sie sind dann Grundlage für die Rechnungsstellung und andere Anwendungen. Oder nehmen wir den Handelssektor. Hier dient eine Flut an Kassen-, Verkaufs-, Bestands- und Prognosedaten in ähnlicher Größenordnung als Grundlage für Anwendungen für Warenwirtschaft, Lagerverwaltung und Logistik oder Bedarfsplanungen. Andere Branchen stehen vor vergleichbaren Herausforderungen. Noch schneller wachsen die Datenmengen beim Data Warehousing. Hier werden immer mehr historische Daten aufbewahrt, die für detaillierte Business-Intelligence-Analysen genutzt werden. Oft werden sie auch mit Fremddaten kombiniert. Beispielsweise beziehen Banken Unmengen von Marktinformationen von Datenfeed-Anbietern, die sie in Form von Zeitreihen festhalten und bei Bedarf analysieren, um die genauen Ursachen von Börsenausschlägen und andere Muster zu erkennen. Das ist insbesondere für das Risikomanagement wichtig. Beim Algorithmic Trading müssen sie Realtime- und historische Daten in Sekundenbruchteilen gemeinsam analysieren. Zu den klassischen strategischen und taktischen BI-Analysen, die primär Daten der Vergangenheit betrachten, kommt zunehmend operationale BI. Sie beobachtet Entwicklungen möglichst zeitnah, um bei Problemen schnell korrigierend einzugreifen. Dadurch strömen weitere große Mengen operationaler Daten in die Analyse-Datenbank. Die Folge: Die Datenmenge eines durchschnittlichen Data Warehouses wächst jährlich um mehr als 125 Prozent. Volumina im Terabyte-Bereich sind vielfach die Regel. Zu den quantitativen kommen neue qualitative Herausforderungen. Der Anteil unstrukturierter Datentypen nimmt zu: Dokumente in verschiedenen Formaten, Bilder, Grafiken, digitale Video und Tonaufzeichnungen, HTML-Seiten und andere - Analysten sprechen von hunderten von Dateiformaten. Treibende Kraft sind vor allem Compliance-Anforderungen wie SOX oder Basel II. Insbesondere die Unmenge an E-Mail-Anhängen lässt den Anteil dieser Datentypen immer schneller wachsen; so müssen Unternehmen in Deutschland handels- und steuerrechtlich relevante E-Mails - je nach Industrie - bis zu 10 Jahren aufbewahren und jederzeit in angemessener Frist verfügbar machen.

Die Konsequenzen großer Datenbanken

Im operativen Betrieb verschlechtert sich infolge der wachsenden Menge und Komplexität der Daten und der damit verbundenen Indexe die Performance von Anwendungen. Jede Transaktion, jede Abfrage muss alle Daten einer Tabelle durchlaufen. Beispielsweisewerden bei der Rechnungsstellung in der CDR-Tabelle eines Telekommunikationsunternehmens oft Milliarden von Datensätzen gelesen, nur um Daten eines einzigen Kunden in einem Monat zu selektieren. Gleichzeitige Operationen gegen verschiedene Dateninstanzen in der gleichen Tabelle können mit anderen Datenbank-Operationen zusammenstoßen und zu Konflikten beim Zugriff auf Seiten, Locking oder ähnlichem führen. Prozesse werden langsamer oder stoppen ganz. Konflikte entstehen außerdem zwischen OLTP- und DSS-Betrieb. Betroffen sind auch Management und Pflege der Datenbank im operativen Betrieb. Prüfungen, etwa Fehleranalysen im Datenbereich, das Update großer Index-Tabellen und die Aktualisierung von Statistiken dauern erheblich länger. Die Backup-Zeitfenster – in vielen Unternehmen nur wenige Stunden in der Nacht – reichen nichtmehr aus. Auch die Verfügbarkeit der Daten wird schlechter. Damit entstehen wiederumneue Probleme im DBA-Bereich. In der genannten IDC-Studie gaben mehr als 50 Prozent der Unternehmen mit einer Datenbank-Größe über 1,5 TB an, dass sie zu wenige DBA haben und ihre Mitarbeiter überlastet sind. Die Personalkosten steigen proportional zu Größe und Komplexität der Datenbank. Im Data-Warehouse-Bereich wird die Datenexplosion insbesondere dort zum Problem, wo die Datenbank-Technologie allein auf den Transaktionsbetrieb ausgerichtet ist. Ein solches System benötigt gegenüber den Rohdaten zusätzlichen Platz für Indexe und Verwaltung. Um 1 Terabyte an Nettodaten zu speichern, werden in der Regel 2,5 bis 6 Terabytes belegt. Die Folge: Die Speicherkosten steigen rapide. Das Datenvolumen wächst heute schneller als die Verbesserung des Preis-Leistungs-Verhältnisses bei magnetischen Datenträgern. Eine zweite Folge sind sehr lange Abfragezeiten. Wegen der zeilenorientierten Speicherung muss in transaktionsorientierten Datenbanken immer jeder Datensatz komplett gelesen werden. Versuchen Unternehmen, durch Voraggregation der zu analysierenden Daten Abhilfe zu schaffen, schränken sie die Flexibilität von Ad-hoc-Abfragen erheblich ein. Eine weitere Konsequenz: Immer mehr Wissen eines Unternehmens (je nach Untersuchung zwischen 35 und 75 Prozent) liegt in einer unstrukturierten Form vor. Diese Daten werden meist separat in sequentiellen Dateien gespeichert. Damit steht ihnen die ausgereifte DBMS-Funktionalität wie Transaktionskonzept, Rechte-Schemata oder Sicherungskonzepte nicht zur Verfügung. Nicht zuletzt verschärft die Datenexplosion ein Problem, dessen Bedeutung in letzter Zeit immer deutlicher erkannt wird: Speicherung und Verarbeitung der riesigen Bestände erfordern immer mehr Rechnerleistung, Plattenlaufwerke und Kühlsysteme – was einen hohen Energiebedarf und zusätzliche CO2-Emissionen nach sich zieht. Die Debatte um „Green IT“ hat hier eine wesentliche Quelle.

Lösungen

Viele Unternehmen greifen zur einfachsten (und teuersten) Lösung, um der Datenflut Herr zu werden: mehr Hardware in Form von zusätzlicher Memory, schnelleren Prozessoren und mehr Plattenplatz. IDC dazu: „Die Herausforderung mit Hardware zu erschlagen hilft nur eingeschränkt, da dies nicht direkt die Ursachen der Performance-Probleme löst. Um diese wirklich zu adressieren, sind grundlegende Verbesserungen der DBMS-Technologie notwendig.“ Der wichtigste Grundsatz lautet: Nur auf solche Daten zugreifen, die tatsächlich benötigt werden. Dazu sind getrennte technische Lösungen je nach den spezifischen Anforderungen von OLTP-Betrieb und Data Warehousing sinnvoll.

OLTP-Datenbanken: Partitionierung

Im operativen, transaktionsorientierten IT-Betrieb lässt sich die Effizienz sehr gut durch die Partitionierung großer Datenbestände steigern. Dabei werden große Tabellen logisch in kleinere Einheiten unterteilt, ebenso die Indexe. Die Daten kann man semantisch partitionieren, das heißt ihre Platzierung in den Partitionen nach ihrem Inhalt spezifizieren (etwa: Kundennamen A-C in Partition 1, D-F in Partition 2 etc.). Hierfür gibt es wiederum verschiedene Methoden. Die Partitionen können separat verarbeitet und gemanagt werden. Abfragen und Updates greifen nur auf diejenigen Partitionen zu, die sie tatsächlich benötigen. So verbessert sich die Performance. Auch Management und Pflege der Datenbank sind einfacher, wenn die betreffenden Operationen nur noch Teilmengen der Daten adressieren. Zum Beispiel besteht bei der Partitionierung einer Tabelle nach Monaten die Möglichkeit, ein Update der Statistiken nur bei den aktuellen letzten drei Monatsdaten durchzuführen. Ältere Daten ändern sich wenig und die Statistik ist aktuell. Parallele Schreib-, Lese- und Maintenance-Operationen verursachen weniger Lock- und Ressourcenkonflikte, wenn sie sich an verschiedene Partitionen richten. So können etwa in einem logischen Bereich Indexe aktualisiert werden, während in anderen Abfragen laufen und dritte reorganisiert werden. Der DBA kann die Aufgaben entsprechend planen. Auch das Backup kann parallel durchgeführt und damit beschleunigt werden. Ebenso erhöht sich die Verfügbarkeit der Daten.

Data Warehouse: Spaltenweise Speicherung

Die Grundidee Partitionierung – Reduktion der zu lesenden Daten – gilt auch für Data Warehouses. Allerdings ist hier eine andere technische Methode sinnvoller, denn bei Analysen – wie etwa Zeitreihenbetrachtungen – wird meist die komplette Datenbasis benötigt, um Zusammenhänge zu erkennen. Deshalb empfiehlt sich eine Architektur, die sich von OLTP-Datenbanken grundsätzlich unterscheidet: Speicherung und Zugriff erfolgen nicht nach Zeilen, sondern Spalten. Da sich Abfragen generell auf Spaltenwerte beziehen, hat dieses Vorgehen zwei entscheidende Vorteile: Weil nur diejenigen Daten gelesen werden, nach denen gesucht wird, reduziert sich die Zahl der I/Os. Zugleich lassen sich die Daten besonders gut komprimieren, weil alle Daten einer Spalte vom selben Typ sind. In einer Zeile hingegen gibt es immer verschiedene Datentypen; der Kompressions-Algorithmus wird somit auf Basis des kleinsten gemeinsamen Nenners gewählt. Die Datenbank kann komplett indexiert werden, da jedes Feld automatisch als Abfrageschlüssel dient. Dadurch erhält man eine sehr hohe Flexibilität. Zusätzliche Index-Dateien, die die Datenbank aufblähen, sind überflüssig. Diese Merkmale reduzieren den Speicherbedarf und erlauben eine viel schnellere Auswertung der Daten. Beides wiederum senkt den Energieverbrauch – ein wesentlicher Beitrag zum Ziel der Green IT.

THEO RULAND

Diesen Artikel finden Sie auch in der Ausgabe April 2008 des it management.