Datenplattform der Zukunft

Data Warehouse - richtig modernisieren statt vorschnell abschalten

03.02.2016
Von 
Peter Welker verfügt über 25 Jahre IT-Projekterfahrung als Entwickler und Lösungsarchitekt. Er ist Partner und Berater für Big Data und Data Warehousing bei Trivadis. Als Autor verschiedener Fachbücher, regelmäßiger Referent und Keynote Speaker auf Data-Warehouse- und Datenbankkonferenzen ist er mit diesen Themen seit Jahren bestens vertraut. Darüber hinaus ist Peter Welker bei der DOAG für das Thema Big Data verantwortlich. Normal 0 21 false false false DE X-NONE X-NONE

Die Data Warehouse Technik

DWHs werden heute fast ausschließlich auf relationalen Datenbanken betrieben und Daten werden mittels SQL gelesen und verarbeitet. Für die Data Marts sind zum Teil auch speziell abfrageoptimierte multidimensionale OLAP-Datenbanken (Online Analytical Processing) im Einsatz. Beide Technologien sind für viele typische Anwendungsfälle eines Data Warehouse bestens geeignet, beispielsweise für betriebswirtschaftliches Berichtswesen oder Controlling. Relationale Datenbanken bieten durch die Möglichkeit, jederzeit Daten miteinander zu verbinden (Join) 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 und Multidimensionale Datenbanken gewährleisten zudem Datenkonsistenz, Hochverfügbarkeit, flexible und wirksame Sicherheitsmechanismen und Verfahren zur Sicherstellung eines wirksamen Datenschutzes sowie eine gute Verarbeitungsgeschwindigkeit auch für größere, strukturierte Datenmengen. Kein Grund also, sich aus der Komfortzone heraus zu wagen? Ganz im Gegenteil!

"Neue" Anforderungen

Verringerte Kosten und damit verbunden der Wunsch nach mehr Effizienz sind immer ein wesentlicher Treiber für Veränderungen, nicht nur im Umfeld von Data Warehouses. Hier haben sich in den vergangenen Jahren zahlreiche Ansätze etabliert. Dazu gehören Softwarelösungen zur Aufnahme fachlicher Anforderungen und deren möglichst einfache Überführung in technische Strukturen. Zudem sind hier Konzepte und Tools zur Modellierung von Datenstrukturen und Prozessen sehr hilfreich, welche dann eine weitreichende Generierung (statt manueller Entwicklung) von ETL Strecken ermöglichen, zumal sie den Aufbau und die Pflege der Dokumentation erleichtern und gleichzeitig die Komplexität der Data-Warehouse-Prozesse reduzieren können.

Im Rahmen neuer fachlicher und technischer Problemstellungen stehen aber vor allem die großen Themen und Trends der vergangenen Jahre im Blickpunkt. Dabei geht es um Tagesaktualität, unflexible Berichte, begrenzte Datenpools, zu große Datenmengen und Datendurchsätze beziehungsweise nicht einheitlich strukturierte Daten. Das sind alles Erfordernisse, die von einem herkömmliche Data Warehouse nicht, oder nur mit erheblichen Mehraufwand zu stemmen sind. Hier ein Überblick gängiger Anforderungen:

DWH operativ einsetzen: Immer mehr Unternehmen sehen das DWH nicht nur als Daten-Endpunkt, sondern als Teil weiterer operativer Prozesse. So kann es das Meldewesen bei Banken unterstützen, online Informationen für Portale bereitstellen oder CRM-Kundendaten analysieren, segmentieren und wieder ins CRM zurückspielen. Letzteres bildet einen sogenannten "Closed-Loop". Solch ein operativer Betrieb erfordert aber einige Zusatzanstrengungen. Zum Beispiel erhöht sich die nötige Systemverfügbarkeit deutlich. War es in der Vergangenheit vielleicht noch akzeptabel, wenn das DWH zwei oder drei Tage abgeschaltet war, ist plötzlich eine 24/7 Verfügbarkeit unabdingbar und stellt die DWH Architektur sowie die damit verbundenen etablierten Bewirtschaftungs- und Administrationsprozesse in Frage: Es gibt keine "keimfreien" Zeitfenster mehr für die ETL-Prozesse und die zulässige Zeit für das Restore eines Backups schrumpft von Tagen auf Stunden.

Wie schon beschrieben, steckt ein weiteres Problem operativer DWHs in der Datenqualität. Wo kleinere Abweichungen früher noch akzeptabel waren, werden plötzlich absolut exakte Zahlen benötigt. Ist eine höhere Verfügbarkeit manchmal noch durch mehr Hardware, teurere Softwarelizenzen und generelle Anpassungen an den Datenintegrationsmechanismen umsetzbar, gibt es bei der Datenqualität häufig nur eine Lösung: Jeden einzelnen Verursacher aufspüren und ganz gezielt praktikable Lösungen zur Korrektur oder Vermeidung der Fehler bauen - ganz wie bei der Programmierung der Quellsysteme selbst.

