Evaluierung von Data Warehouse- ?· Datenzugriff Data Mart Data Warehouse Operative Systeme Modellierung…

Download Evaluierung von Data Warehouse- ?· Datenzugriff Data Mart Data Warehouse Operative Systeme Modellierung…

Post on 04-Jun-2018

214 views

Category:

Documents

1 download

Embed Size (px)

TRANSCRIPT

<ul><li><p>Evaluierung von Data Warehouse-Werkzeugen</p><p>Hong Hai Do1, Thomas Sthr1, Erhard Rahm1, Robert Mller1,Gernot Dern2</p><p>1Institut fr Informatik, Universitt LeipzigAugustusplatz 10/11, 04109 Leipzig</p><p>2R+V Allgemeine Versicherung AGJohn-F.-Kennedy Str. 1, 65189 Wiesbaden</p><p>Tel.: 0341 / 97 32 306Email: hong@informatik.uni-leipzig.de</p></li><li><p>Evaluierung von Data Warehouse-Werkzeugen</p><p>Zusammenfassung. Die wachsende Bedeutung von Data Warehouse-Lsungenzur Entscheidungsuntersttzung in groen Unternehmen hat zu einer unber-schaubaren Vielfalt von Software-Produkten gefhrt. Aktuelle Data Warehouse-Projekte zeigen, da der Erfolg auch von der Wahl der passenden Werkzeuge frdiese komplexe und kostenintensive Umgebung abhngt. Wir prsentieren eineMethode zur Evaluierung von Data Warehouse Tools, die eine Kombination ausBewertung per Kriterienkatalog und detaillierten praktischen Tests umfat. DieVorgehensweise ist im Rahmen von Projekten mit Industriepartnern erprobt undwird am Beispiel einer Evaluierung fhrender ETL-Werkzeuge demonstriert.</p><p>1. Einleitung</p><p>Die wachsende Akzeptanz von Data Warehouses hat eine rasante Technolo-gieentwicklung in diesem Bereich zur Folge. Dieser Markt verlangt nach unter-sttzenden Werkzeugen, die der Bereitstellung der notwendigen Informationen imWarehouse zum Entscheidungsproze dienen (Chaudhuri, Dayal 1997; Jarke et al.2000; Kimball et al. 1998).</p><p>Abbildung 1 zeigt eine typische Data Warehouse-Umgebung. Daten aus heteroge-nen operativen Systemen (Dateien, DBMS1, etc.) auf unterschiedlichen Plattfor-men (Mainframe, Client/Server, PC) mssen extrahiert, transformiert, aggregiertund schlielich in das zentrale Data Warehouse bzw. lokale Data Marts geladenwerden (ETL1 - Wieken 1999; Soeffky 1999). Typischerweise werden Data Wa-rehouse bzw. Data Marts mittels CASE1-Produkten modelliert. Die Analyse derzusammengefhrten Daten geschieht dann ber BI1-Werkzeuge (z.B. OLAP1,Reporting, Data Mining) der Datenzugriffskomponente (Wieken 1999). Zuneh-mende Bedeutung erfhrt die Anbindung an das Internet und die Bereitstellungrollenspezifischer Informationsangebote ber Informationsportale (White 1999).Metadaten, also beschreibende Informationen zu unterschiedlichsten Aspekten(Herkunft, Qualitt, etc.) sollten in einer entsprechenden Management-Komponente (Repository) einheitlich und konsistent zur Nutzung und Admini-stration des Data Warehouse verwaltet werden (Staudt 1999).</p><p>Zur Bewertung und Auswahl einer adquaten Werkzeuglandschaft bedarf es dahereiner strukturierten, praxisnahen und herstellerunabhngigen Vorgehensweise.</p><p> 1 BI = Business Intelligence, CASE = Computer Aided Software Engineering, DBMS =Datenbank-Managementsystem, ETL = Extraction Transformation Load, OLAP = OnlineAnalytical Processing</p></li><li><p>Datenzugriff</p><p>Data Mart</p><p>Data Warehouse</p><p>Operative Systeme</p><p>Modellierung</p><p>Metadaten-Management</p><p>ETL</p><p>DM DBMSDM DBMS</p><p>DWH DBMS</p><p>PackagedApplication Flat Files DBMS</p><p>Externe Daten</p><p>Metadaten-Repository</p><p>ReportingTool</p><p>OLAP Tool</p><p>Data MiningTool</p><p>ETL ToolCASETool</p><p>InformationPortal</p><p>Datenzugriff</p><p>Data Mart</p><p>Data Warehouse</p><p>Operative Systeme</p><p>Modellierung</p><p>Metadaten-Management</p><p>ETL</p><p>DM DBMSDM DBMS</p><p>DWH DBMS</p><p>PackagedApplication Flat Files DBMS</p><p>Externe Daten</p><p>Metadaten-Repository</p><p>ReportingTool</p><p>OLAP Tool</p><p>Data MiningTool</p><p>ETL ToolCASETool</p><p>InformationPortal</p><p>Abbildung 1. Data Warehouse-Architektur</p><p>Die Universitt Leipzig (Abteilung Datenbanken) entwickelt u.a anbieterunabhn-gige Auswahlverfahren fr verschiedene Klassen von Data Warehouse-Werkzeugen (ETL- und Portallsungen) und leitet daraus in Zusammenarbeit mitUnternehmen adquate Produktvorschlge ab. Die erworbenen praktischen Erfah-rungen auf diesem Gebiet resultieren aus bisher vier seit April 1998 durchgefhr-ten Industrieprojekten mit der R+V Versicherung sowie dem Informatikzentrumder Sparkassenorganisation (SIZ). Zwei der Projekte konzentrierten sich auf dieEvaluierung von ETL-Werkzeugen, um den Auswahlproze bei der Versicherungbzw. in den vom SIZ vertretenen Bankinstituten zu untersttzen (Mller et al.1998; SIZ-Studie 1999).</p><p>Die praktische Evaluierung des State-of-the-Art von Data Warehouse-Werkzeugen ist fr uns ein initialer Schritt zur Forschung in offenen Problemendieses Bereiches. Neben dem Problem der Datenintegration (Hrder et al. 1999;Jarke et al. 2000) betrifft dies vor allem den Bereich Metadaten-Management.Hier behandeln wir Anstze zur Verbesserung der Interoperabilitt sowie zurBereitstellung von Business-Sichten auf Warehouse-Daten durch Integration vontechnischen und Business-Metadaten (Do, Rahm 2000; Mller et al. 1999).</p><p>Dieser Bericht zeigt eine in Industrieprojekten erprobte Vorgehensweise zur Aus-wahl von Data Warehouse-Produkten und prsentiert die daraus abgeleiteten Er-gebnisse am Beispiel von ETL-Werkzeugen. Er ist wie folgt strukturiert: Kapitel 2prsentiert unsere Vorgehensweise bei der Bewertung von Data Warehouse-Werkzeugen. Kapitel 3 vertieft dies am Beispiel der praktischen Evaluierung vonETL-Werkzeugen und prsentiert Ausschnitte unserer Produktergebnisse. In Ka-pitel 4 fassen wir zusammen und geben einen Ausblick auf geplante Ttigkeiten.</p></li><li><p>2. Vorgehensweise bei der Werkzeugevaluierung</p><p>Abbildung 2 verdeutlicht unsere im Evaluierungsproze verfolgte Vorgehenswei-se. Vier prinzipielle Schritte werden unterschieden:</p><p> Projektspezifische Adaption des Evaluierungsverfahrens Anbietervorauswahl per Kriterienkatalog Praktische Evaluierung Bewertung der Testergebnisse und EmpfehlungAnschlieend sollte eine produktionsnahe Erprobung unter Regie des jeweiligenUnternehmens erfolgen.</p><p>Entscheidung</p><p>Projektdefinition</p><p>Erstellung des Kriterienkatalogs</p><p>Testszenario</p><p>Erstellung des Testszenarios</p><p>Anforderungen</p><p>Kriterienkatalog</p><p>Legende</p><p>Schritt:</p><p>Input/Output:</p><p>Erzeugt Output/Nutzt Input:</p><p>Iteration</p><p>Iteration</p><p>Vorauswahl</p><p>Gegenberstellung,Bewertung</p><p>Testergebnisse A</p><p>Werkzeug AWerkzeug BWerkzeug A</p><p>Testergebnisse BTestergebnisse A</p><p>Praktischer Test</p><p>Vorprodutiver Einsatzim Unternehmen</p><p>Abbildung 2. Vorgehensweise zur Werkzeugevaluierung</p><p>2.1. Projektspezifische Adaption des Evaluierungsverfahrens</p><p>Zunchst wird gem der unternehmensspezifischen Anforderungen die Klasseder bentigten Werkzeuge und die Anforderungen an diese im Rahmen des DataWarehouse-Projekts identifiziert. Insbesondere werden projektspezifische K.O.-Kriterien bestimmt (z.B. Minimalfunktionalitten, technische Installationsvoraus-setzungen, maximale Aufwendungen, etc.), die eine einfache Vorselektion vonProdukten zu einem frhen Zeitpunkt ermglichen.</p></li><li><p>Kriterienkatalog. Anschlieend ist ein entsprechender Kriterienkatalog zur Vor-auswahl der Werkzeuge zu entwickeln bzw. an die jeweiligen Projektanforderun-gen anzupassen. Diese Kriterien bilden die Basis fr die vergleichende Bewertung.Um den Aufwand der Anbieter beim Ausfllen zu minimieren, sollen die Kriterienmglichst eindeutig, gut kommentiert und vertretbar feingranular ausgewhltwerden.</p><p>Testszenario. Die Papier-Evaluierung mittels Katalog (zusammen mit Informa-tionen aus Data Sheets, White Papers, etc.) ergibt zwar bereits einen guten ber-blick ber die zu erwartende Mchtigkeit der Werkzeuge und ihre Unterschiede.Unsere Erfahrung hat allerdings gezeigt, da erst der praktische Test vor Ort unterWettbewerbsbedingungen die tatschlichen Fhigkeiten der Werkzeuge auf-zeigt. Daher wird ein einheitliches Testszenario bentigt, welches die zuknftigeEinsatzumgebung der Werkzeuge im Unternehmen (Software, Hardware, Daten-basis) mglichst genau nachbildet und die Bewertung deren prinzipiellen Eigen-schaften und Fhigkeiten in Form von praktisch zu lsenden Aufgaben adressiert.</p><p>Falls neue wesentliche Anforderungen in Betracht zu ziehen sind, ist ggf. eineIteration dieser Phase erforderlich.</p><p>2.2. Vorauswahl per Kriterienkatalog</p><p>Per Recherche im Internet, in Fachzeitschriften und vergleichbaren Studien istzunchst ein berblick ber den technologischen Stand des Marktes zu gewinnenund die Menge relevanter Anbieter und Produkte zu identifizieren.</p><p>Der Kriterienkatalog wird zunchst an in Frage kommende Anbieter versendet,welche den Kriterienkatalog innerhalb einer angemessenen Frist ausfllen. Dieanschlieende Auswahl der Werkzeuge fr den praktischen Test erfolgt dann berdie Auswertung der ausgefllten Kriterienkataloge. Mit einer Bewertungsmetrikdurch Gewichtung von Kriterien gem Unternehmensanforderungen kann zudiesem Zeitpunkt aus den verbliebenen Werkzeugen bereits eine Vorauswahlgetroffen werden, die den Kreis der ggf. aufwendig zu testenden Tools signifikanteinschrnkt. Insbesondere knnen Anbieter durch Erfllung von K.O.-Kriterienfrhzeitig ausgesondert werden.</p><p>2.3. Praktische Evaluierung</p><p>Die nach Durchfhrung der Katalog-Evaluierung gewonnene Einschtzung derFhigkeiten der Werkzeuge durch Anbieter und Tester/Anwender knnen in eini-gen Punkten auseinandergehen bzw. Aspekte noch unklar bleiben. Auerdem sindBewertungen ber Ergonomie, Handling, Nutzerfreundlichkeit, etc. als wesentlicheinzustufen.</p></li><li><p>Daher wurden praktische Tests gemeinsam mit den Anbietern in einem Proof ofConcept (PoC) von zwei bis vier Tagen Dauer durchgefhrt. Dadurch konnten dieInstallations- und Einarbeitungszeiten signifikant verkrzt werden. Gem ei-genentwickelter Aufgabenstellungen wurden die Funktionalitten mit dem An-bieter gemeinsam getestet und der Grad der Aufgabenbewltigung festgehalten.</p><p>2.4. Bewertung der Testergebnisse</p><p>Smtliche Testergebnisse der Werkzeuge wurden in kompakten, gem der zen-tralen Bewertungskriterien strukturierten Testberichten zusammengefat. Dieherausragenden Strken und Schwchen der einzelnen Werkzeuge wurden miteiner +/-Bewertung verdeutlicht. Eine feinere Notengebung wurde nur in Aus-nahmefllen, abhngig von den Projektzielen, vorgenommen, da die zugrundelie-gende Gewichtung und Vergleichbarkeit generell als problematisch zu bewertensind.</p><p>Sollte der Evaluierungs- und Entscheidungsproze lnger andauern bzw. der Pro-jektkontext wechseln, so ist ggf. eine Aktualisierung der gewonnenen Ergebnisseerforderlich. Bei verhltnismig kurzen Zeitrumen (z.B. ein Quartal) sind nor-malerweise keine wesentlichen nderungen am Produkt zu erwarten.</p><p>Nach getroffener Auswahl sind die Kandidaten einer vorproduktiven Einsatzphaseim Unternehmen zu unterziehen. In dieser Phase sollten, falls relevant, insbeson-dere Performance-, Verfgbarkeits- und Heterogenittsaspekte der zu testendenWerkzeuge praktisch betrachtet werden.</p><p>3. Evaluierung von ETL-Werkzeugen</p><p>Der ETL-Vorgang wird in aktuellen Data Warehouse-Umgebungen sehr hufigdurch eigenentwickelte Legacy-Programmierlsungen (C/C++, Cobol, DB-Skripte) durchgefhrt. Insbesondere problematisch sind dabei der betrchtliche Aufwand bei der Wartung, Konsistenzerhaltung und Doku-</p><p>mentation, die schwierige Integration der Mainframe-Welt mit Client/Server- oder PC-</p><p>Umgebungen und die fehlende Metadatenuntersttzung.</p><p>In diesem Abschnitt wird die in Kapitel 2 beschriebene Vorgehensweise am prak-tischen Beispiel der Evaluierung von ETL-Werkzeugen diskutiert, welche imKontext des Initialprojektes mit der R+V-Versicherung durchgefhrt wurde. Zielwar die Identifikation eines adquaten Metadaten-gesttzten ETL-Werkzeuges.</p></li><li><p>3.1. Kriterienkatalog</p><p>Eine detaillierte Abhandlung des nachfolgend vorgestellten Kataloges findet sichin (Mller et al. 1998).</p><p>Anbieter-/Produktprofil. Anbieterinformationen wie z.B. Mitarbeiterzahl inDeutschland/weltweit, Marktprsenz, Zeitpunkt Erst-Release, Vertriebsnetz, Bi-lanzsummen und nicht zuletzt der angebotene technische Support sind neben denProduktfhigkeiten wichtige Indikatoren fr die Verllichkeit und Stabilitt einesAnbieters (jngst zahlreiche bernahmen!).</p><p>Das Produkt wird grob gem der prinzipiellen Ausrichtung der Anbieter (z.B.DBMS-, BI-, CASE-, Repository-Bereich, etc.) klassifiziert. Auerdem werdendie wesentlichen Komponenten und Funktionalitten des Werkzeugs sowie die frdie Installation und Nutzung notwendigen Hardware- und Software-Voraussetzungen registriert.</p><p>Quellextraktion/integration. Ein zentraler Punkt ist die Fhigkeit zur Extrakti-on von Daten - bzw. bei knappem Zeitfenster fr die Aktualisierung des Ware-house - auch von nderungen auf Daten (Changed Data Capture) aus den rele-vanten Quellsystemen (diverse Dateiformate, relationale/hierarchische DBMS aufunterschiedlichsten Plattformen).</p><p>Insbesondere mu bei der Integrationsfhigkeit bewertet werden, inwiefern dieMapping-Definition sowie der Datentransfer von den Mainframe-Quellsystemenzu Client/Server- oder PC-Zielsystemen mglichst transparent und integriert, d.h.weitgehend ohne explizite Bercksichtigung der Systemgrenzen, durchgefhrtwerden kann.</p><p>Mapping-Definition, Datenbewegung. Zur Umsetzung der Abbildung von ope-rativen in dispositive Systeme werden sog. Mappings definiert, welche die not-wendigen Transformations- und Filtervorschriften enthalten. Deren Definitionkann unterschiedlich erfolgen: graphisch oder skriptorientiert, per Drag&amp;Dropoder tabellen-/formularorientiert. Es ist zu untersuchen, ob und bis zu welchemKomplexittsgrad Filterbedingungen fr das Lesen der Quellsysteme und Konver-tierungsregeln bzgl. der Datenbewegungen definiert werden knnen (s. Abschnitt3.2). Einen diesbezglichen Ausschnitt unseres Kriterienkataloges zeigtAbbildung 3.</p><p>Bzgl. der Umsetzung der Datenbewegung finden sich prinzipiell zwei Anstze:einige Produkte generieren Programm-Code (C/C++, Cobol, etc.), welcher dannlokal kompiliert wird und die Datenbewegungen durchfhrt. Bei der zweiten Vari-ante, der sog. engine-basierten Lsung, wird der generierte Transformations-Code(im folgenden Engine genannt) zur Laufzeit interpretiert. Die Programme mssenin beiden Fllen in proprietre oder externe Scheduling-Systeme eingebundenwerden, welche wiederum verschiedene Grade an automatischer Verwaltung die-ser Transformations-Jobs anbieten.</p></li><li><p>Abbildung 3. Ausschnitt des Kriterienkatalogs zum Aspekt Mapping-Komplexitt</p><p>Metadaten-Management. Die Verwaltung von im ETL-Proze anfallenden Me-tadaten erfordert i.d.R. die Existenz eines Repositories. Hier ist zu unterscheiden,ob Produkte auf bewhrte DBMS-Technik zurckgreifen oder eine einfache Da-teiablage bevorzugen.</p><p>Fr eine integriertes Warehouse-Konzept spielt die Interoperabilitts und Aus-tauschfhigkeit eine tragende Rolle. Es werden Export/Import-Formate (MDIS2,CDIF3, XML4 etc.) abgefragt, API-Fhigkeiten (C/C++ oder Java), tool-spezifische Metadaten-Wrappers fr BI-, Repository-Produkten, Portalen, etc.registriert. Weiterhin wird die Untersttzung adquater Metamodellstandards(CWM5, OIM6) vermerkt.</p><p>Neben den rein technischen Metadatenaspekten ist die Orientierung eines ETL-Produktes hinsichtlich Business Term-Modellierung, Grad der Komplexitt desMetamodells (Entity-Relationship, UML7) bzw. die Art der Spezifikation desBusiness Term-Modells (graphisch, skriptorientiert) von Bedeutung.</p><p>Ergonomie, Handling. In diesem Abschnitt werden ergonomische Aspekte er-fragt, z.B. die Existenz graphischer Benutzeroberflchen, kontextsenstiver Online-Hilfe, Untersttzung bei der Mapping-Definition, Komplexitt der Administration,etc. Diese Kriterien knnen nur bedingt durch den Anbieter ausgefllt werden;</p><p>...</p></li></ul>

Recommended

View more >