Die IBM DB2 als Basis für alle Daten: BI-Architektur

Eine überzeugende Vision für Business Intelligence (BI) sollte sich auf einen einfachen Satz ohne technischen Jargon oder Marketing-Schlagworte reduzieren lassen. Die BI-Vision von IBM lässt sich wie folgt ausdrücken: „Ziel ist, BI-Funktionen in die Datenbank zu integrieren und sie ausschließlich über offene Standardschnittstellen als Teil einer integrierten BI-Plattform zugänglich zu machen. Für weitere Schichten der BI-Architektur arbeiten wir mit Geschäftspartnern zusammen.“

Abb. 1: BI-Funktionalität hat fast alle Stufen der Anwendungshierarchie durchdrungen, sodass sich Kunden allmählich über Datenkonsistenz, Sicherheit und Performance Gedanken machen.

BI-Funktionen in die Datenbank integrieren

Die Feststellung, dass IBM BI-Funktionalitäten in die Datenbank integriert, ist nicht so trivial wie sie klingt. Viele BI-Anwendungen extrahieren große Daten-Volumina mithilfe einer einfachen SQL-Syntax aus dem Data Warehouse, bereiten sie in der Anwendungsschicht auf und filtern (oder bündeln) sie, um die gewünschte Granularität zu erreichen. Erst dann wenden sie die Funktionalität an, die die eigentliche Wertsteigerung darstellt. Client-Tools gehen oft genauso vor, ob der temporäre Cache nun ein Spreadsheet, OLAP-Würfel oder lokales Dateisystem ist. Viele Benutzeranwendungen ahmen dieses Modell nach, weil es das Vorbild ist, das die Entwickler am besten kennen.

IBM DB2 UDB hat sich stetig in die Richtung weiterentwickelt, BI-Funktionen innerhalb der Datenbank zu unterstützen. Zu diesen BI-Fähigkeiten gehören Data Mining, OLAP, ETL, geografische Analysen und komplexere Statistik- und Analysefunktionen für Regression, Kovarianz, Stichproben, Ranking, gleitende Kennzahlen etc. – im Folgenden als „BI-Funktionen“ bezeichnet.

OLAP-Tools eignen sich sehr gut für eine flexible Analyse des Unternehmens. Die Wirksamkeit von Marketing-Kampagnen hängt zum Beispiel von vielen Variablen ab, so dass ein vordefinierter Bericht vielleicht nicht alle benötigten Informationen zeigt. Aber wo beginnt man eine multidimensionale Analyse? Um den OLAP-Würfel abzusuchen oder ein Drill-Down durchzuführen, muss man erst wissen, wie die Attribute zu definieren sind. Wenn zum Beispiel die geografische Lage ein wichtiger Faktor für die Einschätzung der Wirksamkeit einer Marketing-Kampagne ist, sollte dann die hierarchische Gliederung auf Städte, Postleitzahlen oder sonstige Untergliederungen aufgebaut werden? Und sollten diese dann nach oben zu Bezirken, Ländern oder Regionen führen?

Die Mining-Funktionalität von DB2 lässt den Benutzer wichtige Dimensionen und Attribute automatisch erkennen und hierarchisch gliedern. Wenn sich herausstellt, dass die Bevölkerungsdichte eine deutliche Korrelation zu den Faktoren Marketing-Kosten und Verkaufszahlen aufweist, dann kann in DB2 eine Analysefunktion aufgerufen werden, die ein Diagramm der verschiedenen Stufen der Bevölkerungsdichte erzeugt. Wenn diese Stufen Attribute eines OLAP-Würfels sind, können Client-Tools ein Drill-Down anhand der verschiedenen Bevölkerungsdichten durchführen, um so einen Eindruck von der Wirksamkeit von Marketing-Programmen zu gewinnen.

Die Vorteile von BI-Funktionen in DB2 sind deutlich und vielfältig:
• Sie ermöglichen der Datenbank, genaue Daten mit der gewünschten Granularität an BI-Endpunkte (Anwendungen, Benutzer oder Tools) zu liefern.
• Sie verlagern einen größeren Teil der „Schwerarbeit“ (Scannen, Sortieren, Zusammenführen und Bündeln der Daten) auf die Ebene der Architektur, die speziell dafür geschaffen und optimiert wurde, den Warehouse-Datenbank-Server.
• Sie verringern die Menge an Daten, die durch das Netzwerk fließen.
• Sie setzen nicht so viele Daten den weniger sicheren Bereichen außerhalb des Firewalls aus.
• BI-Funktionen auf Basis derselben Daten, im selben DB2 Data Warehouse geben viel eher „eine einzige Version der Wahrheit“ für das gesamte Unternehmen wieder – unabhängig vom Tool oder der Anwendung des Endbenutzers.

