Semantic Layer: Definition, Bausteine und Abgrenzung

Ein Semantic Layer ist eine Bedeutungs-Schicht zwischen der Datenbank (den Tabellen im Data Warehouse oder Lakehouse) und den auswertenden Werkzeugen. Er legt fest, wie Kennzahlen (zum Beispiel Umsatz), Dimensionen (zum Beispiel Kunde, Produkt, Zeit) und deren Beziehungen berechnet werden. Diese Definitionen werden zentral gepflegt und von allen Anwendungen (Reporting-Werkzeugen wie Power BI, Analyse-Notebooks, KI-Assistenten) einheitlich verwendet.

Was ist ein Semantic Layer?

Ein Semantic Layer ist der zentrale Ort, an dem Kennzahlen (Umsatz, Deckungsbeitrag, Kündigungsquote), Dimensionen (Kunde, Produkt, Zeit) und deren Beziehungen definiert werden. Die Definition wird einmal geschrieben und dann von allen abfragenden Werkzeugen identisch verwendet, egal ob Reporting-Werkzeug wie Power BI, Analyse-Notebook oder KI-Assistent. Ohne diese Schicht definieren Teams dieselbe Kennzahl typischerweise mehrfach mit abweichender Logik, etwa Umsatz brutto gegen netto oder wiederkehrender Jahresumsatz (ARR, Annual Recurring Revenue) mit gegen ohne Rabatt.

Historisch stammt die Idee aus dem klassischen BI-Zeitalter mit BusinessObjects Universe, MicroStrategy Semantic Layer und den SAP BW InfoCubes. Die aktuelle Generation ab etwa 2019 firmiert als headless Metrics Layer und ist bewusst vom BI-Tool entkoppelt: dbt Semantic Layer mit MetricFlow, Cube.dev, AtScale und Databricks Unity Catalog Metric Views. Der Grund für die Entkopplung liegt in der wachsenden Zahl an Konsumenten: Neben BI-Tools ziehen Notebooks, Reverse-ETL, Wissensassistenten und Text-to-SQL-Werkzeuge dieselben Kennzahlen und brauchen eine gemeinsame Definitionsquelle.

Typische Bausteine sind ein Metadaten-Modell (welche Tabellen und Views hängen zusammen), Kennzahlen-Definitionen als SQL-Ausdrücke mit Aggregations- und Filter-Semantik, Dimensions- und Hierarchie-Definitionen, eine Access-Control-Bindung, ein Query-Compiler (übersetzt eine Business-Frage in physisches SQL gegen Warehouse oder Lakehouse) und ein Caching-Layer für Wiederholungs-Queries. Zusammen bilden diese Bausteine eine wiederverwendbare, versionierte Bedeutungs-Schicht auf einem bereits modellierten Datenbestand.

Abgrenzung zu Data Warehouse, BI-Tool, Data Catalog und Data Modeling

Ein Semantic Layer wird häufig mit benachbarten Konzepten vermischt, die entweder eine andere Schicht oder eine andere Aufgabe bezeichnen.

Begriff	Achse	Kernunterschied
Data Warehouse	Schicht	Das Warehouse ist die Speicher- und Rechen-Schicht darunter mit den physischen Fakten- und Dimensionstabellen. Der Semantic Layer beschreibt, wie diese Tabellen zu Geschäftsbegriffen kombiniert werden, und hat ohne Warehouse oder Lakehouse keine Datenbasis.
BI-Tool	Rolle	Power BI, Tableau oder Superset sind Konsumenten, die den Semantic Layer auslesen und Dashboards rendern. Historisch fielen Semantik-Definition und Visualisierung im BI-Tool zusammen; moderne Architekturen trennen die beiden Rollen und definieren Kennzahlen zentral, nicht pro Report.
Data Catalog	Aufgabe	Der Katalog inventarisiert Datenassets und macht sie auffindbar (Metadaten, Ownership, Klassifikation, Lineage). Der Semantic Layer definiert die rechenbare Bedeutung darauf. Katalog beantwortet „Welche Daten gibt es?", Semantic Layer beantwortet „Wie werden sie zu Kennzahlen aggregiert?".
Data Modeling	Ebene	Data Modeling bezeichnet die physische oder logische Modellierung auf Tabellenebene (3NF, Star-Schema, Data Vault, One Big Table). Der Semantic Layer arbeitet auf einem bereits modellierten Datenbestand und ergänzt die Business-Sicht, ersetzt aber weder Star-Schema noch Wide-Tables.
Business Glossary	Ausführbarkeit	Ein Business Glossary ist ein rein fachliches Vokabular ohne ausführbare Logik: Es sagt, was „aktiver Kunde" bedeutet. Der Semantic Layer setzt diese Definition in ausführbares SQL um und liefert konkrete Zahlen.

Die zentrale Trennlinie verläuft zwischen Katalog-Schicht und Semantic Layer: Der Katalog inventarisiert und findet, der Semantic Layer berechnet und aggregiert. Beide Schichten liegen heute häufig direkt aneinander (Unity Catalog Metric Views sind ein Beispiel), sind aber inhaltlich getrennt.

Beispiel: ARR-Kennzahl über mehrere Konsumenten

Ein B2B-Softwareanbieter definiert die Kennzahl ARR (Annual Recurring Revenue) einmal im Semantic Layer als Summe der aktiven Abonnement-Verträge mit annualisiertem Betrag, exklusive Rabatte und Setup-Fees. Die Definition liegt versioniert in dbt Semantic Layer oder als Databricks Metric View im Unity Catalog. Power BI konsumiert die Kennzahl für das Executive Dashboard, das Notebook des Data-Science-Teams zieht dieselbe Zahl für die Churn-Prognose, der LLM-basierte Text-to-SQL-Assistent im Vertrieb antwortet mit demselben Wert.

Ohne Semantic Layer entstehen typischerweise drei abweichende Zahlen. Jeder Konsument kopiert die Definition, passt sie leicht an oder interpretiert einen Rand-Fall anders, etwa Downgrades im laufenden Monat oder gestundete Rechnungen. Die Diskussion über die richtige Zahl ersetzt dann die Diskussion über die Geschäftsentwicklung. Der Semantic Layer verhindert diese Fragmentierung, indem er eine einzige, versionierte Definitionsquelle bereitstellt.