Self-Service: "Wenn ich das bei der IT in Auftrag gebe, warte ich ein halbes Jahr auf eine Lösung - dabei will ich doch nur ein paar hundert Zeilen aus meinem Excel-Sheet in meinen Bericht einbinden." So ähnlich klingen viele Begründungen für erste "U-Boot Aktivitäten" und den Aufbau diverser "Schatten-Lösungen" rund um das DWH. Fachbereichsanwender exportieren ganze Teile aus dem DWH in eigene, lokale Datenbanken und nutzen gängige Tools - gerne Excel - um die Daten für ihre Analysen zusammenzuführen. Dabei werden massenhaft Mechanismen zur Qualitätssicherung ausgehebelt, die DWH-Entwickler und andere IT-Mitarbeiter über lange Zeit mühevoll aufgebaut haben. Diese sind oftmals auch ein beliebter Grund für gegenseitige Schuldzuweisungen, wenn dabei etwas schiefgeht.

Dabei muss man den Fachanwendern im Grunde Recht geben. Ihre Anforderungen sind die Richtschnur für die Anstrengungen der IT. Hier heißt es Umdenken: Die Anforderungen an das Berichtswesen steigen permanent. Controller, Marketingmitarbeiter oder Vertrieb brauchen mehr Flexibilität bei Ihrer Arbeit. Und mehr Unterstützung durch DWH-affine Kollegen.

Ein organisatorischer Ansatz zur Lösung des Problems ist das BI Competence Center (BICC), in dem nicht nur die Mechanismen für flexiblere Arbeit mit den Daten aus dem Data Warehouse definiert und umgesetzt werden, sondern auch die richtigen Ansprechpartner zwischen Fachbereich und IT angesiedelt sind.

Ein technischer Ansatz heißt "Federation". Hier wird dem Anwender erlaubt, mehrere Quellen in einer Abfrage gemeinsam zu nutzen, also Data Warehouse und Excel-Sheet, ERP, CRM oder was auch immer benötigt wird. Die Einbindung zusätzlicher Datenquellen wird zwar von einigen Business-Intelligence-Frontends gut unterstützt. Zum Teil bildet aber eine zentrale Konfiguration, die nur Administratoren zugänglich ist und keine individuellen Quellen erlaubt, die einzige Möglichkeiten zur Einbindung. An dieser Stelle braucht es deutlich mehr benutzerspezifische Möglichkeiten.

Das größte Problem bei solchen verteilten Daten ist die Performance. Es ist schon schwierig genug, auf einer einzigen, homogenen Datenbank mit abfrageoptimierten Datenstrukturen eine gute Antwortzeit hinzubekommen. Der Zusammenschluss mehrerer unterschiedlicher Datenbanken über ein herkömmliches Netzwerk stellt eine noch wesentlich größere Herausforderung dar, speziell wenn mehrere sehr große Datenbestände über dieses Netzwerk verbunden (gejoined) werden müssen. Darum kann dieser Ansatz keine generelle Lösung sein, sondern sollte nur für besondere Anwendungsfälle eingesetzt werden. Solche Szenarien werden durch spezielle Federation-Software wie zum Beispiel Cisco Composite, Denodo, RedHat JBoss Teiid oder Datavirtuality unterstützt. Hier ist der Zusammenschluss sehr unterschiedlicher Datenquellen auf zentraler Ebene möglich. Diese Werkzeuge bieten zudem Abfrageoptimierung, Datenverteilungsanalysen beziehungsweise Caching-Mechanismen und somit bessere Chancen auf akzeptable Performance. Leider kann der "normale" Anwender auch hier meist nicht einfach "private" Datenquellen nach Bedarf hinzufügen. Immerhin sind aber weitere Datenquellen durch Administratoren in aller Regel innerhalb von Minuten oder Stunden integrierbar.

Ein weiterer Ansatz für Self-Service BI sind die sogenannten "Sandboxes": Lokale, benutzerspezifische Bereiche, oft innerhalb der zentralen Data Warehouse Plattform, auf denen benutzereigene Daten abgelegt werden können. Dieser Ansatz verringert das Risiko schlechter Antwortzeiten für Abfragen, lässt aber die Frage offen, wie individuelle Daten in die Sandbox kommen. Dafür braucht es wiederum spezielle Software für einfache Datenintegration. Open Source Anbieter solcher Tools - wie Pentaho oder Talend - sind in den Community-Editionen zwar kostenfrei und auch relativ einfach zu bedienen. Richtig endbenutzertauglich sind sie darum aber noch lange nicht. Oft kommen daher in der Praxis selbstentwickelte Dienste wie browser-basierte, automatisierte Textdatei-Uploads zum Einsatz.

