Sven Bosinger solution architect BI. Data Warehouse Architekturen Der Schlüssel zum Erfolg! DOAG

Transkript

1 Sven Bosinger solution architect BI Data Warehouse Architekturen Der Schlüssel zum Erfolg! DOAG

2 Agenda Kurze Vorstellung its-people Architektur als Erfolgsfaktor Verschiedene Architekturansätze Herausforderung Datenqualität Fallbeispiele Fazit DOAG

4 its-people Experten für IT-Projekte its-people ist ein unternehmerisch organisierter und geführter Verbund von selbständigen und erfahrenen IT-Beratern its-people ist versierter Anbieter von technologienahen Dienstleistungen: Oracle, SAP, BI und IT-Management Services its-people bietet Trainings aus der Praxis für die Praxis -> its-people academy its-people bietet seine Dienstleistungen bundesweit und flächendeckend an und orientiert sich dabei an den Bedürfnissen der Kunden its-people ist in den Wirtschaftsräumen Rhein-Main, Nordrhein- Westfalen, München, Hamburg und Wolfsburg vertreten und umfasst ca. 70 Berater sowie 50 assoziierte Mitglieder DOAG

6 Architektur als Erfolgsfaktor Ein Data Warehouse hat in der Regel viele Väter Projektbeteiligte Fachbereich: Anwender und Sponsor IT-Abteilung: Konzeption und (Weiter-) Entwicklung Hoster: Controlling: Betrieb Kostenkontrolle Es bestehen Interessenskonflikte DOAG

7 Architektur als Erfolgsfaktor Anforderungen an ein Data Warehouse Fachbereich Korrektheit und Konsistenz der Daten Hohe Verfügbarkeit der Informationen Kurze Latenzzeiten Granularität der Daten Standardisierung der verwendeten Begriffe und Sachverhalte Historisierung der Inhalte Fachbereich DOAG

8 Architektur als Erfolgsfaktor Anforderungen an ein Data Warehouse IT-Abteilung Konsolidierung heterogener Datenquellen Performanz der Ladeprozesse Einfache Erweiter- und Skalierbarkeit IT-Abteilung Fachbereich DOAG

9 Architektur als Erfolgsfaktor Anforderungen an ein Data Warehouse Hoster Reibungslose Integration in die vorhandene Systemlandschaft Bekannte Technologie Standardportfolio Hoster IT-Abteilung Fachbereich DOAG

10 Architektur als Erfolgsfaktor Anforderungen an ein Data Warehouse Controlling Möglichst niedrige Erstellungskosten (Projektkosten) Möglichst niedrige Betriebskosten (Wartung) ROI Controlling Hoster IT-Abteilung Fachbereich DOAG

11 Architektur als Erfolgsfaktor Ein Data Warehouse ist Prozessgetrieben Unterstützung von Geschäftsprozessen Beruht selbst auf Prozessen Datenbewirtschaftung Metadatenmanagement Datenqualitätsmanagement Betrieb Changemanagement Eine gute Architektur muss alle diese Prozesse unterstützen! Extraktion Transformation Workflow Laden DOAG

12 Architektur als Erfolgsfaktor Konsequenzen: Anforderungen sind zum Teil gegenläufig Eine erfolgreiche Architektur muss den unterschiedlichsten Anforderungen Rechnung tragen Die Architektur hat maßgeblichen Einfluss auf: Den Nutzen für den Fachbereich Die Grenzen des Wachstums Die Kosten für Erstellung und Betrieb Die Manageability Die Architekturfrage muss früh entschieden werden! DOAG

14 Verschiedene Architekturansätze Die (einfache) Reportinglösung Quellsysteme Reporting E1 Einkauf E2 E4 E3 Vertrieb HR SQL-Statements V1 V2 H1 H2 H4 V3 V4 H3 H5 V5 DOAG

15 Verschiedene Architekturansätze Die (einfache) Reportinglösung Vorteile Kurze Latenzzeiten Verfügbarkeit wie im Quellsystem Granularität der Daten Schnelle und kostengünstige Projektrealisierung DOAG