BI-Funktionen als Teil einer integrierten Plattform ausschließlich über offene Standardschnittstellen zugänglich machen

Wenn es offensichtlich sinnvoll ist, die Warehouse-Datenbank für BI-Funktionen zu nutzen, warum führen dann so viele Tools und Anwendungen einen Großteil der Arbeit lieber selber aus? Oder anders gefragt: Warum fungieren so viele BI-Endpunkte als Datengroßhändler und nicht als Verbraucher?

Teilweise lässt sich dies auf die Entwicklungen aus einer Zeit zurückführen, in der sich sogar einfachste Hierarchien nicht in SQL ausdrücken ließen. Für multidimensionale Analysefunktionen wird seit langem eine spezielle Struktur bevorzugt: der MOLAP-Würfel (Multidimensional OnLine Analytical Processing) mit proprietären Speicherstrukturen und Schnittstellen. Data Mining-Algorithmen werden üblicherweise auf Dateien außerhalb der Datenbank angewendet. In diesen Beispielen werden die Daten vom Warehouse für eine Zwischenplattform aufbereitet und dort umstrukturiert, ehe die BI-Funktionen eingesetzt werden. Dies führt zu mindestens drei verschiedenen, voneinander abhängigen Datenstrukturen, die drei unterschiedliche Zeitpunkte widerspiegeln und auf drei Server-Plattformen verteilt sind– jede mit eigenen APIs (Application Programming Interface), Verwaltungsfunktionen und Optimierungstechniken. Die einzelnen Analyse-Silos spielen ihre Rolle zwar gut, das Verfolgen des Analysevorteils hat jedoch den grundlegenden Wert des Data Warehouse zunichte gemacht.

Kritische Abweichungen, die sich in einem großen OLAP-Würfel verbergen, können recht mühsam zu finden sein. Mining-Algorithmen für die Entdeckung von Abweichungen sind in der Lage, ungewöhnliche Werte automatisch hervorzuheben. In einigen Fällen können solche Unregelmäßigkeiten auf eine neue Geschäfts-Chance hinweisen, in anderen wiederum auf ein Problem, das unbedingt gelöst werden muss. DB2 Mining-Funktionen in der Datenbank können auf die gesamten Warehouse-Daten skaliert werden. So wird kein entscheidender Kundendatensatz übersehen, nur weil er erst eingefügt wurde, nachdem die Mining-Daten aus der Datenbank extrahiert wurden. Mit externen Mining-Tools, die auf autonomen Dateien basieren, ist dies praktisch unmöglich.

DB2 löst dieses Problem, indem die gesamten BI-Funktionen einschließlich Mining und OLAP auf denselben Datenstrukturen in derselben Datenbank auf derselben Warehouse-Ebene basieren. Selbst in einem föderierten DB2 Warehouse „sehen“ alle BI-Funktionen ein einziges logisches Schema, das von den Einzelheiten der Topologie der verteilten Daten abstrahiert ist.

Mit DB2 ist es möglich, Mining-Ergebnisse an ein anderes Berichts- oder OLAP-Tool weiterzuleiten. Zum Beispiel kann ein Analyst seine bevorzugte Arbeitsumgebung benutzen, um ein assoziatives Modell für die Kundensegmentierung zu erstellen und ein Vorhersagemodell für das Risiko der Kunden zu verlieren. Diese Modelle lassen sich dann im Standard-PMML-Format exportieren und in der Datenbank speichern. Dort können die integrierten Mining-Funktionen von DB2 die Modelle aus einer SQL-Prozedur aufrufen. Als Nächstes kann der gesamte Kundenbestand in der Datenbank aktualisiert werden, indem die Segmentierungs-Cluster als Attribut und das vorhergesagte Risiko als Kenngröße hinzugefügt werden.

Der Leiter einer Fachabteilung, der sich den OLAP-Würfel mit den laufenden Umsätzen inklusive dieser neuen Kenngröße ansieht, vermag bestimmte Kundensegmente zu identifizieren, in denen hohe Umsätze einem hohen Abwanderungsrisiko gegenüberstehen. Eine vorbeugende Kundenbindungskampagne kann daraufhin genau auf diese Segmente zielen und sich ganz auf die Kunden konzentrieren, die eine optimale Kombination von Rentabilität und Risiko aufweisen.

DB2 stellt BI-Funktionen mit der am weitesten verbreiteten Standardschnittstelle zur Verfügung: SQL. Die SQL-Erweiterungen für BI in DB2 werden oft ergänzt durch XML. Dies ermöglicht erweiterte Beschreibungen und die Bildung von nicht tabellarischen Daten wie Mining-Modellen oder Würfelansichten sowie den Meta-Datenaustausch mit externen Tools. Das obige Szenario mit Mining, OLAP-Analyse und Warehouse-Drill-Down lässt sich vollständig in DB2 realisieren – oder aber mit DB2 Information Integrator auch über verteilte heterogene Datenquellen hinweg, und zwar einzig und allein mit SQL und XML.

