View Persistency

View Persistency in SAP Datasphere speichert das Ergebnis einer View (einer gespeicherten Datenbank-Abfrage) dauerhaft als Tabelle ab, statt es bei jedem Aufruf neu zu berechnen. Anfragen lesen dann aus dieser Kopie und antworten schneller; die Kopie wird nach einem festgelegten Zeitplan, über eine Task Chain (eine Kette geplanter Aufgaben) oder per Hand aktualisiert.

Was ist View Persistency?

Eine View in [SAP Datasphere](/insights/glossar/sap-datasphere/) ist zunächst nur eine gespeicherte Abfrage, also eine Rechenvorschrift ohne eigene Datenkopie. Sie liest ihre Daten aus [Local Tables](/insights/glossar/local-tables/) (lokal gespeicherten Tabellen), [Remote Tables](/insights/glossar/remote-tables/) (Tabellen, die über eine Verbindung auf ein anderes System zugreifen) oder aus weiteren Views. Bei jedem Aufruf berechnet die SAP-HANA-Cloud-Datenbank das Ergebnis neu. Wenn die View mehrere Tabellen zusammenführt, Kennzahlen zusammenrechnet oder über eine Fernverbindung Daten aus einem entfernten System zieht, wird das teuer: Die Antwortzeiten steigen, die Last auf den Quellsystemen wächst, und Auswertungen für Berichte oder KI-Anwendungen (Artificial Intelligence, deutsch: Künstliche Intelligenz) werden zäh.

View Persistency ist der explizite Schalter, um dieses Ergebnis zu materialisieren. Pro View lässt sich im Data Builder unter den View-Properties „Data Persistence" aktivieren. Die zugrundeliegende View bleibt logisch definiert; nur ihr Ergebnis wird bei jedem Refresh in eine interne Tabelle im [HANA-Cloud](/insights/glossar/hana-cloud/)-Speicher des Spaces geschrieben. Die Storage-Klasse dieser Tabelle ist wählbar: In-Memory Column Store für den Hot-Layer, Native Storage Extension für den Warm-Layer. Anfragen gegen die persistierte View lesen die materialisierte Kopie; die ursprüngliche Query wird nur noch beim Refresh ausgeführt.

Der Refresh läuft über einen konfigurierbaren Zeitplan (stündlich, täglich, cron-ähnlich), über einen manuellen Trigger im Data Integration Monitor oder als Task in einer Task Chain. Ein automatisches Delta-Handling gibt es nicht: Jeder Refresh berechnet das View-Ergebnis komplett neu und ersetzt die vorhandene persistierte Tabelle. Der Datenstand entspricht damit dem letzten Refresh-Zeitpunkt und liegt hinter dem aktuellen Stand der Quelle zurück.

Der Begriff existiert, weil Datasphere bewusst zwischen logischer Modellierung (Views) und physischer Speicherung (Tables) trennt. View Persistency erlaubt es, eine logische Definition ohne Umbau der Modellierung physisch zu machen. In der [Data-Tiering](/insights/glossar/data-tiering/)-Familie ist Persistency der Hebel, um eine teure View in den Hot- oder Warm-Layer zu heben und die Berechnung bei jedem Zugriff einzusparen. Die Gegenrechnung sind zusätzliche HANA-Cloud-Speicherbelegung durch das View-Ergebnis und Data Integration Hours beim Refresh.

Abgrenzung: Materialized View, Cache, Analytic Model, Snapshot, Transformation Flow

Die häufigsten Verwechslungen entstehen an fünf Stellen: gegenüber der klassischen Materialized View aus relationalen Datenbanken, gegenüber Cache-Mechanismen der Datenbank-Engine, gegenüber dem Analytic Model als semantischer Schicht darüber, gegenüber Snapshots als historisierten Zeitständen und gegenüber Transformation Flows als explizit modellierten Pipelines.

Zusätzlich lohnt die Trennung vom [Replication Flow](/insights/glossar/replication-flow/): Der lädt Daten aus einer externen Quelle in eine Local Table (Extract-and-Load, meist Change-Data-Capture-basiert). View Persistency materialisiert das Ergebnis einer bereits im Space vorhandenen View; die Quelle sind Datasphere-Objekte, kein externes Quellsystem. Replication Flow ist Ingest, View Persistency ist Ergebnis-Speicherung.

Beispiel: persistierte Umsatz-Aggregation über eine Remote Table

Ein Datasphere-Space „Sales" liest tagesaktuelle Auftragsdaten über eine Remote Table S4_SD_Orders_Live aus einem produktiven S/4HANA-System und verknüpft sie in einer View V_Orders_Aggregated mit den lokal replizierten Materialstammdaten und einer Kunden-Hierarchie. Die View führt mehrere Joins, eine Aggregation auf Materialgruppen-Ebene und einen Filter auf offene Aufträge durch. Ohne Persistency braucht jede Abfrage einen Föderations-Zugriff auf S/4HANA plus die Aggregation zur Query-Zeit. Ein Dashboard mit zwanzig gleichzeitigen Nutzern belastet die Quelle spürbar und antwortet im Sekundenbereich.

Der Space-Owner aktiviert View Persistency auf V_Orders_Aggregated und plant einen stündlichen Refresh. Das Ergebnis der View liegt fortan als interne Local Table im In-Memory Column Store des Spaces. Dashboard-Abfragen treffen die persistierte Kopie und antworten in Millisekunden; die S/4HANA-Last sinkt auf einen einzigen Zugriff pro Stunde. Der Preis: Der Datenstand ist bis zu eine Stunde alt, der Space belegt zusätzlich HANA-Cloud-Speicher, und der stündliche Refresh erzeugt Data Integration Hours. Die Wahl zwischen häufigem und seltenem Refresh ist damit eine Verrechnung zwischen Aktualitäts-Anforderung, Speicher- und Compute-Kosten sowie Quellsystem-Last, wie sie im [SAP-Datasphere-Pricing-Guide](/insights/sap/sap-datasphere/pricing-guide/) durchgerechnet ist.