16 Verschiedene Architekturansätze Die (einfache) Reportinglösung Nachteile Korrektheit und Konsistenz der Daten nur auf Berichtsebene Standardisierung findet nur im Bericht statt Historisierung abhängig vom Quellsystem Keine Konsolidierung Performanz abhängig vom Quellsystem Keine Prozesse für Metadaten-, Datenqualitäts- und Changemanagement Komplexe Datenmodelle Gefahr von Report Kaskaden => Hochgradige Redundanz DOAG

17 Verschiedene Architekturansätze Das unabhängige Data Mart Quellsysteme Data Warehouse Reporting Einkauf E1 E2 E4 E3 V1 Vertrieb V2 H1 HR H2 H4 ETL SQL-Statement oder OLAP-DML V3 V4 H3 H5 Data Mart V5 DOAG

18 Verschiedene Architekturansätze Das unabhängige Data Mart Vorteile Korrektheit und Konsistenz der Daten Verfügbarkeit unabhängig vom Quellsystem Granularität auf Berichtswesen abgestimmt Standardisierung gewährleistet Daten können historisiert werden Konsolidierung unterschiedlicher Datenquellen Performante Ladeprozesse Klarer ETL-Prozess Prozesse für Metadaten- und Datenqualitäts- Management DOAG

19 Verschiedene Architekturansätze Das unabhängige Data Mart Nachteile Vergrößerung der Granlarität nicht möglich Latenzzeiten vorhanden, meist 1 Tag Historisierung meist sehr Aufwendig Erweiter- und Skalierbarkeit ist eingeschränkt Changemangement sehr aufwendig Führt häufig zu Data Mart Kaskaden DOAG

20 Verschiedene Architekturansätze Das abhängige Data Mart DOAG

21 Verschiedene Architekturansätze Das abhängige Data Mart Vorteile Korrektheit und Konsistenz der Daten Verfügbarkeit unabhängig vom Quellsystem Granularität kann beliebig eingestellt werden Standardisierung gewährleistet Historisierung im Datenmodell Konsolidierung unterschiedlicher Datenquellen Performante Ladeprozesse Einfache Erweiter- und Skalierbarkeit Klarer ETL-Prozess Prozesse für Metadaten-, Datenqualitäts- und Changemanagement DOAG

22 Verschiedene Architekturansätze Das unabhängige Data Mart Nachteile Latenzzeiten vorhanden, meist 1 Tag Kosten für Realisierung und Betrieb Redundanz der Daten DOAG

23 Verschiedene Architekturansätze Einsatzgebiete Reportinglösung: Systemnahe Auswertungen auf einer Quelle Unabhängiges Data Mart: kleine Informationssysteme für eine einzige Fachabteilung bei geringem Änderungsaufkommen und wenigen Datenquellen Abhängiges Data Mart Enterprise Reporting Lösungen bei fachabteilungsübergreifende Auswertungen und vielen Datenquellen Ein Wechsel zwischen den verschiedene Ansätzen ist nur mit großem Aufwand möglich DOAG

25 Herausforderung Datenqualität Was ist eigentlich (Daten)qualität: Qualität ist nie absolut, sondern immer subjektiv in einem definierten Kontext Von Qualität spricht man, wenn die gestellten Anforderungen erfüllt werden Um Qualität messen zu können muss ein Qualitätsziel definiert sein Qualität ist, wenn der Kunde wiederkommt und nicht die Ware You cannot control what you cannot measure Tom DeMarco 1982 DOAG

26 Herausforderung Datenqualität Ursachen und Wirkung Ursachen (allgemein) Fehlerhafte Programmierung Fehlende Überprüfungen Falsche/unvollständige Datenerfassung Ursachen (im Data Warehose) Widersprüchliche Datenquellen Latenzprobleme Unzureichende Datenintegration DOAG

27 Herausforderung Datenqualität Problem-Beispiele im Data Warehouse: FK-Verletzung Geistersätze im Auftrags-System Widerspruch Produktnummern und -bezeichnungen stimmen nicht überein Strukturkonflikt Konzerndefinition stimmt im Faktura-System nicht mit der Definition des Vertriebssteuerungs-System überein Latenzkonflikt Auftragsinformationen mit fehlenden oder unzureichenden Kundeninformationen DOAG

