Continuous Improvement Process (CIP) 5/5 (2)

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

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

Mit den richtigen Informationen, analytisch aufbereitet, können folgende Fragen effizient und jederzeit beantwortet werden:

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

Lösung: Continuous Improvement Process

Continuous Improvement Process (CIP)

Continuous Improvement Process (CIP) ist ein Vorgehen, das durch kontinuierliche Analyse und Auswertung der erhobenen Messdaten einen Überblick über die Infrastruktur bestehend aus Datenbank- und Applikationsservern sowie die ausgeführten Prozesse bietet. Der Continuous Improvement Process fokussiert sich auf zwei Kategorien. Die erste umfasst eine detaillierte Analyse der verwendeten Datenbank und die zweite untersucht die ausgeführten Informatica-Datenintegrationsprozesse. Ultimatives Ziel dieses Vorgehens ist es, die Leistungsfähigkeit der Informationsfabrik detailliert beurteilen zu können. Ineffiziente Prozesse, nicht sinnvoll belegte Speicherkapazität, eine unausgewogene Systemauslastung mit ungünstigen Spitzenlastsituationen sollen identifiziert und durch geeignete Verbesserungsmaßnahmen frühzeitig behoben werden. Des Weiteren sind die Ergebnisse der Analyse wichtige Anhaltspunkte für die Einplanung neuer Verarbeitungsprozesse bzw. für die Ausbaufähigkeit bestehender Verarbeitungsprozesse vor dem Hintergrund sich abzeichnender Änderungen der Rahmenbedingungen.

Die Basisdaten für die Analyse werden durch Abfragen auf das Datenbank Dictionary und der Laufzeitinformationen des Informatica Repositorys bestimmt. Darüber hinaus werden Daten aus der Persistenzschicht der integration-factory Generic Logging Solution hinzugezogen. Die operativen Metadaten werden zur Schaffung einer analytischen Sicht langfristig gespeichert.

Die Analysen des Continuous Improvement Process stellen einen Teilausschnitt der integration-factory operativen Metadaten Analyse Lösung OMA dar. In Abgrenzung zu OMA findet keine Transformation und Abbildung auf einen generischen Objektbegriff mit hierarchischen Objekt-Beziehungen und dynamischer Tiefe statt.

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

Darstellung Continuous Improvement Process

Informatica

Die Datenintegrationskomponente des Data Warehouse, für das der Continuous Improvement Process entwickelt wurde, basiert auf Informatica PowerCenter. Das Informatica Repository zeichnet die wesentlichen Laufzeitdaten auf. Angereichert um semantische Informationen über Applikationen und Integrationssequenzen aus der integration-factory Generic Logging Solution stellen dies die wesentlichen operativen Metadaten für die Analyse dar.

Um die Effizienz eines Datenintegrationsprozesses beurteilen zu können, sind neben den eigentlichen Laufzeitdaten (Start, Ende, Laufzeit, Anzahl verarbeiteter Quell- und Zieldatensätze, Anzahl Ausführungen in einer Zeiteinheit) auch Informationen über das Gesamtsystem (parallel ausgeführte Verarbeitungsprozesse) sowie eine Einteilung der Datenintegrationsprozesse in verschiedene Prozessklassen, die jeweils hinsichtlich der Verarbeitungskomplexität eine Äquivalenzklasse darstellen, erforderlich. Anhand der semantischen Informationen lassen sich sinnvolle Einteilungen finden. Diese Klassen können sich beispielsweise am Funktionsbereich oder der betriebenen Applikation orientieren. 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 ihre unveränderlichen bzw. in die veränderlichen 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

Die Laufzeiten (Start, Ende, Laufzeit) sowie die Verarbeitungsmenge jedes einzelnen Prozesses werden aufgezeichnet und abgelegt und basierend auf den gebildeten Klassen ins Verhältnis gesetzt. Ausreißer in Gestalt von langlaufenden oder extrem und unerwartet schnellen Prozessen werden durch Abweichungen vom Mittel erkannt. Das hier zugrundeliegende Data Warehouse hat pro Tag ca. 600 verschiedene Verarbeitungsprozesse mit ca. 95.000 Prozessinstanzen, so dass eine Einzelfallanalyse augenscheinlich wenig zielführend ist. Auch hängt die durchschnittliche Laufzeit eines Prozesses in einem Monat stark von weiteren Faktoren ab, wie der Anzahl der Arbeitstage im Monat, da einige Prozesse nur an Werktagen ausgeführt werden sollen, oder von neuen Implementierungen, für die anfänglich noch wenig Erfahrungswerte vorliegen. Die Datenbasis berücksichtigt diese Aspekte und schafft somit die Grundlage für eine objektive Bewertung, welcher Prozess eingehender untersucht und optimiert werden muss.

Oracle

Das Data Warehouse, für das der Continuous Improvement Process entwickelt wurde, basiert auf einer Oracle Database. CIP legt bei der Datenbankkomponente 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, oder gänzlich ungenutzte bzw. aufgegebene Datenobjekte, die überaltert oder bestimmungslos geworden sind. In Entwicklungs- und Simulations-/ Testumgebungen identifiziert der Continuous Improvement Process auch solche Objekte, die per Konvention im falschen Schema gespeichert bzw. angelegt wurden, und Tabellen, die in den Papierkorb verschoben wurden.

Die Basisdaten für die Analyse werden durch regelmäßige Abfragen auf Service Tabellen des Oracle Dictionarys ermittelt und für die Analyse langfristig gespeichert.

  • Löschen von Backups

Backup-Tabellen werden durch Abweichungen von Namenskonventionen wie z. B. X_, _BKP und _BCK erkannt. Basierend auf dieser Menge wird eine Liste erstellt und anschließend 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 Data Warehouse, für das der Continuous Improvement Process entwickelt wurde, trennt zwischen Owner-, technischen und personalisierten Nutzern. Nur Owner-Nutzer sollen eigenständige Daten besitzen. Alle Zugriffsnutzer besitzen dagegen keine DDL-Rechte.

Sofern erkannt wird, dass der Zugriffsuser eine Tabelle enthält, muss dieser Sachverhalt weitergehend geprüft werden. Gegebenenfalls muss die Tabelle umgezogen oder gelöscht werden. Dies ist ein typisches Szenario für Entwicklungs-, Simulations- 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, das alle drei Wochen ausgeführt wird, gelöscht.

Ergebnis

In dem folgenden Bild ist der monatliche Durchschnitt der Laufzeit für die oben genannten drei Klassen (DIM, FCT und ADAL) von Februar bis September dargestellt. Die Analyse hatte einige Optimierungspotenziale erkennen lassen. So konnten die Laufzeiten pro Laufzeitklasse deutlich reduziert und so die Verarbeitung beschleunigt werden.

Laufzeiten CIP

Die folgende 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.

Speicherplatz CIP