Große Datenmengen: Bei besonders umfangreichen Datenmengen beispielsweise aus dem Internet-of-Things (IoT), aus Produktionsanlagen oder im Telekommunikationsumfeld denkt man gleich an Big-Data-Technologien wie Hadoop. Dabei sind viele analytische Anforderungen auch bei außerordentlich großen Datenmengen im dreistelligen Terabyte- oder sogar Petabyte-Bereich mit großen relationalen Datenbankclustern von Oracle, Teradata, Microsoft, IBM und anderen einfach und effektiv umsetzbar. Beim Einsatz hunderter CPU-Cores und mehrerer Terabyte RAM lassen sich auch mit herkömmlichen Techniken riesige Datenmengen effektiv bewegen, speichern und auswerten - mit durchaus passabler Performance. Allerdings fallen dabei oft enorme Kosten für Softwarelizenzen und Hardware an.

Besonders der Umgang mit uneinheitlich strukturierten Daten wie Dokumenten, Multimedia-Dateien und Ähnlichen ist zudem nicht gerade die Stärke relationaler oder multidimensionaler Datenbanken. Bei Anforderungen außerhalb relationaler Strukturen - und da genügt es oft schon, jederzeit beliebige neue Attribute zu bestehenden Daten hinzufügen zu können - sind andere Lösungen wie Hadoop oder Wide-Column NoSQL Datenbanken zum Speichern deutlich besser geeignet. Das gilt insbesondere bei Anforderungen, bei denen die Strukturen jederzeit flexibel sind und erst bei der Analyse klar definiert werden müssen (Schema-On-Read) und nicht schon zur Zeit der Modellierung feststehen (Schema-On-Write).

Die Hersteller von DWH-Lösungen haben solche Anforderungen in den zurückliegenden Jahren verinnerlicht und bieten mittlerweile Systeme mit RDBMS, Hadoop/NoSQL und entsprechender Software zur Konnektivität zwischen beiden Welten an. Diese Lösungen sind heute allerdings noch recht limitiert und beschränken sich meist auf Werkzeuge für den Datenaustausch und übergreifende SQL-Abfragen. An der nahtlosen, plattformübergreifenden Verwaltung von Metadaten und anforderungsoptimiertem automatischem Komprimieren und Verschieben von Daten zwischen den Technologien (Data Lifecycle Management) wird gegenwärtig intensiv geforscht und entwickelt.

Ein ganz anderer Trend zum Umgang mit großen Datenmengen ist die Modellierung von Core-DWHs nach dem Data-Vault-Model. Dieses erlaubt eine größere Flexibilität bei den Datenstrukturen, eine sehr leicht verallgemeinerbare Vorgehensweise und wesentlich schnellere Befüllung des Cores, hat aber auf der anderen Seite eine beachtliche Inflation an Tabellen zur Folge und macht die Befüllung der Data Marts aus dem DWH-Core nicht unbedingt schneller oder einfacher.

Big Data & DWH

Egal ob es um hohe Kosten, umfangreiche Datenmengen, einen extremen Datendurchsatz oder Echtzeit-Anforderungen geht: Früher oder später kommen Big Data Technologien wie die Hadoop Plattform, Streaming Lösungen beziehungsweise NoSQL-Datenbanken ins Spiel. Und spätestens dann stellt sich die Frage nach zusätzlichem Know-how bei den DWH-Entwicklern. Die Implementierung von MapReduce- oder Spark-Jobs - sei es mittels Java, Scala oder entsprechender Scripting Engines - passt dabei oft nicht zur Expertise langjähriger Datenintegrationsspezialisten.

Unter anderem darum bauen Anbieter von Datenintegrationssoftware wie Informatica oder Oracle immer mehr Big-Data-Funktionalität in ihre Lösungen ein. Solche Werkzeuge können durch grafisch definierte Extraktions-, Lade- und Transformationsprozesse - wenn auch noch mit funktionalen Abstrichen im Hadoop-Bereich - wahlweise SQL-Befehle auf Datenbanktabellen oder Pig- und Spark-Scripts auf HDFS basierten Dateien ausführen und dabei auch NoSQL-Datenquellen und Change-Data-Capture-Prozesse integrieren. Letztere streamen die Änderungen aus ERP und CRM dann direkt beispielsweise ins Hadoop Filesytem HDFS oder Apache Flume. Die Datenintegration kann heute also sowohl auf traditionelle DWHs als auch auf Big-Data-Plattformen verteilt werden. Schon aus Gründen der Kosten und Skalierbarkeit sollten Unternehmen diese Optionen in ihre Überlegungen mit einbeziehen.