BI mit großen Datenmengen · Identifizierung welche ETL SDE oder SIL Tasks haben eine hohe ... Bei Task mit stark schwankenden Datenmengen im POST SQL des SDE ... Informatica DAC

BI mit großen Datenmengen

Christian CasekRiverland Solutions GmbH 2010

Riverland Solutions GmbH

01.11.20102© RiverlandSolutions GmbH

► Hochkarätiges Team von Technologie- und Projektmanagement-Experten (50+)

► Kernteam hat mindestens 8 Jahre Siebelerfahrung

► Hoher Technologie und Integrationsfokus

► Starker Erfahrungshintergrund in nationalen wie internationalen Projekten

► Hochprofessioneller aber pragmatischer Ansatz

► Fokus auf Qualität und Wertschöpfung

► Oracle BI Projektierungen in über 10 Projekten

► Oracle Certified Partner

► Erster Oracle BI Partnerschaft in Deutschland (2008) mit dem Produkt Oracle BI Suite (EE und SE)

Technologie und Implementierung

► Oracle CRM Siebel CRM

► Oracle Business Intelligence Analytisches CRM Operatives BI in CRM

► Oracle Fusion Middleware Integration

Who Are We?

Christian Casek

Who am I?

► Senior BI Berater bei der Riverland Solutions GmbH

► Operativ tätig in BI Projekten als Architekt und Consultant

► Seit 5 Jahren BI Erfahrung mit Oracle BI EE(Siebel Analytics) und Crystal

Reports (Business Objects)

► In verschiedenen BI Projekten in diversen Rollen mitgewirkt

► Erfahrung mit der Integration des Oracle BI Publishers(print-ready Reporting) in

Oracle CRM Applikationen


Fragestellung

Welche Fragen werden beantwortet

► Wie können kurze Antwortzeiten der Oracle BI Dashboards gewährleistet werden?

► Wie soll bei Laufzeitproblemen oder langen Laufzeiten vorgegangen werden?

► Welche Maßnahmen können ergriffen werden, um die Performance nachhaltig zu

verbessern?

► Wie kann die Laufzeit der ETL Läufe reduziert werden?


Ist-Situation

Szenario

► Loyaltygestütztes System mit Prämien in Form von Punkten

► Bis zu 500 Mio. neuer bzw. aktualisiertet Datensätze täglich

► Fachliche Reduzierung der Datenmenge bereits durchgeführt

Problemstellung

► Lange ETL Laufzeiten sprengen die gesetzten SLA

● Ist-Situation: ETL Laufzeit 10-12 Stunden

● Soll Anforderung: ETL Laufzeit max. 8 Stunden

► Lange Antwortzeiten der Standard und Ad-hoc Berichte

● Ist-Situation: Berichtauswertungszeit > 30 Minuten

● Soll Anforderung: Berichtauswertungszeit < 10 Minuten


Oracle BI

Systemüberblick


Datawarehouse

Schicht

Logische BI

Schicht

BI Server

RPD

Request und Dashboard

Schicht

Datenbanken

Informatica

DAC

Request

Dashboard

Anforderungsaufnahme



Datawarehouse

Schicht

Logische BI

Schicht

BI Server

RPD


Schicht

Datenbanken

Informatica

DAC

Request

Dashboard



► Bereits bei der Anforderungsaufnahme ist eine Laufzeitbetrachtung durchzuführen

► Reduzierung der Kundenwünsche auf die tatsächlich benötigten Attribute und

Kennzahlen

● Die zu Ladende Datenmenge kann hier reduziert werden

► Hinterfragen des fachlichen Nutzens hinter der Anforderung

● Verständnis für das Geschäft des Kunden erlangen

● Durch das Verständnis können die Wünsche des Kunden besser umgesetzt werden

► Benötigte Aktualität des Datenbestandes festlegen

● Festlegen welche Daten täglich, wöchentlich und monatlich geladen werden können


Datawarehouse Schicht


Datawarehouse

Schicht

Logische BI

Schicht

BI Server

RPD


Schicht

Datenbanken

Informatica

DAC

Request

Dashboard


ETL Laufzeit - Szenario


► Identifizierung welche ETL SDE oder SIL Tasks haben eine hohe Laufzeit haben.


ETL Laufzeit - Lösungsansatz


► Das betreffende SQL an Hand des DB Explain Plans analysieren




► Table Access Full => Verwendung von DB Hint „parallel“

► Syntax parallel (W_PERSON_D, 8): Tabellenname, Anzahl zu verwendender

Prozesse










► Generell führt Oracle DB den optimalen Explain plan aus

► Wichtige Voraussetzung: Statistiken der Tabellen müssen aktuell sein

► Problem: starke Schwankungen der Datenmengen beim ETL

► Folge:

● Statistiken nicht korrekt

● Oracle DB führt nicht den optimalen Explain Plan aus

● Lange Laufzeiten

► Lösung: Bei Task mit stark schwankenden Datenmengen im POST SQL des SDE

Workflows eine Statistikberechnung erzwingen:

begin dbms_stats.gather_table_stats

ownname => 'OLAP',tabname =>'WC_LOY_CARD_DS',

estimate_percent => 1,

method_opt => 'for all columns size 1')\;

end\;




► Fachliche Reduzierung von Ladeintervallen bei Aggregaten (Aggregatslauf auf das

Wochenende verlagern)

► Reduktion der ETL auf das Laden der tatsächlich benötigten Spalten

► Anlegen von zusätzlichen Indexen

