Layered, Scalable Architecture (SAP BW)

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