Data-Aging in S4/HANA

Posted on by Enno Wulff

Related Post

Daten mit einem Verfallsdatum sind keine neue Erfindung. Seit Google und Co. alles speichern, was jemals irgendwo auf einem Webserver verfügbar war, ist der Wunsch da, Daten nach einer bestimmten Zeit automatisch wieder zu löschen. Was im World-Wide-Web eher persönliche Gründe hat, hat bei HANA einen sehr praktischen und handfesten Hintergrund: Speicherplatz.

Datenbankkonzept HANA

Der große Geschwindigkeitsdurchbruch gelingt HANA durch die InMemory-Technik bei der alle notwendigen Daten im Hauptspeicher verwaltet werden. Für die Verarbeitung im Hauptspeicher werden die Spalten von der Festplatte komplett in den Hauptspeicher geladen. Es ist nämlich ein Irrglaube, dass HANA stets und ständig alle Daten im Hauptspeicher vorhält. Die Datenspeicherung erfolgt auch weiterhin auf der Festplatte. Um so wichtiger ist es bei einer HANA-Datenbank, dass nur die Felder selektiert werden, die auch wirklich für die Verarbeitung von Bedeutung sind.

Hauptspeicher

Auch bei großen Datenmengen hat HANA kaum Probleme, diese zu verarbeiten. Aber mit wachsenden Datenbeständen wird auch eine HANA-Datenbank an ihre Grenzen kommen. Da bei der Verarbeitung die komplette Spalte einer Tabelle geladen wird, kann man sich leicht vorstellen, dass auch HANA einmal Probleme bekommen wird, alle Daten vorzuhalten.

Wer eine HANA-Datenbank einsetzt oder einsetzen möchte, muss sich mittelfristig mit dem Thema Data-Aging auseinander setzen.

Datenalterung

Um diesem Trend entgegen zu wirken, gibt es das Konzept der Datenalterung. Die Daten werden hierbei in Partitionen verteilt, die nicht standardmäßig selektiert werden. Es gibt dann für eine Datenbanktabelle mehrere Partitionen. Eine davon enthält nur die aktuellen Daten. Bei einem SELECT werden nur die Daten aus dieser Partition gelesen. Alle anderen Daten sind für den Anwender – und auch für den Entwickler! – unsichtbar.

Data-Aging-Objekte

Für die Datenalterung werden zusammengehörige Tabellen unter einem Data-Aging-Object zusammengefasst. Unter diesem DA-Objekt werden alle notwendigen Einstellungen verwaltet. Für dieses Objekt wird das Analyseprogramm gestartet um den Alterungsprozess anzustoßen.

Datentemperatur

Die aktuellen Daten sind heiß. Daten, die normalerweise nicht mehr benötigt werden, sind kalt. Auch wenn sich der Begriff Temperatur eingebürgert hat, gibt es keine lauwarmen Daten oder  Datensätze mit einer Temperatur von 12° Celsius. Die Temperatur wird in Tagen gemessen.

Technik

Alle Tabellen, die gealtert werden sollen, müssen ein Feld _DATAAGING besitzen. Ist dieses Feld leer, so gehört der Datensatz zum heißen, also aktuellen, Datenbestand. Die Analyseprogramme setzen für die Datensätze, die nicht mehr aktuell sind, das entsprechende Datum.

Die Datenbanktabelle selbst besteht aus verschiedenen Partitionen. Wie diese Partitionen aufgeteilt werden sollen, kann je Data-Aging-Objekt definiert werden. Sinnvoll sind zum Beispiel Zwei-Jahres-Partitionen. Das bedeutet, dass Daten innerhalb dieses Zeitraums in diese Partition verlegt werden. Bei der Definition der Partitionszeiträume werden alle Partitionen bereits angelegt. Es bedeutet jedoch nicht, dass die Daten auch schon darin laden. Wenn für ein Objekt definiert wird, dass es nach 5 Jahren alt ist, dann landet es auch erst nach 5 Jahren in der entsprechenden Partition.

Archivierung

Welche Daten nicht mehr benötigt werden, wird durch eine Funktionalität abgebildet, die auch bei der Archivierung verwendet wird. Da ein Datensatz für sich nicht einfach als alt (oder kalt) definiert werden kann, sondern nur im Kontext, müssen bestimmte Logiken dafür sorgen, dass die Daten richtig interpretiert werden.

Es gibt Daten, die gar nicht altern. Offen Posten zum Beispiel sind immer aktuell. Bei anderen Datenobjekten muss definiert werden, anhand welchen Datums das Objekt als alt klassifiziert werden kann und welche abhängigen Datensätze dazu gehören.

Der Vorteil hierbei ist, dass die grundsätzlichen Logiken durch die Archivierungsprogramme bereits vorhanden sind. Der Nachteil ist, dass es nach wie vor Beziehungen zwischen Datenobjekten gibt, die sehr schwer zu fassen sind. Der komplette Belegfluss eines Dokumentes muss dafür analysiert und bewertet werden.

Konsequenzen für die Anwender

Der Anwender soll von dem Alterungsprozess möglichst nichts mitbekommen. Er soll seine Transaktionen wie gewohnt aufrufen und damit arbeiten. Nur sieht er eben nicht mehr die Daten, die von einem Analyseprogramm als alt eingestuft wurden. In der Praxis wird sich zeigen, wie gut das Data-Aging funktioniert bzw. wie zufrieden der Anwender damit ist. Wenn es gut läuft, sieht der Anwender weniger Daten, was in der Regel gut ist, sofern alle relevanten Daten auf dem Bildschirm erscheinen.

Konsequenzen für die Entwicklung

Im ersten Moment hört es sich etwas strange an, dass man als Entwickler keinen vollen Zugriff mehr auf die Daten in der Datenbank hat. Ich habe im Hands-On-Workshop ein mulmiges Gefühl gehabt, als nach dem Alterungsprozess die Daten aus der SE16n einfach weg waren. In der SE16h gibt es unter S4/HANA einen neuen Menüpunkt in dem man die Temperatur (also das die Anzahl der Tage) einstellen kann, mit der die Daten gelesen werden sollen.

In der Programmierung hat man die Möglichkeit zu einem Data-Aging-Objekt die Selektion zu beeinflussen. Vor dem Select-Befehl muss das DA-Objekt angesprochen werden und das gewünschte Alter definiert werden.

Die letzten Jahre ist der Umgang mit der Datenbank leichter geworden. Joins funktionieren besser und es ist über ein Jahrzehnt her, dass ich einen Oracle-Hint verwenden musste. Die Performance ist insgesamt besser geworden; SELECT INTO CORRESPONDING FIELDS ist nur unwesentlich langsamer als der direkte Select in eine Tabelle.

Zuerst dachte ich, dass nun nach diesen Vereinfachungen wieder mehr Arbeit auf den Entwickler zukommt. Für den Großteil der Entwickler wird sich jedoch nichts ändern. Der Zugriff auf die Datenbank erfolgt weiterhin über die üblichen Open-SQL-Befehle.

Es kommt nun lediglich ein neues, sehr spezielles Aufgabengebiet hinzu.

Eine sehr gute und detaillierte Übersicht zeigt Bartosz Jarkowki in seinem SAP-Blog How To Perform Data Aging in S4/HANA. Weitere technische Details kannst du in dem Blogbeitrag von Jens Gleichmann nachlesen: Technical Details About Data Aging.

Enno Wulff
Letzte Artikel von Enno Wulff (Alle anzeigen)