Multi-Temperature Data Management

Multi-Temperature Data Management ist ein Ordnungsprinzip, das Daten nach ihrer Nutzung in Temperatur-Klassen (Hot, Warm, Cold, teils Remote) einteilt: Häufig gebrauchte Daten liegen auf schnellem, teurem Speicher, selten gebrauchte auf langsamem, günstigem Speicher. Für jede Klasse legt eine Regel (Policy) fest, wo die Daten liegen und wie darauf zugegriffen wird. Ziel ist, Antwortzeit (wie schnell eine Abfrage antwortet) und Speicherkosten getrennt zu steuern.

Was ist Multi-Temperature Data Management?

Multi-Temperature Data Management ist ein Ordnungsprinzip aus dem Data Warehousing (zentrale Datensammlung für Auswertungen). Hintergrund: In den meisten Datenbeständen wird ein kleiner Teil der Daten sehr oft abgefragt, während ältere oder selten genutzte Daten deutlich günstiger gespeichert werden können. SAP hat den Begriff mit SAP BW und später SAP BW/4HANA (deutschen Analyse-Plattformen) geprägt und ihn in SAP Datasphere und in der [SAP Business Data Cloud](/insights/sap/business-data-cloud/) als Ordnungsmerkmal übernommen.

Die kanonischen Temperatur-Klassen sind Hot, Warm, Cold und optional Remote. Hot bezeichnet Datensätze mit hoher Zugriffsfrequenz und niedriger Latenz-Toleranz; sie liegen im spaltenorientierten In-Memory-Bereich von SAP HANA Cloud. Warm sind Daten mit reduzierter Frequenz und moderater Latenz-Toleranz; die Umsetzung erfolgt über Buffer-Cache-basierte Warm-Stores wie die Native Storage Extension. Cold sind ältere oder rein archivarische Daten auf Objektspeicher wie [HANA Data Lake Files](/insights/glossar/hana-data-lake-files/), Amazon S3 oder Azure Data Lake Storage. Remote bezeichnet den föderierten Zugriff auf Daten in einer Fremdplattform ohne Kopie.

Multi-Temperature Data Management ist ein Steuerungskonzept, kein einzelnes Feature. Es kombiniert Policies (Alter, Nutzung, fachliche Regel), Partitionierung (Zeit, Fachbereich, Business-Datum), Storage-Zuordnung (Column Store, Warm-Store, Data Lake) und Zugriffspfad. Die Umsetzung unterscheidet sich pro Plattform: SAP BW/4HANA nutzt Data Tiering Optimization mit Hot-, Warm- und Cold-Stores; SAP Datasphere kennt lokale Tabellen im HANA-Cloud-Store, lokale Tabellen mit Native Storage Extension und Remote Tables gegen den HANA Data Lake. Der Begriff existiert, weil sich Storage-Kosten und Latenz-Anforderungen in modernen Datenplattformen entkoppelt haben und ein gemeinsames Vokabular für die Design-Entscheidung zwischen Dashboard-SLA, Ad-hoc-Analyse und langfristiger Historie mit regulatorischer Aufbewahrung fehlte.

Abgrenzung zu Data Tiering, Data Aging, Archivierung und Objekt-Lifecycle

Multi-Temperature Data Management wird häufig mit den technischen Bausteinen verwechselt, die eine solche Architektur umsetzen. Die Unterschiede liegen in der Steuerungsebene und im Grad der fachlichen Semantik.

Beispiel: dreistufige Multi-Temperature-Policy in SAP Datasphere

Ein Datasphere-Space verwaltet Vertriebstransaktionen über zehn Geschäftsjahre. Die Multi-Temperature-Policy weist die letzten zwei Jahre als Hot aus (lokale Tabelle im spaltenorientierten Hauptspeicher von SAP HANA Cloud). Die Jahre drei bis fünf sind Warm (lokale Tabelle mit Native Storage Extension, seitenweise nachladbar über Buffer Cache). Die restlichen Jahre sind Cold (Remote Table gegen HANA Data Lake Files auf dem Objektspeicher der Business Data Cloud). Ein operatives Dashboard über das laufende Geschäftsjahr trifft nur den Hot-Layer und antwortet in Millisekunden. Eine Zehn-Jahres-Analyse aktiviert alle drei Ebenen und akzeptiert längere Antwortzeiten. Die Storage-Kosten sinken deutlich, weil der Grossteil der Datenmenge auf Objektspeicher liegt.

Architektonisch sitzt Multi-Temperature Data Management als Design-Ebene über den konkreten Storage-Techniken. Sie bestimmt, welche Daten in welche Klasse wandern, wann Promote/Demote stattfindet und wie transparent der Zugriff für die Modellierung bleibt. Ein analoges Muster findet sich in Databricks-Lakehouse-Architekturen, in denen aktuelle Delta-Tabellen durch Photon und Disk-Cache warm gehalten werden und historische Partitionen über eine Lifecycle-Policy des Objektspeichers in eine günstigere Storage-Klasse wandern.