• Like
  • Save

Das modulare DWH-Modell - DOAG SIG BI/DWH 2010 - OPITZ CONSULTING - ArnoTigges

  • 2,769 views
Uploaded on

Der Vortrag beschreibt die Architektur eines serviceorientierten, modular erweiterbaren DWH-Modells und dem dazu gehörigen Berichtswesens. Er soll außerdem zeigen, wie ein solches Modell in ein …

Der Vortrag beschreibt die Architektur eines serviceorientierten, modular erweiterbaren DWH-Modells und dem dazu gehörigen Berichtswesens. Er soll außerdem zeigen, wie ein solches Modell in ein bereits existierendes, stark heterogenes Umfeld eingebunden werden kann.
Die verschiedenen Schichten des DWH-Modells sowie die Einbindung in das Umfeld werden dabei detailliert beschrieben. Auf die Vor- und Nachteile der verschiedenen Modellierungsmöglichkeiten (3NF, Stern, Cube), sowie Aspekte der zukünftigen Erweiterung und Veränderung wird ebenfalls eingegangen. Eine kurze Übersicht über Tuning und Sicherheitsaspekte beendet den ersten Teil.
Der zweite Teil besteht aus einer Übersicht über die Einbindung des Berichtswesens in die Gesamtarchitektur. Verschiedene Ansatzmöglichkeiten für die Bedienung der Anforderungen verschiedener Nutzergruppen werden erarbeitet. Zuletzt werden Ideen zur Konsolidierung und Ablösung eines stark zerklüfteten, sich widersprechenden Berichtswesens gegeben.
Der Vortrag soll damit DWH-Architekten Möglichkeiten aufzeigen, wie man ein DWH zukunftssicher und flexibel modellieren und in ein heterogenes Umfeld einbetten kann. OPITZ CONSULTING Berater Arno Tigges hielt diesen Vortrag am 29.06.2010 bei der DOAG SIG BI/DWH in Köln.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,769
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Die Bedürfnisse des Business an Reporting/BI sind in den letzten Jahren signifikant größer geworden Auch die DWH Tools und Technologien haben sich deutlich weiterentwickelt Die Erwartungen an einzelne Bereiche ist großer geworden, z.B. bessere Analysemöglichkeiten, höhere Detailtiefe, bessere Datenqualität, kürzere Ladezyklen Es gibt aber auch ganz neue Erwartungen, z.B. bzgl. Compliance-Anforderungen, Unstrukturierte Datenquellen, SOA auch für externe Stakeholder Hinweise: Größere Datenmengen -> Data Lifecycle Management Single Point of Truth -> DWH haben das eigentlich immer als Ziel gehabt, aber durch unterschiedliche Insellösungen und nicht durchgägniges DWH entstanden oft widersprüchliche mehrfache „Points-of-Truth“ Compliance -> Security Flexible Anpassungsmöglichkeiten -> Informationen müssen langfristig verwaltet und angereichert werden können, ohne dass Business-Änderungen nur per Re-Design des DWH klappen .. -> Die Architektur muss Zukunftssicher sein
  • Kurzer Anriss dieser beiden Grundansätze als Vorbereitung eines Fazits des Vortrags: die Balance zwischen beiden Ansätzen ist wichtig Anmerkungen: Oracle unterstützt technologisch beides Des einen Vorteil sind des anderen Nachteil und umgekehrt
  • 1: DWH Projekte scheitern häufig, da die Komplexität unterschätzt wird, keine Experten zu rate gezogen werden, Ergebnisse zu spät kommen, und dann der Nutzen auch noch den Stakeholdern nicht wirklich klar gemacht werden kann, bzw. die Anzahl an Nutzern im Verhältnis zum „großen“ Projekt sehr klein ist 2: Slogan „Never touch a running system“ insbesondere anzuwenden auf „never change a loading ETL program“ Fehlendes Metadatenmanagement führt oft zu dem beschriebenen Lösungen: Alles richtig und (z.B. von OC) herrvoragend angewendet…. Und um das Ganze zu ermöglichen, die darauf abgestimmte „PRAKTIKABLE“ Referenzarchitektur
  • Kurzer Abriss, was überhaupt eine „Referenz“-Architektur darstellen soll. Durch aktuelle Technologien, wie z.B. den OBI-Server als Abstraction Layer, besser umsetzbar, also praktikabel
  • erstes Übersichtsdiagram als Einstieg. Simple Aufteilung in Quelle -> Management -> Access, begleitet von ETL und umrandet von Security Security ist „allgegenwärtig“, deshalb außen herum ETL, Messaing und Metadaten auf dieser Folie erläutern (nicht auf der nächsten) Anknüpfen zu Life-Cicle-Management und durchgängiges Metadatenmanagement, was in folgenden Vorträgen des Tages thematisisert wird!
  • Diese Folie baut sich Stück für Stück auf, alle einzelnen Komponenten werden erläutert. Dies ist die zentrale Grafik und diese Folie benötigt sicher 5 bis 10 Minuten! (Einblendeffekte müssen noch gemacht werden!!!) Quellen: Bei Quellen kommen natürlich auch externe Daten vor, hier sind nur diese vier Quellen exemplarisch angegeben Real-Time Provisioning ist via Messaging z.B. implentierbar, oder change-tracking mit log-mining etc. Alle möglichen „Spielarten“ sind hier vorstellbar, beim befüllen der Staging Area Stage: Im Stage kann/sollte auch abgekoppelt werden, wann Daten von der Quelle ins Stage gelangen, und wann sie weiter ins Foundation Layer transportiert werden. So kann z.B. der Stage auch als zwischenlager/Puffer dienen Selbstberständlich findet DQM im Stage statt, zurückgewiesene Daten bleiben dort „hängen“ Foundation: Auch Core DWH gennant. Gilt als HERZ des DWH. Auch Atomic Layer genannt, weil hier die Daten auf tiefster Detailebene liegen (Devlin/Inmon). Historisierung kann hier stattfinden, da dies im 3NF deutlich einfacher geht, als im Dimensionsmodell WICHTIG: Prozessneutrale Speicherung, also rein auf Datenmanagement ausgelegt und nicht auf das Business. Hier können vorgefertigte Enterprise Modelle zum einsatz kommen, oder man fängt tatsächlich mit einem weissen Blatt Papier und den Ausdrucken der Datenmodelle der Quellen an und modelliert „nach Lehrbuch“ das 3NF Modell. Access+Performance Dies ist der Kimbal Teil, hier findet man nun Cubes/Dimensionen und alles so aufbereitet, dass es für Navigation und Abfrage optimiert ist Analysis Sandpit evtl. wenn zeit ist kurz erklären. Evtl. mach ich dazu noch eine optionale Folie, ansonsten auf der Tonspur erklären Hier sollten z.B. auch Data Marts eingefangen und eingebettet werden, um Insellösungen zu vermeiden. Jedes Data Mart kann hier auf die entsprechenden Zielbedürfnisse hin modelliert sein, greift aber immer über das Foundation Layer zu, nur so bekommt man einen „wirklichen“ Single-Point-of-Truth BI Abstraction Layer: Beispiel OBI Server, der ist genau soetwas! Vorteile erläutern… Die vier Kästen am Rand sind nur Beispiele, zukünftige andere Anwenden werden genau dort in der Architektur platziert. Wichtig ist stets: Der Zugriff führt wenn eben möglich über das grüne Kästchen, sofern aber das nicht möglich ist, kann auf alle anderen, weiter „entfernten“ Layer durchgegriffen werden. Das wird dadurch symbolisiert, dass der grüne Balken nicht bis ganz oben und nicht bis ganz unten geht! MVs = Materialized Views AWs = Analytical Workspaces CTAS = Create Table As Select
  • Standard BI Applikationen (COTS = Commercial out the shelf) können Daten direkt an das Access Layer liefern, z.B. über vordefinierte, vorgegebenen ETL Strecken die solche Tools mitbringen. Oder man geht den „normalen“ Weg über Staging etc. man kann auch beides für jeweilige Teile machen, dann muss aber im Access-Layer sichergestellt werden, dass für diese Daten dort ein „Single-Point-of-Truth“ hergestellt wird
  • Jegliche Daten innerhalb der verschiedenen Layer können von jedem BI Tool zugegriffen werden, genauso wie auf ETL Metadaten oder Data Quality Metadaten. Mit diesem allgemeinen Zugriff hat man stets die Möglichkeit eine weitreichende Analyse / Data Mining zu betreiben. Kernpunkt: ist etwas (bislang) nicht im Access and Performance Layer vorhanden, so greife ich auf das Foundation Layer zu. Ist es auch dort nicht vorhanden, dann evtl. im Staging? Letztendlich holt man, wenn nichts anderes geht, die Daten aus dem Quellsystem selber. Der letzte Punkt ist wichtig: eine möglichst offenes Datenzugriffskonzept mach das DWH erst als wirklich zentrales und durchgängig verwendbaren „Single-point-of-Truth“ Man kann schnell im Berichtswesen auf aktuelle Bedürfnisse reagieren, ohne dass die Daten sofort komplett im DWH liegen müssen (was ja nach wie vor nicht ganz so schnell geht) Wird ein solcher Report langfristig genutzt, werden alle benötigten Daten (siehe auch weiter unten) Stück für Stück in die diversen Layer integriert.
  • BI-Tools: z.B. für Planung und/oder Hochrechnung Anriss des Themas „EPM“ und „Deming Kreis“ Für EPM Szenarien ist diese Architektur somit auch sehr gut. Das Thema geht aber weit über diesen Vortrag hinaus Im Sandpit können z.B. neue Strukturen evaluiert werden. Wenn die Ergebnisse entsprechend den Erwartungen sind, können dann solche neuen Strukturen umgesetzt werden und somit zurück in das Business fließen (Beispiel: Strukturkennzahlen) Daten, die zurückfließen sollen, gehen immer diesen Kreis. NIEMALS fließen Daten den umgekehrten Weg, also niemelas vom Tool in das Access Layer und dann weiter in das Foundation Layer, usw.!
  • Ein durchgängiges DWH muss zum Ziel haben, dass ALLE Reortinganforderungen über das DWH agewickelt werden. Mit dem beschriebenen Vorgehen und der Referenzarchitektur funktioniert das, da es (theoretisch) keine Einschränkungen bzgl. Machbarkeit gibt. Ein Report wird im Zweifel sozusagen zunächst komplett am Data Warehouse vorbei entwickelt, ist aber trotzdem Teil der Architektur und kann anschließend in diese Integriert werden. Mehrere Vorteile: Man kann viel schneller auf Business Änderungen Reagieren, ohne dass dabei wieder Insellösungen entstehen (also Reporting am Warehouse vorbei) Man kann die Usage der neuen Reporte tracken und daraus eine Roadmap machen, was in Zukunft in die Warehouse Layer integriert werden soll (so kann man auch die ursprünglich mal vom Fach als extrem wichtig deklarierten Berichte, die aber dann doch nur einmal genutzten wurden, dem echten DWH heraushalten) Ein BICC kann als zentrale BI Stelle im Unternehmen für Reporting etabliert werden, die über die Architektur die Möglichkeit haben, wirklich alle Anforderungen zu erfüllen (theoretisch)
  • Ein durchgängiges DWH muss zum Ziel haben, dass ALLE Reortinganforderungen über das DWH agewickelt werden. Mit dem beschriebenen Vorgehen und der Referenzarchitektur funktioniert das, da es (theoretisch) keine Einschränkungen bzgl. Machbarkeit gibt. Ein Report wird im Zweifel sozusagen zunächst komplett am Data Warehouse vorbei entwickelt, ist aber trotzdem Teil der Architektur und kann anschließend in diese Integriert werden. Mehrere Vorteile: Man kann viel schneller auf Business Änderungen Reagieren, ohne dass dabei wieder Insellösungen entstehen (also Reporting am Warehouse vorbei) Man kann die Usage der neuen Reporte tracken und daraus eine Roadmap machen, was in Zukunft in die Warehouse Layer integriert werden soll (so kann man auch die ursprünglich mal vom Fach als extrem wichtig deklarierten Berichte, die aber dann doch nur einmal genutzten wurden, dem echten DWH heraushalten) Ein BICC kann als zentrale BI Stelle im Unternehmen für Reporting etabliert werden, die über die Architektur die Möglichkeit haben, wirklich alle Anforderungen zu erfüllen (theoretisch)

