Continuous Improvement Process (CIP)

5/5 (2)

Das Business Data Warehouse (BDWH) ist das Data Warehouse der European Energy Exchange Gruppe (EEX). Es stellt unterschiedlichen Applikationen und Abnehmersystemen in der EEX Gruppe Daten von hoher Qualität zu Verfügung. Das BDWH ist in die operativen Geschäftsprozesse des Unternehmens eingebunden und erlangt dadurch eine besondere Kritikalität. Es akquiriert hauptsächlich Echtzeitdaten aus den verschiedenen Handels-, Abwicklungs- und Risikobewertungssystemen. Die Basisdaten werden in nahe-Echtzeit mit historischen Daten in Informationen transformiert. Diese werden wiederum an ein Message System für die weitere EEX-interne Verwendung übertragen. Zuverlässigkeit, Geschwindigkeit und Effizienz spielen in der Datenverarbeitung also eine herausragende Rolle. Um die Leistungsfähigkeit des BDWH zu optimieren, wurde ein Continuous Improvement Process (CIP) etabliert.

Ausgangssituation

Das Data Warehouse ist ein zentraler Baustein der unternehmensweiten Informationsinfrastruktur. Es kann als Informationsfabrik verstanden werden, die den Kunden Informationsprodukte in hoher Qualität zu vereinbarten Lieferterminen an definierter Stelle zur Verfügung stellen soll. Die Leistung der Fabrik muss sich am Verhältnis zwischen Aufwand und Output beurteilen lassen, also ihrer Effizienz. Hierzu werden Informationen über den Produktionsprozess zur Überwachung, Steuerung und Produktionsplanung benötigt.

Werden die richtigen Informationen analytisch aufbereitet, können folgende Fragen jederzeit effizient beantwortet werden:

  • Produktionsplanung
  • Kapazitätsplanung
  • Ressourcen-Ausnutzung
  • Performance und Identifizierung von Verbesserungspotential

Continuous Improvement Process (CIP)

Ein CIP ist ein Vorgehen, welches einen Überblick über die Infrastruktur aus Datenbank- und Applikationsservern, sowie die ausgeführten Prozesse bietet. Dies geschieht durch die kontinuierliche Analyse und Auswertung der erhobenen Messdaten.

Der CIP fokussiert zwei Kategorien: Die erste umfasst eine detaillierte Analyse der verwendeten Datenbank und die zweite untersucht die ausgeführten Informatica-Datenintegrationsprozesse. Das Ziel dieses Vorgehens ist die genaue Beurteilung der Leistungsfähigkeit der Informationsfabrik. Ineffiziente Prozesse, nicht sinnvoll belegte Speicherkapazität oder unausgewogene Systemauslastungen mit ungünstigen Spitzenlastsituationen sollen identifiziert und durch geeignete Verbesserungsmaßnahmen frühzeitig behoben werden. Außerdem sind die Ergebnisse der Analyse wichtige Anhaltspunkte für die Einplanung neuer Verarbeitungsprozesse, bzw. für die Ausbaufähigkeit von bestehenden Verarbeitungsprozessen bei veränderten Rahmenbedingungen.

Die Basisdaten für die Analyse werden durch Abfragen der Datenbank Dictionary und der Laufzeitinformationen des Informatica Repository bestimmt. Darüber hinaus werden Daten aus der Persistenzschicht der integration-factory Generic Logging Solution hinzugezogen.
Die operativen Metadaten werden langfristig gespeichert, um eine analytische Sicht zu schaffen.

Die Analysen des CIP stellen einen Teilausschnitt der operativen Metadaten-Analyse-Lösung OMA von integration-factory dar. In Abgrenzung hierzu findet allerdings keine Transformation und Abbildung auf einen generischen Objektbegriff mit hierarchischen Objektbeziehungen und dynamischer Tiefe statt.

Die regelmäßige Durchführung des CIP liefert ein belastbares Bild und führt zu einer verbesserten Gesamtperformance des analysierten Data Warehouse Systems.

Informatica

Das Data Warehouse, für den der CIP entwickelt wurde, basiert in seiner Datenintegrationskomponente auf Informatica PowerCenter. Das Informatica Repository zeichnet die wesentlichen Laufzeitdaten auf. Es wird außerdem angereichert um semantische Informationen über Applikationen und Integrationssequenzen aus der integration-factory Generic Logging Solution. Zusamen ergeben sich die entscheidenden operativen Metadaten für die Analyse.

Um die Effizienz eines Datenintegrationsprozesses beurteilen zu können, sind verschiedene Informationen erforderlich. Das sind zum einen die eigentlichen Laufzeitdaten: Start, Ende, Laufzeit, Anzahl der verarbeiteten Quell- und Zieldatensätze, sowie die Anzahl an Ausführungen in einer Zeiteinheit. Zum anderen handelt es sich um Informationen über das Gesamtsystem, also den parallel ausgeführten Verarbeitungsprozessen. Schließlich benötigt es noch eine Einteilung der Datenintegrationsprozesse in verschiedene Prozessklassen, die je eine Äquivalenzklasse hinsichtlich der Verarbeitungskomplexität darstellen. Diese Einteilungen lassen sich anhand der semantischen Informationen sinnvoll finden. Die Klassen können sich beispielsweise am Funktionsbereich orientieren, oder an der betriebenen Applikation.