28 Herausforderung Datenqualität Sicherstellung durch abhängige Data Marts Qualitätsschranke DOAG

29 Herausforderung Datenqualität Aufgaben des Enterprise Modell Integrationsebene Sicherstellung der Integrität durch ER-Modellierung: Primärschlüssel Fremdschlüssel Constraints Das Enterprise Modell bildet den Qualitätsanspruch ab Daten, die gegen die impliziten Prüfungen verstoßen werden abgelehnt, also nicht geladen Alle Prüfungen finden beim Transport der Daten aus der Staging Area in das Enterprise Modell statt DOAG

31 Fallbeispiele Probleme durch Reporting Ausgangslage Konzernreporting basierte auf ca. 250 Excel-Berichten, in der Regel eine gewachsene Lösung ca. 50 Excel-Tabellen direkt auf den Quellsystemen, die restlichen bauen auf diesen auf Berechnungen und Formeln werden an unterschiedlichen Stellen verwendet Komplexe Berechnungen erfolgen über Makros Es werden bei neuen Reporting Anforderungen neue Excel- Tabellen angelegt => Das Chaos wächst! DOAG

32 Fallbeispiele Probleme durch Reporting Problematik Bei Änderungen im Quellsystem müssen die 250 Berichte manuell durchgesehen und geändert werden Änderungen sind daher Aufwendig Seiteneffekte sind nicht abschätzbar Migrationsprobleme durch Makros Das KnowHow steckt in den Köpfen und nicht im System (keine Metadaten) DOAG

33 Fallbeispiele Probleme durch Reporting Mögliche Lösung Aufbau einer Reporting Datenbank, in der alle Quellen konsolidiert werden Definition klarer Datenqualitätsziele für den Übergang aus Stage in das Enterprise Modell Definierter Datenbewirtschaftungsprozess Aufbau mehrer fachbereichspezifischer Data Marts Einsatz eines Standard Reporting Werkzeugs, dass auf einem Metadaten-Layer aufsetzt Kapselung der Datenmodelle hinsichtlich der Fachbereichsnutzer DOAG

34 Fallbeispiele Probleme durch unabhängiges Data Mart Ausgangslage Reporting basiert auf 3 unabhängigen Data Marts, die direkt aus einem Quellsystem über eine Staging Area geladen werden Die Rohdaten werden täglich auf Dateisystem Ebene gesichert Daten werden in den Data Marts stark aggregiert Historisierung erfolgt beim zuladen zu den Data Marts Das größte Data Mart hat mittlerweile ca. 500GB Daten DOAG

35 Fallbeispiele Probleme durch unabhängiges Data Mart Problematik Bei Änderungen in den Quellsystemen müssen die Ladeprogramme für jedes Data Mart angepasst werden Wenn neue Kennzahlen berechnet werden sollen, müssen die Data Marts geändert und komplett neu aufgebaut werden Auswertungen über mehrer Data Marts hinweg sind aufwendig und laufzeitintensiv DOAG

36 Fallbeispiele Probleme durch unabhängiges Data Mart Mögliche Lösung Zwischen die Data Marts wird ein Enterprise Modell platziert In diesem wird die Historie erzeugt und die Datenqualität geprüft Änderungen in den Quellsystemen führen nur noch zu Anpassungen in den Ladeprozessen für das Enterprise Model Neue Kennzahlen können aus dem Enterprise Model abgeleitet werden Die Historisierung erfolgt nicht mehr in jedem Data Mart DOAG

38 Fazit Es gibt nicht die Data Warehouse Architektur Jeder Ansatz hat seine Berechtigung Die Architektur muss auf die Anforderung zugeschnitten sein Der Wechsel zwischen den Architekturansätzen ist aufwendig und teuer Man muss sich frühzeitig Gedanken um die richtige Architektur machen Aus Fehlern (auch anderer) lernen DOAG

39 Vielen Dank! DOAG