HTAP (Hybrid Transactional/Analytical Processing) ist eine Datenbank-Architektur, die zwei Aufgaben in einem System zusammenführt: das Verarbeiten laufender Transaktionen wie Bestellungen, Kontobuchungen oder Bestandsbuchungen (klassisch OLTP) und das Ausführen analytischer Auswertungen wie Reports, Dashboards oder Aggregate über große Datenmengen (klassisch OLAP). Der übliche Umweg über ein separates Data Warehouse mit nächtlicher Datenkopie entfällt. Der Begriff wurde 2014 vom Analystenhaus Gartner geprägt.
Was ist HTAP?
Die zentrale Idee einer HTAP-Datenbank ist die Aufhebung der jahrzehntelang etablierten Trennung zwischen operativem und analytischem System. In klassischen Architekturen läuft die operative Datenbank auf einem zeilenorientierten Speicher (Row Store, jede Zeile liegt am Stück auf der Festplatte, gut für viele kleine Schreib- und Einzelzugriffe wie „hole diese eine Bestellung"). Das analytische System nutzt dagegen einen spaltenorientierten Speicher (Column Store, jede Spalte liegt am Stück, gut für aggregierende Abfragen wie „Summe aller Umsätze pro Region"). Zwischen beiden Systemen liegt eine ETL-Strecke (regelmäßiger Ladejob, der Daten aus dem operativen System ins Analyse-System schiebt) oder eine CDC-Strecke (Change Data Capture, überträgt nur die geänderten Datensätze fortlaufend).
HTAP-Systeme versuchen, beide Workloads in einer Engine zu lösen. Technisch geschieht das meist durch zwei parallele Repräsentationen derselben Daten: ein Memory-resident Row Store für transaktionale Operationen und eine spaltenorientierte Sekundärsicht, die im Hintergrund aktuell gehalten wird. Der Gartner-Begriff von 2014 (Pezzini, Edjlali) sollte ursprünglich Anwendungen ermöglichen, in denen Reporting und operative Steuerung auf derselben Datenbasis arbeiten, ohne dass zwischen Schreibvorgang und Analyse-Sicht erst ein nächtlicher Ladejob laufen muss.
Verbreitete Vertreter sind SingleStore (vormals MemSQL), TiDB (PingCAP), SAP HANA und Oracle Database In-Memory. Diese Systeme bedienen mittlere Mischlasten gut, in denen ein einzelnes Datenmodell sowohl Transaktionen als auch Echtzeit-Dashboards trägt. Bei hochskalierten Profilen mit sehr vielen parallelen Schreibzugriffen oder sehr großen analytischen Scans zeigt sich allerdings ein Engine-Physik-Kompromiss: Zeilen- und Spaltenformat haben gegenläufige Optimierungsziele, und eine Engine kann beides nicht gleichzeitig auf dem Niveau spezialisierter Systeme bedienen. Reynold Xin (Databricks) hat das auf dem Data+AI Summit knapp gefasst: eine Engine sei „zwangsläufig kompromissbehaftet".
Abgrenzung gegen LTAP und Zero-ETL
HTAP, LTAP und Zero-ETL adressieren dieselbe Fragestellung (wie lassen sich operative und analytische Workloads ohne klassische ETL-Strecke zusammenführen), setzen aber an unterschiedlichen Schichten an.
| Ansatz | Engines | Speicher | Datenkopien |
|---|---|---|---|
| HTAP | eine Engine für OLTP und OLAP | gemeinsamer Store, oft hybrides Layout | konzeptionell keine |
| Zero-ETL | zwei getrennte Engines | je Engine eigener Store | bleiben bestehen, Pipeline ist nur verborgen |
| LTAP | zwei spezialisierte Engines | gemeinsamer Objektspeicher | konzeptionell keine, gemeinsamer Store noch angekündigt |
HTAP löst das Kopier-Problem in einer Engine und nimmt dafür den Trade-off zwischen Schreib- und Lese-Profil in Kauf. [LTAP](/insights/glossar/ltap/) trennt die Engines wieder und vereint dafür die Speicher-Schicht: Lakebase als zeilenorientierte Engine und das Lakehouse als spaltenorientierte Engine arbeiten auf demselben Objektspeicher. [Zero-ETL](/insights/glossar/zero-etl/) lässt sowohl Engines als auch Datenkopien getrennt und automatisiert nur die Pipeline dazwischen.
Beispiel: SingleStore in einer Logistik-Plattform
Eine Logistik-Plattform verwaltet Bestellungen, Bestände und Lieferaufträge. Auf denselben Tabellen laufen zwei Lastprofile parallel: operative Transaktionen (eine Bestellung anlegen, einen Bestandseintrag aktualisieren, eine Lieferung quittieren) und Echtzeit-Dashboards (Bestellvolumen pro Region in den letzten 15 Minuten, Lagerumschlag pro Artikelgruppe, Lieferquote). In einer klassischen Architektur würde der operative Datenbestand nachts oder per CDC ins Data Warehouse übertragen; das Dashboard sähe damit Daten mit Verzögerung.
Mit SingleStore als HTAP-Datenbank entfällt diese Trennung. Die operative Anwendung schreibt direkt in die Datenbank, und die Dashboards lesen ihre Aggregate auf derselben Engine. Bestell- und Bestandsdaten sind in zeilenorientierter Form für Punktzugriffe verfügbar; eine spaltenorientierte Sekundärsicht beschleunigt die aggregierenden Abfragen der Dashboards. Solange das Lastprofil im mittleren Bereich bleibt (einige zehntausend Transaktionen pro Sekunde und Reporting-Last, die mit der Engine skaliert), funktioniert das gut. Erst bei sehr großen Analyse-Scans oder bei Streaming-OLTP an der oberen Skalierungs-Grenze zeigen sich die Trade-offs des Single-Engine-Ansatzes.
HTAP (Hybrid Transactional/Analytical Processing) im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.