OLAP (Online Analytical Processing)

OLAP (Online Analytical Processing) steht für Datenbanksysteme, die viele Datensätze zusammenfassend auslesen. Sie berechnen Kennzahlen wie Umsatz oder Marge über Millionen Zeilen, statt einzelne Datensätze zu speichern und zu ändern. Der Begriff wurde 1993 vom Informatiker E. F. Codd geprägt und grenzt Analyse-Abfragen (das Zusammenfassen vieler Zeilen zu wenigen Kennzahlen) gegen den Gegenpol OLTP (Online Transaction Processing, also das laufende Buchen einzelner Vorgänge wie Bestellungen) ab.

Was ist OLAP?

OLAP beschreibt ein Nutzungsmuster, keine Produktkategorie. Systeme mit einem OLAP-Profil bedienen wenige, aber große Abfragen: Kennzahlen über Millionen oder Milliarden Zeilen zusammenfassen, nach mehreren Merkmalen (Zeit, Region, Produkt) gruppieren, Zeiträume und Hierarchien vergleichen. Das Ergebnis ist typischerweise klein (eine Tabelle mit wenigen Zahlen), die dafür durchlaufene Datenmenge groß. Das Gegenmuster ist OLTP (Online Transaction Processing) mit vielen kleinen Einzelsatz-Vorgängen wie Bestellungen oder Buchungen, die zeilenweise erfasst werden.

Der Begriff geht auf ein White Paper von E. F. Codd (1993) zurück, in dem der Autor zwölf Regeln für analytische Datenbanksysteme formulierte. Nigel Pendse verdichtete diese Regeln später zur Kurzform FASMI (Fast Analysis of Shared Multidimensional Information). Die zentrale mentale Struktur eines OLAP-Systems ist der Datenwürfel (Cube) mit Kennzahlen als Zellinhalten und Dimensionen als Kanten. Auf diesem Cube laufen Slice-and-Dice-Operationen: Roll-up, Drill-down, Slice, Dice, Pivot.

Technisch stützen sich OLAP-Systeme auf drei Bausteine: spaltenorientierter Speicher, Vektor-Ausführung und dimensionale Modellierung. Spaltenorientierter Speicher liest bei einer Aggregation nur die relevanten Spalten. Die Vektor-Engine verarbeitet Werte gebündelt in CPU-Registern statt zeilenweise. Das dimensionale Modell nach Ralph Kimball (Star- oder Snowflake-Schema) legt Fakten- und Dimensions-Tabellen so an, dass Analyse-Abfragen wenige Joins und viele Aggregationen erzeugen.

Historisch wird OLAP in drei Umsetzungsklassen sortiert. MOLAP (Multidimensional OLAP) materialisiert einen physischen Cube mit vorberechneten Aggregaten (Microsoft SSAS Multidimensional, Oracle Essbase, IBM Cognos TM1). ROLAP (Relational OLAP) beantwortet Cube-Abfragen über SQL-Aggregate auf einer relationalen Datenbank mit Star-Schema; heutige Cloud-Warehouses (Snowflake, BigQuery, Redshift) und Lakehouse-Engines (Databricks SQL, Microsoft Fabric) fallen in diese Klasse. HOLAP kombiniert beide Ansätze. Die MOLAP-Cube-Rolle ist heute in semantische Schichten übergegangen (Power BI Semantic Model, Databricks Metric Views, dbt Semantic Layer), die dimensionale Definitionen tragen, ohne einen physischen Cube zu materialisieren.

Abgrenzung zu OLTP, HTAP, LTAP und Data Warehouse

Der OLAP-Begriff wird häufig mit vier verwandten Konzepten vermischt: dem Gegenprofil OLTP, den Architekturmodellen HTAP und LTAP sowie der Architektur-Rolle Data Warehouse.

Die wichtigste Abgrenzung verläuft zwischen OLAP und OLTP. Ein OLTP-System speichert Bestellungen, Bewegungen und Buchungen zeilenorientiert und ist auf hohe Transaktionsraten mit ACID-Garantien optimiert. Ein OLAP-System liest historisierte Kopien dieser Daten spaltenorientiert und beantwortet Kennzahl-Abfragen. Die Trennung in zwei Systeme führt zu einer ETL- oder CDC-Strecke dazwischen, deren Auflösung heute die Architekturmodelle [HTAP](/insights/glossar/htap/) und [LTAP](/insights/glossar/ltap/) angehen.

Die zweite Verwechslung betrifft OLAP und Data Warehouse. Ein Warehouse ist die Architektur-Rolle „zentraler, historisierter Analyse-Bestand"; OLAP das Workload-Profil darauf. Ein modernes [Data Warehouse](/insights/glossar/data-warehouse/) auf Snowflake oder Databricks SQL ist ein ROLAP-System, aber OLAP läuft auch außerhalb eines Warehouse (etwa auf einem Lakehouse ohne Warehouse-Schicht darüber).

Beispiel: OLAP-Workload in einer Handels-Datenplattform

Eine Handels-Datenplattform historisiert Verkaufstransaktionen aus SAP ERP, Kundendaten aus einem CRM und Klickstrom-Ereignisse aus dem Webshop. Der Fakten-Bestand „Verkaufstransaktion" umfasst mehrere Milliarden Zeilen; die Dimensions-Tabellen halten Kunde, Produkt, Zeit und Region mit Slowly-Changing-Historie. Reports fragen aggregierende Kennzahlen ab: Umsatz pro Region und Monat, Marge pro Produktkategorie, Wachstum gegen Vorjahr.

Diese Abfragen tragen ein klassisches OLAP-Profil (große durchlaufene Datenmengen, kleine Ergebnismengen). Die Plattform bedient sie als ROLAP-Workload auf Databricks SQL oder Snowflake. Spaltenorientierter Speicher (Delta Lake, Iceberg oder das native Warehouse-Format) reduziert die zu lesenden Bytes; die Vektor-Engine (Photon, Snowflake-Query-Backend) verarbeitet die Aggregate gebündelt. Ein separater MOLAP-Cube wird kaum noch angelegt; die semantische Definition liegt in [Analytic Models](/insights/glossar/analytic-models/), im Power-BI-Semantic-Model oder in einem Metric Layer. Fachbereichs-Ausschnitte entstehen als Views auf demselben Bestand und tragen die Rolle eines [Data Mart](/insights/glossar/data-mart/).

Bei Sub-Sekunden-Latenz mit hoher Nutzer-Konkurrenz kommen Real-Time-OLAP-Engines wie Apache Druid, Apache Pinot oder ClickHouse ins Bild. Sie teilen dasselbe Workload-Profil und optimieren zusätzlich auf niedrige Query-Latenz.