Das modulare DWH-Modell - DOAG SIG BI/DWH 2010 - OPITZ CONSULTING - ArnoTigges
•
0 gefällt mir•1,364 views
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.
![[object Object],[object Object],Durchgängige Business Intelligence durch eine praktikable DWH-Referenzarchitektur ,[object Object],Das modulare DWH Modell](https://image.slidesharecdn.com/dasmodularedwh-modell-doagsigdwh-bi2010-opitzconsulting-arnotigges-111125063756-phpapp01/85/das-modulare-dwhmodell-doag-sig-bidwh-2010-opitz-consulting-arnotigges-1-320.jpg)
![Agenda ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (6)
Ähnlich wie Das modulare DWH-Modell - DOAG SIG BI/DWH 2010 - OPITZ CONSULTING - ArnoTigges
Ähnlich wie Das modulare DWH-Modell - DOAG SIG BI/DWH 2010 - OPITZ CONSULTING - ArnoTigges (20)
Mehr von OPITZ CONSULTING Deutschland
Mehr von OPITZ CONSULTING Deutschland (20)
Das modulare DWH-Modell - DOAG SIG BI/DWH 2010 - OPITZ CONSULTING - ArnoTigges
- 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
- 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
- 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
Hinweis der Redaktion
- 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)