Data Flow One Engine V 3.1

Data Flow One Engine V 3.1

Data Flow One Engine V3.1 Für eine gute Performance Data Flow One ist eine Standardsoftware im EAI-Bereich, welche es dem Benutzer ermöglicht, auf einfache, graphisch unterstützte Weise Data Warehouses und Datamarts aufzubauen und zu betreiben. Data Flow One (DFO) besteht aus zwei Komponenten: Data Flow One Engine Data Flow One Repository Highlights Automatische Übernahme technischer Metadaten Flexibles Datenmodell Performance-optimiertes Metadatenmodell Erweiterbare Beschreibungen Metadaten von Lieferapplikationen und Datamarts Unterstützung der Datenqualitätssteigerung Die Data Flow One Engine ist ein ETL-Tool (Extract-, Transform-, Load-Tool) für das Laden von Daten (in der Regel aus operativen Systemen) in ein Data Warehouse und Extrahieren dieser Daten. Architektur und Ausprägung des Data Warehouse sind durch seine Funktion bestimmt, z. B. als Business Intelligence oder Operational Data Store. Die zum Laden und Entladen des Data Store erforderlichen Ströme, Transformationen, Abbildungen etc. werden als Metadaten definiert und von der Engine bei der Ausführung interpretiert. Das Data Flow One Repository übernimmt die Speicherung und Auswertung der Metadaten, welche die Datenströme, Abbildungen und Prozesse des Data Warehouses beschreiben. Nutzen Effiziente Datenbereitstellung für DataMart-Projekte Skalierbarer Einsatz Einfache Implementierung, Unterhalt und Ausbau Produktivitätssteigerung Kurze Lernphase für den Benutzer 01

Abb.1 Architektur Data Flow One Engine am Beispiel eines OS/390 Data Warehouses DFO Engine Client OS/390 Operative Systeme (Lieferapplikationen) Data Flow Metadaten Batch-/Ablaufsteuerung DataMart DFO Engine Server DS Data Store DFO Engine Server Schnittstelle Schnittstelle Monitoring Data Modelling Tools Technische Metadaten Business Information DFO Repository Frontend Abb.1 zeigt die Architektur eines DataWarehouses, welches durch die DFO Engine betrieben wird. Im Zentrum steht ein zentraler Data Store, dessen Aufbau durch ein unternehmensweites Datenmodell bestimmt wird. Unterscheidet sich dieses erheblich von den Datenmodellen der Lieferapplikationen und Datamarts, gestalten sich die Lade- und Extraktprozesse sehr komplex. Die Engine bietet die volle für Laden und Extrahieren erforderliche Funktionalität. Insbesondere können beim Extrahieren beliebig komplexe Joins und Selektionen aus dem Data Store vorgenommen werden. Die von der Engine durchzuführenden Abbildungen werden als Data Flow Metadaten vorgegeben, wobei hierzu als Frontend der DFO Engine Client verwendet wird. Die Data Flow Metadaten werden vom DFO Engine Server zur Laufzeit interpretiert. Die Data Flow Metadaten, die mittels der graphischen Oberfläche des Clients generiert werden, sind in einer leicht lesbaren Sprache formuliert. Damit sind sie sehr kompakt und können beispielsweise für Analysezwecke per Email versandt werden. Die Lade- und Extraktströme können als Batchverarbeitungen in die Tagesendverarbeitung integriert werden, indem logische und applikatorische Abhängigkeiten für die Verarbeitung festgelegt werden. Relevante Informationen über ausgeführte Verarbeitungen (Start und Ende, verbrauchte Ressourcen, Kennzahlen über Mengen, Return Codes) werden in Tabellen abgelegt und historisiert. Die Aufbereitung dieser Daten erfolgt über Funktionen des Repository. Die Engine bietet formale und inhaltliche Überprüfungen von Feldinhalten der Schnittstellendateien als Funktion an. Warnungen und detaillierte Fehlermeldungen werden ebenfalls in Tabellen abgelegt. 02