Transcript

  • 1.
    • Arno Tigges, Seniorberater
    • OPITZ CONSULTING München GmbH
    Durchgängige Business Intelligence durch eine praktikable DWH-Referenzarchitektur
    • DOAG SIG DWH/BI, Köln, 29. Juni 2010
    Das modulare DWH Modell
  • 2. Agenda
    • Hintergrund Was sind die aktuellen Anforderungen an DWH/BI?
    • Praktikable DWH Referenzarchitektur Wie wird man den aktuellen Anforderungen gerecht?
    • Einbindung in die Gesamtarchitektur Wie führe ich eine DWH/BI-Lösung durchgängig ein?
    • Fazit
  • 3.
    • 1
    Hintergrund
  • 4. Aktuelle Anforderungen an Business Intelligence
    • Aktuelle Geschäftsprozesse haben die Erwartungen an Business Intelligence deutlich gesteigert
      • (Near-)Real-Time Data Warehouse
      • durchgängige, also unternehmensweite Business Intelligence
      • sowohl tiefere als auch breitere Analysemöglichkeiten
      • Verarbeitung von immer größeren Datenmengen
      • perfekte Datenqualität und ein echter „Single Point of Truth“
      • unstrukturierte Datenquellen
      • Compliance and Corporate Governance
      • stets flexible Anpassungsmöglichkeiten und Zukunftssicherheit
  • 5. „ Die Zwei“ Modellierungsansätze
    • Ralph Kimbal
      • Dimensionales Modell mit Stars und Snowflakes
      • vereinfachtes „denormalisiertes“ Datenmodell
      • auf das Abfragen von Daten ausgerichtet
    • Barry Devlin / Bill Inmon
      • „ der Teufel liegt im Detail“, also stets größtmögliche Detailtiefe
      • normalisiertes 3NF-Datenmodell
      • auf das Datenmanagement ausgerichtet
    Vorteil Nachteil Kimbal
    • einfache Navigation (Drills)
    • schnelle Datenzugriffe
    • eingeschränkte Analysemöglichkeiten
    • nötige Anpassungen u. U. sehr komplex
    Devlin Inmon
    • effektives Datenmanagement
    • kein Verlust von Detailtiefe oder Historisierung
    • Performance oft problematisch
    • komplexe 3NF-Strukturen für Anwender
  • 6. Typische Probleme und Lösungsansätze
    • Probleme:
    • Ein DWH ist kompliziert und nur langwierig einzuführen … (… und nutzt am Ende ja sowieso nur einigen wenigen.)
    • Selbst kleinere Änderungen im DWH sind sehr kompliziert … (… bei größeren Änderungen fängt man besser gleich von vorne an.)
    • Es entstehen mehrere kleinere Insel-Lösungen ... (… die untereinander nicht einmal abgleichbar sind: Multiple Points of Non-Truth)
    • Lösungen:
    • „ Think Big – Start Small“ Iterativ-inkrementelles VGM
    • Durchgängiges Metadatenmanagement und geeignete Tools
    • Enterprise DWH-Projekte für durchgängiges BI
  • 7.
    • 2
    Praktikable DWH-Referenzarchitektur
  • 8. Referenzarchitektur
    • Die Referenzarchitektur …
      • … ist nichts „Neues“.
      • … ist aber mit aktuellen technologischen Möglichkeiten besser umsetzbar.
      • … ist keine konkrete Anleitung.
      • … ist geeignet als Leitfaden für eine neu zu implementierende Architektur.
      • … kann auch als Roadmap für Änderungen vorhandener Architekturen dienen.
      • … kann vollständig oder nur in Teilen umgesetzt werden.
  • 9. Hauptkomponenten der Architektur Security Informations-Quellen Quellen Informations-Management Data Warehouse BI- / EPM-Tools Informations-Zugriff ETL, Messaging und Metadaten
    • Design:
    • Das Farbschema ist im Design als „OC 2009“ hinterlegt.
    • Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.
    • Die Standardfarben sind:
  • 10. Details der Architektur Security Quellen Staging Layer Foundation Layer Access + Perfor-mance Layer unstrukturierte Daten Performance Management Apps Master-Daten Standard BI-Applikationen temporäre Daten zurück-gewiesene Daten prozess-neutrales Daten-model in 3NF eingebettete Data Marts MVs, AWs, CTAS Analyse Sandkasten BI-App-Daten ETL, Messaging und Metadaten BI Abstraction and Query Generation operative Daten Advanced Analysis Tools Alerts, Dashboards, Reports, Queries Web Services
  • 11. Datenbewirtschaftung Security Quellen Staging Layer Foundation Layer Access + Perfor-mance Layer unstrukturierte Daten Performance Management Apps Master-Daten Standard BI-Applikationen temporäre Daten zurück-gewiesene Daten prozess-neutrales Daten-model in 3NF eingebettete Data Marts MVs, AWs, CTAS Analyse Sandkasten BI-App-Daten ETL, Messaging und Metadaten BI Abstraction and Query Generation operative Daten Advanced Analysis Tools Alerts, Dashboards, Reports, Queries Web Services
  • 12.
    • 3
    Einbindung in die Gesamtarchitektur
  • 13. Informationsbereitstellung
    • Jede BI-Anwendung kann auf alle Daten jedes Layers zugreifen.
    • 1. Wahl: Daten über den „BI Abstraction“-Provider beziehen. (Also z. B. aus dem Oracle BI Server)
    • 2. Wahl: BI-Tools dürfen direkt auf Foundation, Stage oder Quelle zugreifen.
    • Ergebnis:
    • Es können alle Report- und Analyse-Anforderungen flexibel und schnell mit dem DWH-Modell zur Verfügung gestellt werden.
    • Alles was an Informationen im DWH vorhanden ist, wird auch genutzt.
    • Es werden keine „Insellösungen“ provoziert.
  • 14. Informationsbereitstellung Security Quellen Staging Layer Foundation Layer Access + Perfor-mance Layer unstrukturierte Daten Performance Management Apps Master Daten Standard BI-Applikationen temporäre Daten zurück-gewiesene Daten Prozess-neutrales Daten-model in 3NF eingebettete Data Marts MVs, AWs, CTAS Analyse Sandkasten BI-App-Daten ETL, Messaging und Metadaten BI Abstraction and Query Generation operative Daten Advanced Analysis Tools Alerts, Dashboards, Reports, Queries Web Services
  • 15. Bidirektionale Integration
    • Gewonnene Informationen fließen direkt zurück
      • BI-Tools erzeugen neue Daten.
      • Auch der „Analyse-Sandkasten“ dient experimentellem Data Mining und erzeugt Daten.
      • Gewonnene Daten müssen bewahrt werden, um den Mehrwert zu sichern.
      • Diese fließen entweder direkt in das Staging Layer …
      • … oder zunächst in die Quelle und dann über die ETL Strecke zurück ins Data Warehouse.
    • Datenqualität verbessern
      • Ergebnisse von Auswertungen können auch zur Verbesserung der Datenqualität genutzt werden.
      • Die Web-Service-Schnittstelle kann z. B. von MDM-Lösungen genutzt werden.
  • 16. Entwicklung und Einführung neuer Reportinganforderungen
    • Iterativ-inkrementelles Vorgehen
      • Um eine neue Anforderung zu realisieren, fehlen meistens die nötigen Daten im Warehouse.
      • Oft müssen diese zunächst integriert werden,
      • erst dann können konkrete Anforderungen definiert werden.
      • Mit iterativ-inkrementellem Vorgehen nähert man sich schrittweise dem Ziel.
    PM, tCM, RM Ergebnis der Iteration 1. Analyse 2. Design 3. Qualitätsdefinition 4. Lösungs- Implemen- tierung 5. Qualitätsmessung, Lieferung
  • 17. Entwicklung und Einführung neuer Reportinganforderungen
    • Iterativ-inkrementelles Vorgehen mit der Referenzarchitektur
      • Während des Designs greift der Report über den BI Abstraction Provider (evtl. sogar ausschließlich) auf die Quellsysteme durch
      • Sobald die Anforderungen verstanden sind, werden die Daten sukzessive in die DWH Layer integriert
      • Der Report selber muss nicht adaptiert werden, sondern nur die Metadaten müssen angepasst werden
    • Ergebnis: schnellere Lieferung der Ergebnisse
  • 18.
    • 4
    Fazit
  • 19. Fazit Anforderung Vereinfachung durch Referenzarchitektur (Near-)Real-Time DataWarehouse durch die prinzipielle Architektur u. neue Technologien durchgängiges, also unternehmensweites BI durch schnelle Umsetzung von Anforderungen und Vermeidung von Insellösungen sowohl tiefere als auch breitere Analysemöglichkeiten durch Balance zwischen „Kimball“ und „Devlin/Inmon“-Ansätzen Verarbeitung von immer größeren Datenmengen durch Lifecycle Management und Redundanzfreiheit im 3NF Foundation Layer perfekte Datenqualität und ein echten „Single Point of Truth“ durch Integration aller Data-Marts unstrukturierte Datenquellen durch die prinzipielle Architektur u. neue Technologien Compliance and Corporate Governance durch das übergreifende Security-Konzept und die Historisierungsmöglichkeiten im 3NF Stets flexible Anpassungs-möglichkeiten und Zukunfts-sicherheit durch einfache Integration, Datenzugriff auf alle Layer und Anpassungsfähigkeit bzgl. Nutzung verschiedener Tools
  • 20. Fragen und Antworten
  • 21. Kontakt
    • OPITZ CONSULTING München GmbH Weltenburger Straße 4 81677 München Tel. +49 89 680098-1467 [email_address]
    • Besuchen Sie uns im Internet: www.opitz-consulting.com
    Quellen: „ Enabling Pervasive BI through a Practical Data Warehouse Reference Architecture“ An Oracle Whitepaper, February 2010 http://www.oracle.com/us/solutions/datawarehousing/058925.pdf
    • Arno Tigges
      • Project Manager