Die Laufzeitdaten und die Verarbeitungsmenge jedes einzelnen Prozesses werden aufgezeichnet und abgelegt. Basierend auf den gebildeten Klassen werden sie ins Verhältnis gesetzt. Ausreißer, wie etwa langlaufende oder extrem und unerwartet schnelle Prozesse, werden durch Abweichungen vom Mittel erkannt.

Das Data Warehouse aus diesem Beispiel hat allerdings täglich ca. 600 verschiedene Verarbeitungsprozesse mit ca. 95.000 Prozessinstanzen. Eine Einzelfallanalyse ist hier augenscheinlich wenig zielführend. Auch hängt die durchschnittliche Laufzeit eines Prozesses in einem Monat stark von weiteren Faktoren ab. Dazu gehört die Anzahl der Arbeitstage, da einige Prozesse nur an Werktagen ausgeführt werden sollen, oder auch neue Implementierungen, für die anfänglich noch wenig Erfahrungswerte vorliegen. Die Datenbasis berücksichtigt diese Aspekte und schafft die Grundlage für eine objektive Bewertung darüber, welcher Prozess eingehender untersucht und optimiert werden muss.

Im DWH-System der EEX werden die folgenden Hauptklassen unterschieden:

  • DIM (Dimension)
    • Prozesse, die zu historisierende, zeitlich zu versionierende Stammdaten verarbeiten
    • Speicherung der Zustandsveränderung eines Objektes
    • Zerlegung der Objekte in unveränderliche und veränderliche Attribute
  • FCT (Fakt)
    • Prozesse, die transaktionale (Fakten-)Daten verarbeiten
    • Sicherung aller Transaktionsdaten unter vollständiger Einordnung in den Data Warehouse Kontext (Bestimmung aller Foreign Keys)
  • ADAL (Broadcast Messages)
    • Prozesse, die zum Application Data Acces Layer gehören
    • Erstellung von Nachrichten im Google Buffer Protocol, Format und Verteilung über einen Message Broker

Oracle

Eine zweite Basis für das Data Warehouse dieses CIP ist eine Oracle Database. In Hinblick auf Datenbanken legt ein CIP das Augenmerk auf die allgemeine Speicherverwendung zur Identifizierung überflüssiger Datenbereiche. In der Regel sind dies Backup-Tabellen, die im Rahmen von Migrationen entstanden sind. Es kann sich aber auch um gänzlich ungenutzte oder aufgegebene Datenobjekte handeln, die überaltert oder bestimmungslos geworden sind. In Entwicklungs- und Testumgebunden identifiziert der CIP auch solche Objekte, die per Konvention im falschen Schema gespeichert oder angelegt wurden, und in den Papierkorb verschobene Tabellen. Die Basisdaten für die Analyse werden durch regelmäßige Abfragen auf Service Tabellen des Oracle Dictionary ermittelt und für die Analyse langfristig gespeichert.

Löschen von Backups

Backup-Tabellen werden durch Abweichungen von Namenskonventionen erkannt, wie z.B. X_, _BKP und _BCK. Basierend auf dieser Menge wird eine Liste erstellt und entschieden, ob die Daten der Backup-Tabelle älter als drei Monate sind und gelöscht werden können.

Löschen von Tabellen im Userschema

Das User Concept des Datawarehouse dieses CIP trennt Owner, technische und personalisierte Nutzer. Nur Owner-Nutzer sollen eigenständige Daten besitzen. Alle Zugriffsnutzer besitzen dagegen keine DDL-Rechte.

Wenn erkannt wird, dass der Zugriffsnutzer eine Tabelle enthält, muss dieser Sachverhalt geprüft werden. Gegebenenfalls muss die Tabelle umgezogen oder gelöscht werden. Dies ist ein typisches Szenario für Entwicklungs- und Testumgebungen. Ein falsches Paketieren für einen Software-Transport in die Produktion kann so wirkungsvoll verhindert werden.

Löschen von Tabellen im Papierkorb

Um Speicherplatz zu sparen, werden gelöschte Tabellen im Papierkorb durch ein automatisches Skript gelöscht, welches alle drei Wochen ausgeführt wird.

Ergebnis

In der folgenden Abbildung ist der monatliche Durchschnitt der Laufzeit für die oben genannten drei Klassen (DIM, FCT und ADAL) von Februar bis September dargestellt. Die Analyse hat einige Potenziale zur Optimierung sichtbar gemacht. So konnten die Laufzeiten pro Klasse deutlich reduziert und die Verarbeitung beschleunigt werden.

Diese Abbildung zeigt den von Mai bis September durch die Datenbank belegten Speicherplatz. Die Spitzen zeigen an, dass in der Datenbank eine Bereinigung durchgeführt wurde.