Data Flow Computer Architektur als zugrundeliegendes Paradigma Gemäss der Data Flow Computer Architektur werden die Abbildungen der Lade- und Extraktionsprozesse in zwei Verarbeitungsebenen zerlegt: Die Verarbeitung der Daten (z.b. Durchführen einer Transformation) erfolgt in speziell dafür programmierten Einheiten, Processing Elements. Der andere Teil der Verarbeitung besteht in der Verteilung und Weitergabe der Daten, Routing. Abb. 2 Beispiel eines Flows: Read, Transformation, Write. Am linken Rand sind die Icons aller verfügbaren Processing Elements aufgelistet. Diese werden per Mausklick ausgewählt und auf der graphischen Oberfläche platziert und mit anderen Elementen verbunden. Die Engine umfasst die Implementierung einer wachsenden Zahl von Processing Elements, die jeweils für klar definierte und abgegrenzte Aufgaben entworfen wurden. Die Verbindung dieser Elemente erfolgt durch Warteschlangen, Queues. Bearbeitete Records werden von den Processing Elements in die vorgesehenen Queues gestellt. Die Processing Elements fangen an zu arbeiten, sowie Daten in den Eingabe- Warteschlangen bereit stehen. Jedes Processing Element kann unabhängig von andern arbeiten. Die Vollständigkeit der bereit gestellten Daten ist die einzige Voraussetzung für Processing Elements. Die Data Flow Computer Architektur braucht keine zentrale Steuerung: jedes Processing Element wird gestartet und wartet auf zu bearbeitende Daten, bis ein Signal Datenende kommt. Bei der Programmierung der Engine wird daher als Erstes eine Zerlegung des Abbildungsprozesses in einzelne Schritte vorgenommen. Damit wird ein Graph definiert, dessen Knoten Processing Elements identifizieren. Kanten zwischen zwei Knoten werden als Warteschlangen realisiert. Der Graph mit den Processing Elements wird auf einer graphischen Oberfläche mit Mausklick festgelegt. In einem zweiten Schritt erfolgt die Parametrisierung der aktiven (Processing Elements) und passiven Elemente (Queues) durch die Definition von Objekten wie Strukturen, Transformationsregeln, SQL Statements, Filterregeln, Aggregationsregeln etc. Der Client erzeugt aus den so definierten Elementen die Data Flow Metadaten und stellt sie für die Ausführung bereit. 03

Funktionalität der Processing Elemente Read aus sequentieller Datei: Der Aufbau der zu lesenden Datenrecords kann im einfachsten Fall von fest vorgegebener Struktur sein. Der Aufbau der einzelnen Records kann jedoch auch variieren und gemäss vorgegebenen Regeln interpretiert werden. Write in sequentielle Datei Select Rows aus Datenbank Insert Rows in Datenbank Delete Rows aus Datenbank Transformation von Daten Die Werte der Ausgabefelder werden als Funktion der Eingabefelder definiert. Es sind praktisch beliebig komplexe Ausdrücke zulässig. Filtern von Daten nach formalen und inhaltlichen Kriterien Delta Detection zwischen verschiedenen Generationen von Datenrecords Split/Separate von Records Merge/Recombine von Records Validierung von Daten Aggregation von Daten: Mit dem Aggregations Process Element können bestimmte Aggregationsfunktionen ausgeführt werden (Zählen, Summen- und Durchschnittsbildung, Minimum/ Maximum) und bei Gruppenwechseln aggregierte Records erzeugt und zur Weiterverarbeitung bereitgestellt werden. Es können dabei mehrere, hierarchisch geordnete Aggregationen ausgeführt werden. Abb. 3 zeigt den ClientEditor für die Parametrisierung von Transformations Processing Elements. 04

