SAP Layered Scalable Architecture

Bis zur Beendigung meiner beruflichen Laufbahn habe ich mit allen Versionen von SAP BW bis einschl. 7.5 gearbeitet. In der Anfangszeit hat es für die Architektur eines DWH auf Basis SAP BW keine Architekturvorgaben gegeben. Entsprechend sahen die Anwendungen aus. Dazu kam, dass die Leistungsfähigkeit der Hardware aus heutiger Sicht recht bescheiden war. Wenn ich das noch richtig in Erinnerung habe, waren bei den ersten Versionen von SAP BW durchaus Transformationen an den Daten bereits im Quellsystem üblich. Da gab es Exits und ABAP-Erweiterungen im Quellsystem. Die Daten wurden +/- mundgerecht während der Extraktion aufbereitet und dann tröpfchenweise in das BW-System übertragen.

Referenzarchitekturen

Ich bin momentan noch auf der Suche danach, wann SAP das erste Mal eine Referenzarchitektur veröffentlichte. Muss so um Version 3.2 gewesen sein, bin mir da aber nicht sicher. Dieses war die Layered Scalable Architecture. Das Staging der Daten wurde verschlankt, Transformationen fanden nur noch im BW-System selbst statt, sofern nicht kundeneigene Erweiterungen in der Extraktion notwendig waren. Damit verschlankte sich das ETL, aus Sicht eines Supporters, erheblich. Fehlerquellen lassen sich so wesentlich besser lokalisieren, der Ladevorgang wurde stabiler.

Die Anforderungen an eine Referenzarchitektur ergeben sich aus den Anforderungen an ein BW-System:

Datenqualität und -konsitenz
Vermeidung von Redundanzen / Inseln
Wiederverwendbarkeit von Objekten und Daten. Dieses betrifft vor allem auch Stammdaten
Wartungsfähigkeit der Anwendung
Single Point of Truth (Spot)

Die LSA beschreibt den konzeptionellen Aufbau eines EDW, regelt das Staging in der Anwendung.

Mit der Einführung von SAP HANA wurde die Referenzarchitektur entsprechend angepasst.

LSA

SAP BW-Systeme mit konventioneller Datenbank

LSA++

SAP BW-Systeme mit HANA-Datenbank

Layered Scalable Architecture

Ebenen

Data Aquisition Layer

Anbindung der Quellsysteme
Dateneingang in die Anwendung, Übernahme der Daten aus der Extraktion im Quellsystem
Persistance Staging Area (PSA), bis zur Version 3.4? musste über die PSA verbucht werden, danach konnte die PSA genutzt werden
Die PSA kann als Kurzzeitspeicher für die Beladung verwendet werden, falls eine Beladung wiederholt werden muss
Übertragene Daten können alternativ zur PSA in schreiboptimierten DSO aufgenommen werden

Enterprise-Data-Warehouse-Layer

Herstellung des SPOT (Single Point of Trueth)
Zusammenführung von Daten aus unterschiedlichen Quellsystemen

Quality & Harmonization Layer

Bereinigung, Harmonisierung von Daten, unterschiedliche Definitionen
Anpassung der Daten

Data – Propagation Layer

Persistente Ebene
Bereitstellung der aufbereiteten Daten für das Reporting

Corporate Memory

In der Corporate Memory befindet sich die Historie der gespeicherten Daten
Auf konventionellen DB basierenden BW kann diese Funktion von der PSA oder von DSO übernommen werden
Das Corporate Memory wird unabhängig von der Fortschreibung in die Architected-Data-Marts gefüllt.
Quelle für Rekonstruktionen ohne erneuten zugriff auf Quellsysteme
Die Speicherung der Daten erfolgt im CM mit dem entsprechenden Modellprofil.
Das Staging der Daten muss entsprechend den Anforderungen unabhängig vom üblichen Datenfluss eingerichtet werden

Architected-Data-Mart-Layer

Business Transformation Layer

Reporting Layer

Virtualization Layer

Layered Scalable Architecture ++ (LSA++)

Änderungen

LSA++ ist eine Anpassung der Architektur der LSA auf die Umgebung innerhalb einer SAP HANA-Datenbank

Spaltenorientierte Datenbank

Vereinheitlichte und universellere Elemente

Virtuelle Elemente

Der Composit Provider fasst

Persistente Elemente

Nähe zur Datenbank

Näher am DBMS als bei BW-Systemen auf Basis konventioneller Datenbanken

Ebenen

Open Operational Data Store (Open ODS)

SAP HANA hat einen neuen Zugriffsmodus auf die Daten in Fremdsystemen
Operational Data Queue (ODQ), PSA wird dadurch obsolet, Daten können direkt, ohne Transformation, in ein aDSO geladen oder repliziert werden. Keine Zuordnung auf InfoObjekts notwendig, das aDSO wird i. R. auf Basis der DataSource-Felder definiert
Das Open ODS kann direkt in das Reporting eingebunden werden, schnelle und agile Bereitstellung von Informationen
Dies wird erreicht durch:
- Definition von wiederverwendbaren BW Semantiken auf den feldbasierten DataStore-Objekten (advanced) der Open-ODS-Schicht mit Hilfe von virtuellen Open ODS Views:
  - Rolle des DataStore-Objekts (advanced) (Fakten, Stammdaten, Texte)
  - Bedeutung der Felder (Merkmal, Kennzahl, Währung,…)
  - Definition von Assoziationen zwischen Open ODS Views (Fakten und Dimensionen: Star Schema, Stammdaten und Texte)
  - Definition von Assoziationen zwischen Open ODS Views und InfoObjects (s.u.)
- Kombination von Open ODS Views mit anderen InfoProvidern der Propagation- oder Architected-DataMart-Schicht über CompositeProvider
- Unmittelbares Querying auf der Open-ODS-Schicht über Open ODS Views und CompositeProvider

EDW Transformations

Funktional identisch mit der Funktion beim LSA

EDW Data Propagation Layer

Das Corporate Memory unterscheidet sich in der Funktion im LSA++ nicht von der im LSA

Corporate Memory

Funktion identisch mit der LSA
Aufgebaut aus aDSO, auf Reporting kann verzichtet werden
Da die Daten nur sehr selten benötigt werden, brauchen sie sich nicht permanent im Arbeitsspeicher befinden, dasaDSO kann entprechend auf Kalt gesetzt werden