Abb. 2: DB2 unterstützt ein breites Spektrum an Datentypen, Funktionen und Zugriffsoptionen. Dies hilft BI-Anbietern dabei, leistungsstarke Analyselösungen zu liefern.

Eine einheitliche Basis für OLAP

Da dieser Aspekt der DB2 Architektur für BI ein wesentliches Unterscheidungsmerkmal für IBM ist, verdient er eine genauere Erläuterung. Die Entwickler der Architektur waren mit einer einmaligen Situation in Bezug auf die Bereitstellung von OLAP-Funktionalität konfrontiert. Im Gegensatz zu ihren Mitbewerbern hatte IBM nie einen proprietären MOLAP-Anbieter oder eine entsprechende Technologie aufgekauft. Das Produkt für den MOLAP-Bereich, der DB2 OLAP Server, ist eine OEM-Version von Essbase, ein Produkt des IBM Business Partners Hyperion. Dadurch war IBM frei und konnte DB2 für eine bessere Unterstützung von OLAP innerhalb der Datenbank weiterentwickeln. Auf der Basis des IBM Projekts „Aurora“ liefert dieser jüngste (aber nicht letzte) Schritt in der Weiterentwicklung von DB2 zur OLAP-Engine die XML-gestützte Aufbereitung von OLAP-Ergebnismengen sowie den Import und Export von in XML beschriebenen multidimensionalen Modellen. Dies ermöglicht eine verbesserte Interoperabilität zwischen DB2 und führenden BI-Tools. Aurora führt (ist schon passiert) ein multidimensionales, modellbasiertes Tool ein, um automatisch die optimalen Strukturen innerhalb von DB2 für eine Leistungssteigerung bei OLAP-Abfragen aufbauen zu können. Für viele Analyseanwendungen krempelt diese verbesserte Fähigkeit von DB2, einen virtuellen Würfel zu beschreiben und zu optimieren, die Spielregeln für OLAP völlig um. Caching und Bereitstellung von OLAP-Würfeln außerhalb des Warehouse kann zwar immer noch einen eigenen Wert bieten, bleibt jedoch den IBM-Geschäftspartnern vorbehalten. Das Warehouse selbst ist der Ort, wo die Schwerarbeit der Aufbereitung von OLAP-Daten geschieht, sei es zur Population von MOLAP-Speicherstrukturen oder für die direkte Betrachtung.

Wie „schließt man den Kreis“ mit Echtzeit-Analysefunktionen? Nehmen wir an, eine Geschäftsanwendung schickt während einer Interaktion mit dem Kunden am PoS (Point of Sales) eine Mitteilung an das DB2 Warehouse. Diese ruft eine Stored Procedure auf, die mit Hilfe eines Vorhersagemodells zur Risikobewertung die aktuelle Bereitschaft zur Abwanderung berechnet. Dabei wird die laufende Transaktion mit dem in der Datenbank gespeicherten Risikoprofil über die gesamte Zeit der Kundenbeziehung verglichen. Eine Risikoeinstufung über dem festgelegten Schwellenwert löst eine Meldung an die Call-Center-Anwendung aus, die dem Kunden eine persönliche Voice-Mail-Nachricht zukommen lässt.

Wie dehnen Web Services Echtzeit-Analysefunktionen aus? Nehmen wir das oben beschriebene dynamische Risiko-Bewertungsszenario. Gehen wir davon aus, dass das Unternehmen nach Erwerb einer neuen Geschäftseinheit die gleiche modellbasierte Risikobewertung in das Legacy-System dieser neuen Einheit integrieren muss. Dazu sind nun keine langwierigen und komplizierten Entwicklungsarbeiten erforderlich. Stattdessen wird die vorhandene Risiko-Bewertungsfunktion in DB2 als Web Service dargestellt, indem die SQL-Prozedur in das entsprechende Web-Protokoll verpackt wird. Das Legacy-System ruft dann die Risikobewertung als normale URL-Adresse über das Internet auf.

Abb. 3: Die DB2-Architektur für BI

Zusammenfassung

Die IBM DB2-Architektur für BI differenziert sich klar und deutlich durch die eingangs beschriebene Strategie: „Ziel ist es, BI-Funktionen in die Datenbank zu integrieren und sie ausschließlich über offene Standardschnittstellen als Teil einer integrierten BI-Plattform zugänglich zu machen. Für weitere Schichten der BI-Architektur arbeiten wir mit Geschäftspartnern zusammen.

Fachautor: Otto Görlich, Data Management Solution Consultant, IBM Software Group Deutschland