Abb.4 zeigt einen Flow, in dem ein Datenstrom aus dem Data Store extrahiert und mit dem des Vortages verglichen wird. Der aktuell gültige Datenstrom wird für den Vergleich am nächsten Tag in einer sequentiellen Datei gespeichert. Komplexe Funktionen Überall wo logische, numerische oder Character Ausdrücke auftreten, können neben einer Vielzahl vordefinierter Funktionen auch komplexe Funktionen verwendet werden. Komplexe Funktionen benötigen eine Parametrisierung. Beispiele für komplexe Funktionen sind Table Lookups, prozedurale Abläufe von SQL Statement und speicherresidente Abbildungen. Delta Verarbeitung Die Engine enthält als Feature eine sehr effiziente Delta Detection, mit der es möglich ist, zwei Generationen eines DataSets auf Änderungen, Hinzufügungen und Löschungen von Records hin zu untersuchen. Damit können die Datamarts entweder mit dem vollen Datenumfang oder lediglich mit Deltas versorgt werden. Das Delta Processing Element verarbeitet über zwei Eingabe Queues zwei geordnete Ströme von Datenrecords gleicher Struktur und vergleicht deren Inhalt. Das Processing Element gibt nur die Records weiter, die in wenigstens einem der festgelegten Felder Änderungen erfahren haben. Die Information, welche Felder sich geändert haben, wird festgehalten und kann später in der weiteren Verarbeitung verwendet werden. Ferner werden Records weitergegeben und markiert, die neu hinzugekommen sind oder gelöscht wurden. 05

Künstliche Schlüssel und Object Identifier Die Vorteile, künstliche Schlüssel anstelle von natürlichen Schlüsseln zu verwenden, sind allgemein anerkannt. Für die Realisierung werden gewöhnlich Integerwerte als künstliche Schlüssel vorgeschlagen, wobei die äquivalenten natürlichen Schlüssel in Lookup-Tabellen abgelegt werden. Die Engine bietet zur Generierung von künstlichen Schlüsseln eine Methode an, die vollständig auf die Verwendung von Lookup-Tabellen verzichtet. Als künstliche Schlüssel werden eindeutige 160 Bits umfassende Strings aus den natürlichen Schlüsseln heraus generiert, die auch als unternehmensweit eindeutige Object Identifier verwendet werden können. Wiederverwendbarkeit Objekte, die definiert sind, können in weiteren Flows verwendet werden. Hierzu genügt eine Referenz auf das Objekt (z.b. auf eine Struktur, eine Abbildungsregel, ein SQL Statement). Die Auflösung von Referenzen zu Objekten, die nicht lokal definiert sind, erfolgt automatisch durch die Engine. Es empfiehlt sich, diese Auflösung nicht erst in produktiven Läufen, sondern in einem vorgezogenen Schritt auszuführen. Abb. 6 zeigt einen speziellen Editor des Engine Client, mit dem eine Übersicht aller definierten und zugreifbaren Objekte ermöglicht wird. Batch- und Realtime Verarbeitung Im Allgemeinen wird die DFO Engine in Batchverarbeitungen innerhalb der Tagesendverarbeitung eingesetzt. Hierbei sind ein- und ausgabeseitig die Schnittstellen entweder sequentielle Dateien oder relationale Datenbanken. Der Einsatz der Engine in Realtime-Umgebungen und deren Einbindung in MQ Series Netzwerke ist geplant. Dabei werden anstelle von Read Processing Elements und Write Processing Elements die noch zu schaffenden MQ Get Processing Elements und MQ Put Processing Elements verwendet. Plattformen Implementierung für OS/390, AIX, LINUX und Windows. Optimiert für Ausführung auf OS/390. Für relationale Datenbank DB2. Hinweise zu Marken Microsoft, Windows und Windows NT sind eingetragene Marken oder Marken der Microsoft Corporation in den USA und anderen Ländern. IBM, AIX, DB2, MQ und OS/390 sind eingetragene Marken oder Marken von IBM. Abb. 6 Tree View des Client: Übersicht aller definierten Objekte 06

Schumacher Informatik AG Burgklinge 15 D-70839 Gerlingen Tel. +(49)-7156-270520 Fax +(49)-7156-270521 info@schumacher-informatik.de Service- & Vertriebspartner Softwaretechnik und Informationsmanagement -stim- GmbH Ansprechpartner Herr Peter Bauer Beelitzer Strasse 127 D-14797 Kloster Lehnin GERMANY Email : Peter.Bauer@stim.de Telefon : +49 (0) 3382-701775 Fax : +49 (0) 3382-702958 07