► Look-Ups in die SQLs der Source Qualifier einbinden


Massenänderungen - Szenario


► Durch eine fachlichen Anforderung wird im operativem System die Berechnung

eines Kundenkartenattributs geändert.

► Eine Aktualisierung des kompletten Kundenkartenstamms (ca. 36 Mio. Datensätze)

ist notwendig.

► Ein Update über den inkrementellen ETL ist nicht möglich, da das Zeitfenster zu

gering ist, um einen solchen Massenupdate zu ermöglichen.


Massenänderungen - Lösungsansatz


► Die DB Transaktion INSERT ist deutlich schneller als die Transaktion UPDATE


WC_CARD_D

WC_CARD_D

_TMP

WC_MIG_ATT

INSERT

DROP Index

on

WC_CARD_D

WC_CARD_D

_BKP

WC_CARD_D

_TMP

Create Index

on

WC_CARD_D

RENAME

Logische BI Schicht


Datawarehouse

Schicht

Logische BI

Schicht

BI Server

RPD


Schicht

Datenbanken

Informatica

DAC

Request

Dashboard


Aggregate

Logische BI Schicht

► Im RPD des BI Servers lassen sich die Logischen Datenquellen für verschiedene

Ebenen festlegen

► Verwendung von Aggregaten auf verschiedenen Levels


Aggregate

Logische BI Schicht

► Reportanforderungen analysieren und Zusammenhängen zwischen Kennzahlen

und Dimensionattributen erkennen

► Gruppierungen festlegen

► Aggregat so wählen, dass es idealerweise für mehrere Reports Verwendung findet


Aggregate

Logische BI Schicht

► Das Beladen der Aggregate verlängert den ETL Prozess

► Priorisierung zwischen ETL Laufzeit und Report Antwortzeiten muss getroffen

werden

► Aggregate vergrößern den Bedarf an Speicherplatz auf der Datenbank


Fragmentation - Szenario

Logische BI Schicht

► Lange Antwortzeiten eines Ad-hoc Reports im Themenbereich Transaktionen

► Datenmenge der Tabelle WC_LOY_TXN_F > 300 Mio. Datensätze

► Ad-hoc Report auf Detailebene, somit keine Verwendung von Aggregaten möglich


Fragmentation - Lösungsansatz

Logische BI Schicht

► Analyse wie die Tabelle sinnvoll verkleinert werden kann

► Teilung der Tabelle in mehrere Teile anhand des am häufigsten verwendeten

Filterkritteriums (z.b. Zeit)


WC_LOY_TXN_F

WC_LOY_TXN_F

_Q1

WC_LOY_TXN_F

_Q2

WC_LOY_TXN_F

_Q3

WC_LOY_TXN_F

_Q4


Logische BI Schicht

► Tabellen im Logischem Layer des RPD einfügen und bekanntgeben



Logische BI Schicht

► Für jede Sourcetabelle muss das Fragment definiert werden, dass sie enthält


Request und Dashboard Schicht


Datawarehouse

Schicht

Logische BI

Schicht

BI Server

RPD


Schicht

Datenbanken

Informatica

DAC

Request

Dashboard


Antwortzeiten - Szenario


► Die Wartezeit eines Reports beträgt über 20 Minuten.

► Der Report ist in Tabellarischer Form und liefert mehrere Tausend Zeilen und ca. 30

Spalten.

► Der Report wird mehrmals täglich in leicht veränderter Form ausgeführt.


Antwortzeiten - Lösungsansatz


► Verwendung von I-Bots

► Über I-Bots kann der Report jeden morgen vor den Usern ausgeführt und gecached

werden.

► Die Antwortzeit bei Ausführung der User wird deutlich verbessert


Antwortzeiten - Lösungsansatz


► Fachliches Hinterfragen des Reports:

● Welchen Nutzen bringt ein Report mit mehreren tausend Zeilen und über 30 Spalten?

● Dient der Extrakt einem anderen Tool als Input?

● Welche Information möchten die Anwender aus diesem Report ziehen?

► Reduktion der Reports auf wenige Spalten

● Management Reports sollte primär grafische Darstellungen enthalten

● Operational Reports enthalten mehr Daten in tabellarischer Form

● Drill-down von Management Ebene auf operative Sicht ermöglichen

► Schulungen für Power-User oder Endanwender

● Durch Schulung das Verständnis des BI vermitteln

● Anleiten zur Erstellung von intelligenten Ad-hoc Reports und Dashboards

● Verwendung von Filtern zur Einschränkung der Ergebnismenge nahelegen


Zusammenfassung

► Verständnis beim Kunden für BI aufbauen (Oracle BI ist kein Excel-Reporting Tool)

► Verständnis für das Geschäft und die fachlichen Anforderungen des Kunden

aufbauen

► Laufzeitbetrachtung muss bereits bei der Anforderungsaufnahme vorgenommen

werden

► In der Datawarehouseschicht liegt das größte technische Optimierungspotenzial

► Optimales Zusammenspiel und Ausgewogenheit aller drei BI Schichten notwendig

► Je später Laufzeitprobleme erkannt werden desto „teurer“ ist die Behebung


Offene Fragen?


Technologie und Implementierung

Vielen Dank für Ihre Aufmerksamkeit

www.riverland.com

Documents

BI mit großen Datenmengen · Identifizierung welche ETL SDE oder SIL Tasks haben eine hohe ... Bei Task mit stark schwankenden Datenmengen im POST SQL des SDE ... Informatica DAC