Kernelement der persistenten Datenhaltung ist auf SAP BS4/HANA neben den Stammdaten der Attribute innerhalb der InfoObjecte, Typ Merkmal ausschließlich das advanced DataStore-Object. Während in den InfoObjecten Stammdaten handelt werden im aDSO vornehmlich Bewegungsdaten gespeichert. Durch die Optionen beim Tabellenaufbau auf einer SAP-HANA Datenbank entfällt die Notwendigkeit zum Sternschema, wie er beim InfoCube in der Welt des klassischen SAP BW verwendet wurde. Durch den flexibleren Aufbau kann das aDSO alle Aufgaben im Datenfluss der Bewegungsdaten übernehmen.
Historisches
Das aDSO ist eine Fortentwicklung des in der klassischen Welt des SAP BW vorhandenen DataStore Objects. Dieses wurde bis zur Version 3.5 (?) von SAP als Operational DataStore Object (ODS) bezeichnet.
Die Grundfunktion des aDSO ist in BW/4HANA durch die geänderte Architektur des Systems in ihrer Grundfunktion als Nativ DataStore Object (nDSO) verfügbar. Darüber, ob und in welcher Funktion dieses bei Datenflüssen innerhalb des DBMS zum einsatz kommt, kann ich nichts sagen.
Beschreibung
Aufgabe
Persistente Speicherung von Daten.
Redundante Speicherung der Daten in unterschiedlichen Tabellen um im Rahmen eines automatisiert Generierten Datenflusses eine definierte Funktionalität zu bekommen.
- Deltaupload
- Snapshot
Aufbau
Für die Benutzung sind die ersten drei Tabellen relevant:
- Eingangstabelle
- Aktive Daten
- Change Log
Die Nutzung ergibt sich aus der jeweiligen Modellierungsvariante. Die anderen Tabellen und Views sind von technischem Interesse.
Tabellen und Views
| Tabelle / View | Inhalt | Namenskonvention | Anmerkung |
|---|---|---|---|
| 1 (Tabelle) | Eingangstabelle | /BIC/A<technischer Name> 1 | |
| 2 (Tabelle) | Aktive Daten | /BIC/A<technischer Name> 2 | |
| 3 (Tabelle) | Change Log | /BIC/A<technischer Name> 3 | |
| 4 (Tabelle) | Validitätstabelle | /BIC/A<technischer Name> 4 | |
| 5 (Tabelle) | Referenzpunkte | /BIC/A<technischer Name> 5 | |
| 6 (View) | Sicht für Extraktion | /BIC/A<technischer Name> 6 | Zeilenorientierter Tabellenaufbau (?) |
| 7 (View) | Sicht für Reporting | /BIC/A<technischer Name> 7 | Spaltenorientierter Tabellenaufbau (?) |
| 8 (View) | Externer Zugriff | /BIC/A<technischer Name> 8 | Neu in SAP BW/4HANA 2.0 |
Modellierungsvarianten
Verwendung ist abhängig von den jeweiligen Anforderungen an das DWH, so können an einer Stelle im Datenfluss durchaus unterschiedliche Varianten zur Anwendung kommen.
Redundante Vorhaltung von Daten, kostet Speicherplatz und Performance. Eine Redundanz ist nicht immer erforderlich. Abhängig von der Funktion im Datenfluss und der Verwendung der Daten.
Verwendung:
- Datamarts mit Reporting
Eigenschaften:
- Aktivierung der Daten benötigt Zeit
- Es werden Strukturen aufgebaut, die das aDSO reportingfähig machen (Redundanz)
- Einzelne Beladungen (Requests) können nicht geziehlt aus dem Datenbestand des aDSO herausgenommen werden
Verwendung:
- Datamarts mit Reporting
- Deltabeladung
Eigenschaften:
- Aktivierung der Daten benötigt Zeit, die Daten werden zunächst in den ChangeLog geschrieben, von dort wird der aktive Datenbestand aufgebaut.
- Zusätzliche Redundanz für das ChangeLog
- Einzelne Beladungen (Requests) können gezielt aus dem Datenbestand des aDSO herausgenommen werden
Verwendung:
- Datenfluss wie bei einem Standard aDSO mit ChangeLog, jedoch werden die Requests nicht aggregiert. Chronologisch eingefügte Datensätze überschreiben den bestehenden Wert.
Eigenschaften:
- Snapshot aDSO werden verwendet, wenn die Quelle nicht in der Lage ist, historische Werte zu liefern.
- Spezialfall
Bei einem Staging aDSO wird nur die Inbound Tabelle vom DTP beschrieben. Eine Aktivierung der Daten ist nicht notwendig.
- Staging ohne Reporting
- Open Operational Data Store
- EDW Propagation Layer
- Corporate Memory
Verwendung:
- Staging mit Reporting
Verwendung:
- Corporate Memory
Frage: HANA kompremiert alle Daten, wozu ist noch eine Kompression eines Objektes notwendig?
SnapShot
Der SnapShot ist eine Variante des aDSO, bei dem die Requests von Vollständigen Beladungen (FULL Load) nachvollziehbar gespeichert werden und die Daten zur Ladezeit nicht mehr in der Quelle reproduzierbar sind.
Sinnvoll um bei Open ODS – Views Persistenz herzustellen,
Semantische Partionierung
aDSO können partioniert werden.
aDSO können maximal 2 Mrd. Datensätze aufnehmen, müssen mehr Datensätze gespeichert werden, muss das aDSO partioniert werden.
Aktivierung der Daten
Abhängig von der Modellierungsvariante müssen die geladenen Daten aktiviert werden. Hierbei werden die sich in der Eingangstabelle befindlichen Daten in die Tabellen der ChangeRequest und die aktiven Daten übertragen.
Data-Tiering
Der Speicherplatz in einem HANA-System ist durch die Größe des Arbeitsspeichers begrenzt. Es muss immer ausreichend Speicher für dynamische Vorgänge (Abfragen) bereitgehalten werden.
Nicht alle Daten müssen permanent für einen Abfrageprozess im Arbeitspeicher gehalten werden. Diese können auf einen schnellen externen Datenspeicher ausgelagert werden. Im Bedarfsfall werden diese Daten automatisch zurück in den Arbeitsspeicher geladen. Dieses erhöht die Latenz der Abfragen etwas.
SAP hat ein System mit drei Wärmezohnen
| Rot | Heiße Daten | Daten, die permanent abgefragt werden |
| Gelb | Warme Daten | Daten, die regelmäßig, aber nicht dauernd abgefragt werden |
| Grün | Kalte Daten | Daten die nur selten in Abgefragt werden |
Administration
Anlage
Kontextmenu einer InfoArea: Neu – DataStore – Objekt (advanced)
Notwendige Angaben:
- BW – Projekt
- Paket
- InfoArea
- Technischer Name
- Beschreibung (Text)
Als Vorlage für die Einrichtung eines aDSO können dienen:
- DataSources
- InfoProvider
- InfoObjects
- InfoSources