Layered, Scalable Architecture (SAP BW): Unterschied zwischen den Versionen

Aus MattWiki
(Die Seite wurde neu angelegt: „== Eine Einführung == * LSA steht für Layered, Scalable Architecture. * LSA ist die Referenzarchitektur eines mehrschichtigen Data Warehouses von SAP“)
 
Keine Bearbeitungszusammenfassung
 
(9 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 2: Zeile 2:
* LSA steht für Layered, Scalable Architecture.
* LSA steht für Layered, Scalable Architecture.
* LSA ist die Referenzarchitektur eines mehrschichtigen Data Warehouses von SAP
* LSA ist die Referenzarchitektur eines mehrschichtigen Data Warehouses von SAP
* Jede Schicht stellt sozusagen einen Service dar und liefert einen bestimmten Mehrwert
* Die Implementierung sollte erweiterbar sein.
''' LSA Struktur '''
{| class="wikitable" style="text-align: center;"
|   || colspan="3" style="background-color:#bbbbbb;" | ↓ Reporting Frontend
|-
| rowspan="2" | Applikations-<br>schicht
| colspan="2" style="background-color:#dddddd;" | Reporting Layer
| rowspan="4" style="background-color:#dddddd;" | Operational<br>Data<br>Store
|-
| colspan="2" style="background-color:#dddddd;" | Business Transformation Layer
|-
| rowspan="3" | Wiederverwendbare<br>Schichten (Single<br>Point of Truth)
| Data Propagation Layer || rowspan="2" | Corporate<br>Memory
|-
| Quality and Harmonization Layer
|-
| colspan="3" | Data Acquisition Layer
|-
| &nbsp;
| colspan="3"  style="background-color:#bbbbbb;" | &uarr; DataSources
|}
Von den genannten Schichten erfüllt jede eine spezifische Aufgabe:
=== Data Acquisition Layer ===
* Unterste Schicht &rarr; Dient der LSA als Dateneingang
* Schnelles entgegen nehmen granularer Daten in Rohform
* Enthält "breite" extraktion von Daten für ggf. zukünftige Anforderungen
* Langzeitspeicherung findet typischerweise nicht hier, sondern zwecks Performance im Corporate Memory statt
* Umsetzung als PSA oder schreiboptimierte DSOs
=== Quality and Harmonization Layer ===
* Bereinigung, Harmonisierung, Transformation von Daten
* Unterschiedliche Quellsysteme auf eine gemeinsame Datenbasis bringen
* Mapping-Tabellen sollten historisiert abgelegt werden, da sich Harmonisierungen über die Zeit ändern
=== Data Propagation Layer ===
* Auch Propagator genannt
* Zentrale Schicht der LSA
* Bereitet Daten für Reporting vor
* Harmonisierung von Delta-Verfahren
* Anreicherung von Bewegungsdaten mit Stammdaten
* Speichern der vollständigen Breite der Information
* Häufig Implementierung per Standard-DSO
=== Business Transformation Layer ===
* Applikationsaufbereitende Schicht
* Stellt Daten für die Anwendungen in der gewünschten Form bereit
* Einfache und komplexe Berechnungen möglich
* Applikationsgetriebene Schicht
* Granularität ist vom Applikationsbedarf abhängig
* Implementierung per Standard-DSO oder InfoSource, falls keine Persistenz notwendig
=== Reporting Layer ===
* Zentrale Berichtsebene
* Stellt Daten für Reporting bereit
* Applikationsgetrieben &rarr; Nicht für andere Applikationen wiederverwendbar
* Implementierung per InfoCube, die optional per InfoSet oder MultiProvider verbunden werden
=== Corporate Memory ===
* Ist das Unternehmensgedächtnis
* Speichert Daten in der Form zum Ladezeitpunkt
* Führt komplette Historie
* Zweck: Auf Basis der historischen Daten neue Sichten implementieren oder komplett neu aufsetzen
* Daten sollten grundsätzlich unangetastet / untransformiert sein
* Um Speicher zu sparen können die Daten klassisch oder im Near Line Storage archiviert werden
=== Operational Data Store ===
* Speichert operationale Daten, z. B. wenn Reporting aus Quellsystem ins BW-Sstem verlagert werden soll.
* Gedacht für Ad-hoc-Auswertungen auf aktuellem Datenbestand
* Implementierung häufig über schreiboptimierte DSOs
[[Kategorie:SAP]]

Aktuelle Version vom 2. September 2017, 15:21 Uhr

Eine Einführung

  • LSA steht für Layered, Scalable Architecture.
  • LSA ist die Referenzarchitektur eines mehrschichtigen Data Warehouses von SAP
  • Jede Schicht stellt sozusagen einen Service dar und liefert einen bestimmten Mehrwert
  • Die Implementierung sollte erweiterbar sein.

LSA Struktur

  ↓ Reporting Frontend
Applikations-
schicht 		Reporting Layer Operational
Data
Store
Business Transformation Layer
Wiederverwendbare
Schichten (Single
Point of Truth) 		Data Propagation Layer Corporate
Memory
Quality and Harmonization Layer
Data Acquisition Layer
  ↑ DataSources

Von den genannten Schichten erfüllt jede eine spezifische Aufgabe:


Data Acquisition Layer

  • Unterste Schicht → Dient der LSA als Dateneingang
  • Schnelles entgegen nehmen granularer Daten in Rohform
  • Enthält "breite" extraktion von Daten für ggf. zukünftige Anforderungen
  • Langzeitspeicherung findet typischerweise nicht hier, sondern zwecks Performance im Corporate Memory statt
  • Umsetzung als PSA oder schreiboptimierte DSOs


Quality and Harmonization Layer

  • Bereinigung, Harmonisierung, Transformation von Daten
  • Unterschiedliche Quellsysteme auf eine gemeinsame Datenbasis bringen
  • Mapping-Tabellen sollten historisiert abgelegt werden, da sich Harmonisierungen über die Zeit ändern


Data Propagation Layer

  • Auch Propagator genannt
  • Zentrale Schicht der LSA
  • Bereitet Daten für Reporting vor
  • Harmonisierung von Delta-Verfahren
  • Anreicherung von Bewegungsdaten mit Stammdaten
  • Speichern der vollständigen Breite der Information
  • Häufig Implementierung per Standard-DSO


Business Transformation Layer

  • Applikationsaufbereitende Schicht
  • Stellt Daten für die Anwendungen in der gewünschten Form bereit
  • Einfache und komplexe Berechnungen möglich
  • Applikationsgetriebene Schicht
  • Granularität ist vom Applikationsbedarf abhängig
  • Implementierung per Standard-DSO oder InfoSource, falls keine Persistenz notwendig


Reporting Layer

  • Zentrale Berichtsebene
  • Stellt Daten für Reporting bereit
  • Applikationsgetrieben → Nicht für andere Applikationen wiederverwendbar
  • Implementierung per InfoCube, die optional per InfoSet oder MultiProvider verbunden werden


Corporate Memory

  • Ist das Unternehmensgedächtnis
  • Speichert Daten in der Form zum Ladezeitpunkt
  • Führt komplette Historie
  • Zweck: Auf Basis der historischen Daten neue Sichten implementieren oder komplett neu aufsetzen
  • Daten sollten grundsätzlich unangetastet / untransformiert sein
  • Um Speicher zu sparen können die Daten klassisch oder im Near Line Storage archiviert werden


Operational Data Store

  • Speichert operationale Daten, z. B. wenn Reporting aus Quellsystem ins BW-Sstem verlagert werden soll.
  • Gedacht für Ad-hoc-Auswertungen auf aktuellem Datenbestand
  • Implementierung häufig über schreiboptimierte DSOs
Abgerufen von „https://otremba.net/w/index.php?title=Layered,_Scalable_Architecture_(SAP_BW)&oldid=1508“