Drei Engines, eine Wahrheit: Ein semantisches Modell für SAP Datasphere, Databricks und Power BI
- AIReadiness, SAP Business Data Cloud (BDC), SAP Datasphere
- 8 Min Lesezeit
Dr. Andreas Wagner
Drei Engines, eine Wahrheit: Dieses Wiki zeigt, wie SAP Datasphere, Databricks und Power BI dieselbe Kennzahlendefinition teilen, statt sie dreimal neu berechnen zu müssen. Der semantische Anker legt Business-Logik wie Währungsumrechnung und Geschäftsjahresvariante genau einmal an der Quelle fest, so liefert die Kennzahl „Net Revenue“ in jeder Engine denselben Wert.
1. Die Ausgangslage
Eine Organisation, drei Systeme (nämlich zu SAP, Databricks und Power BI), drei unterschiedliche Umsatzzahlen für denselben Monat: In modernen Multi-Cloud-Landschaften liegt das Problem selten am Datenzugriff, sondern an der fehlenden, durchgängigen Semantik. Net Revenue wird in SAP anders berechnet als im Databricks-Notebook und wieder anders im Power-BI-Report, da die Währungs-, Perioden- und Geschäftsjahreslogik jedes Mal neu und isoliert voneinander implementiert wird. Die Folge sind endlose Diskussionen über Zahlen statt über unternehmerische Entscheidungen.
Die Lösung ist kein weiteres BI-Tool, sondern ein durchgehendes semantisches Modell.
Dieses Wiki zeigt:
1. Welche Semantik-Ebene jede der drei Engines überhaupt liefert.
2. Wie SAP Datasphere die fachliche Logik zentral festlegt und wie Databricks sowie Power BI diese Definition erben, statt sie in Transformations-Pipelines nachzubauen.
3. Wie die Datenmaterialisierung und der Metadaten-Austausch technisch im Object Store ineinandergreifen.
4. Wie Power BI je nach Architektur – über Microsoft Fabric (Direct Lake) oder direkt über Databricks (DirectQuery) – angebunden wird.
5. Anhand eines durchgängigen Net-Revenue-Beispiels wird gezeigt, wie die Ebenen konkret zu einem verlässlichen Modell verbunden werden.
2. Business-Logik einmal definieren und überall nutzen
Die Analytic Models der SAP Datasphere enthalten bereits die betriebswirtschaftliche Geschäftslogik, beispielsweise Währungsumrechnung, Geschäftsjahresvariante und Hierarchien. Anstatt diese Logik in externen ETL-Strecken redundant nachzubauen, wird der zugrunde liegende Datenbestand als eigenes (customer-managed) Data Product im Object Store von SAP Datasphere materialisiert und zusammen mit strukturierten Metadaten (ORD und CSN) bereitgestellt. Weil eine Datasphere-View selbst keine Daten enthält, wird ihr Ergebnis dafür zuerst persistiert und in den Object Store geschrieben – auf der SAP-Seite entsteht so mindestens eine zusätzliche Kopie.
Databricks bindet diese Datenprodukte über den SAP BDC Connector for Databricks kopierfrei («zero-copy»(LINK)) ein; die Kennzahlen werden anschliessend bewusst – manuell oder über einen CI/CD-Prozess – als Metric Views im Unity Catalog nachgezogen. Ein automatischer Mechanismus, der ein SAP Analytic Model in einen Metric View überführt, existiert dabei nicht: Das Muster ist eine architektonische Konvention, kein Produkt-Feature. Power BI konsumiert dieselben Tabellen: standardmässig per DirectQuery live gegen Databricks – ohne zwischengeschaltete Ebene – oder, wo eine Microsoft-Fabric-Landschaft vorhanden ist, alternativ über ein Direct-Lake-Semantikmodell, das die Delta-Tabellen aus OneLake importschnell liest, ohne bei jeder Abfrage Databricks-Compute zu wecken. Die Definition bleibt an einer einzigen Quelle verankert und wird von den konsumierenden Engines übernommen.
Der praktische Effekt ist dabei folgender: Net Revenue liefert in jeder Engine denselben Wert, da alle die gleiche Quelle und dieselbe Deklaration referenzieren. Governance und Fachbereich müssen nicht mit über die Herleitung einer Zahl diskutieren, sondern können direkt mit ihr arbeiten.
3. Warum das zählt: Eine Definition, nicht nur Daten
Rund um den semantischen Anker halten sich zwei Missverständnisse, die Datenarchitekten früh ausräumen sollten:
- Metric Views sind nur eine weitere Kopie der Kennzahl.“ Ein Metric View im Unity Catalog wird bewusst so angelegt, dass er die an der Quelle definierte Logik über denselben geteilten Tabellenbestand referenziert, anstatt die Berechnungslogik in ETL-Pipelines erneut zu materialisieren. Diese Referenz entsteht nicht automatisch, sondern wird einmalig eingerichtet und gepflegt. Ändert sich die Kennzahlendefinition an der Quelle, passt sich auch die semantische Schicht an – ein ETL-Duplikat würde das nicht tun.
- „Semantik ist Sache des BI-Tools.“ Wenn die Geschäftslogik erst im Dashboard erstellt wird, muss sie für jeden Report neu aufgebaut werden. Das semantische Layer zieht sie an die Quelle zurück, wo sie genau einmal verbindlich definiert wird.
4. Das Semantic Layer in der Praxis
Eine Kennzahl wird im Zusammenspiel aus Datasphere und Quell-CDS-Views mit SAP-eigener Währungs- und Geschäftsjahreslogik definiert. Von dort wird sie in die beiden anderen Engines übernommen, ohne dass die Logik in Transformationsstrecken neu geschrieben werden muss.
5. Was jede Engine an Semantik liefert
Bevor die Ebenen zusammenwachsen, lohnt es sich, einen Blick darauf zu werfen, welche Semantik jede Engine mitbringt – denn sie sind nicht gleichwertig, sondern arbeiten arbeitsteilig.
- SAP (Datasphere Analytic Model): Liefert die reichste, verbindliche Geschäftssemantik. Hier leben Währungsumrechnung, Geschäftsjahresvarianten, Mengeneinheiten und Dimensionen als fachlich geprüfte Definition, direkt aus dem S/4HANA-Kontext. Diese Ebene ist das System of Record für Geschäftslogik.
- Databricks (Unity Catalog Metric View): Es wird eine analytische Semantik-Ebene über dem Lakehouse bereitgestellt. Ein Metric View definiert Kennzahlen deklarativ und stellt sie BI-, Ad-hoc-SQL- und ML-Workloads einheitlich zur Verfügung, ohne physische Tabellen zu duplizieren.
- Power BI (Visualisierungs- und Konsumschicht): Liefert die Konsum-Semantik für Fachanwender. Ob als Direct Lake in Microsoft Fabric oder als DirectQuery auf Databricks: Power BI visualisiert die Kennzahlen, darf aber keine abweichende betriebswirtschaftliche Berechnungslogik in DAX nachbilden.
6. Warum Spiegeln statt Kopieren? Der Mechanismus im Detail
Der Unterschied zwischen Spiegeln und Kopieren entscheidet über die Verlässlichkeit der Zahl. Allerdings wandert ein SAP-Datasphere-Analytic-Model nicht als dynamisch rechnende Engine in den Object Store (LINK zum Object Store): Im Objektspeicher liegen keine Rechenprozesse, sondern flache Parquet-Dateien. Geteilt wird daher nicht die dynamische Laufzeit-Logik, sondern der materialisierte Datenkörper des Data Products zusammen mit seinen semantischen Metadaten (ORD und CSN).
Sowohl ein Databricks Unity Catalog Metric View als auch ein Power-BI-Measure bauen genau darauf auf: Sie duplizieren keine ETL-Transformationsstrecken, sondern deklarieren die Geschäftslogik (wie Net Revenue) als verbindliche Definition über denselben geteilten Tabellenbestand. Das Metadaten-Protokoll stellt sicher, dass Databricks und Fabric die Primärschlüssel, Dimensionen und Feldbeziehungen aus dem SAP-Ursprung verstehen, anstatt sie in SQL-Skripten erraten zu müssen.
Damit verschiebt sich die Frage „Rechnet Databricks Net Revenue richtig?“ zu „Referenziert Databricks die freigegebenen Data Products und deren semantische Definition?“. Die erste Frage lässt sich nur durch mühsamen Abgleich dreier proprietärer Pipeline-Implementierungen beantworten; die zweite ist eine reine Katalog- und Deklarationsprüfung. Genau diese Trennung – einheitlicher Datenkörper plus Metadaten-Kontrakt statt wildwüchsiger ETL-Logik – macht das semantische Layer robust gegen Drift.
7. Die physische Voraussetzung ist ein Datensatz, den alle drei Engines lesen können
Ein gemeinsames Semantik-Modell setzt voraus, dass alle Engines überhaupt denselben physischen Datenbestand sehen. Andernfalls spiegelt man eine Kennzahlendefinition auf verschiedene Kopien – und die Zahlen laufen trotz abgestimmter Formeln wegen asynchroner Ladezeiten auseinander.
Der gemeinsame Datenkörper besteht aus einem einzigen Satz Parquet-Dateien im offenen Delta-Lake-Format, der bei eigenen Data Products im Object Store von SAP Datasphere liegt (SAP-managed Data Products liegen in den Foundation Services, FOS). Kopierfrei ist der Lesezugriff der Engines; die Materialisierung auf der SAP-Seite bleibt nötig:
Engine | Format | Speicher & Zugriffsweg | Zugriffsmethode & Semantik |
SAP Datasphere (BDC) | Delta Lake / Parquet | Datasphere Object Store (eigene Data Products) bzw. Foundation Services (SAP-managed); Bereitstellung via BDC Connect | Analytic Model & Definition der Data Product Contracts (CSN/ORD) |
Databricks | Delta Lake | Zero-Copy via SAP BDC Connector for Databricks (Delta Sharing, seit 2026 unter dem Namen OpenSharing) im Unity Catalog | Metric View über geteilten Tabellen für BI-, SQL- und ML-Workloads |
Power BI (über Fabric) | Delta Lake | OneLake-Shortcut auf den BDC Object Store oder Databricks | Direct Lake Mode: Liest Delta-Parquet direkt ohne Import oder SQL-Übersetzung |
Power BI (ohne Fabric) | Delta Lake | Databricks SQL Warehouse Endpoint | DirectQuery Mode: Führt SQL-Abfragen live gegen Databricks Unity Catalog aus |
8. Beispiel: Net Revenue einmal definieren und in drei Engines nutzen
Das folgende Beispiel zeigt die Kennzahl «Net Revenue» durchgängig – von der Definition in der SAP-Quelle bis zum identischen Wert in Databricks und Power BI.
Fachliche Definition: Bruttoumsatz abzüglich Erlösschmälerungen, umgerechnet in die Konzernwährung Euro zum Monatsdurchschnittskurs und aggregiert nach der Geschäftsjahresvariante K4 (Kalenderjahr, zwölf Perioden). Gerade diese drei Regeln – Abzugslogik, Währungsumrechnung und Geschäftsjahresvariante – sind es, die sonst in jeder Engine abweichen.
Statt die Logik dreimal in Pipelines zu programmieren, wird sie einmal definiert und anschliessend referenziert:
Schritt 1 – Definieren in SAP Datasphere: Net Revenue wird als Measure in einem Analytic Model angelegt. Die Abzugslogik, die Umrechnung auf Euro zum Monatsdurchschnittskurs und die Geschäftsjahresvariante K4 werden hier modelliert. Die zugrunde liegenden Bestände werden als Data Product freigegeben und als Delta-Tabellen im Object Store von SAP Datasphere bereitgestellt. Liegt die Logik in einer Datasphere-View, wird deren Ergebnis dafür zuerst persistiert und in den Object Store geschrieben.
Schritt 2 – Deklarieren in Databricks: Im Unity Catalog wird bewusst – manuell oder über einen CI/CD-Prozess – ein Metric View erstellt, der direkt auf die freigegebenen Data-Product-Tabellen aufsetzt, statt Net Revenue im Notebook über Hilfstabellen neu zu berechnen. Dieser Schritt geschieht nicht automatisch, sondern wird als Definition angelegt und versioniert gepflegt. Databricks-SQL- und ML-Workloads greifen ab jetzt auf dieselbe semantische Basis zu.
Schritt 3 – Anbindung in Power BI:
- Variante A (direkt auf Databricks, Standardweg): Power BI greift per DirectQuery auf das Databricks-SQL-Warehouse zu und nutzt direkt den im Unity Catalog definierten Metric View – ohne zwischengeschaltete Ebene.
- Variante B (mit Microsoft Fabric, optional): Wo eine Fabric-Landschaft vorhanden ist, werden die Tabellen per OneLake-Shortcut referenziert; Power BI greift im Direct Lake Mode zu und liest das Measure , ohne Daten zu kopieren. In beiden Fällen gilt: Es ist keine manuelle Rekonstruktion der Währungsumrechnung in DAX erforderlich
Schritt 4 – Verifizieren: Prüfen Sie für eine Referenzperiode (etwa den Monatsabschluss), dass alle Engines für Net Revenue denselben EUR-Wert ausweisen. Ein automatisierter Reconciliation-Check hält das Modell dauerhaft frei von Berechnungs-Drift.
9. Vom KPI zur Referenz: Ein Playbook für Datenarchitekten
Ein semantisches Layer entsteht nicht durch ein bestimmtes Werkzeug, sondern durch die organisatorische Disziplin, Definitionen nicht zu duplizieren. Diese drei Leitplanken gehören in jedes Playbook:
- Definitionshoheit an der Quelle festschreiben: Legen Sie verbindlich fest, dass alle kernrelevanten Kennzahlen im Datasphere-Kontext definiert werden. Jede in Databricks oder Fabric nachgebaute Berechnungspipeline stellt eine potenzielle dar.
- Deklarieren statt nachbauen: Binden Sie Kennzahlen in Databricks als Unity Catalog Metric View ein. Nutzen Sie in Power BI Direct Lake oder DirectQuery, um auf diese Sichten zuzugreifen. Widerstehen Sie der Versuchung, Transformationslogik per PySpark oder DAX eigenmächtig neu zu schreiben.
- Abweichungen automatisiert überwachen: Prüfen Sie regelmäßig, ob alle Engines dieselbe Daten- und Metadatenbasis referenzieren. Automatisierte Alerts bei Schema- oder Formelabweichungen verhindern, dass sich Zahlen unbemerkt voneinander entfernen.
Häufige Fallstricke
- Logik im Notebook nachbauen: Der Net Revenue muss „einmalig“ in Databricks per SQL-Transformationsjob umgerechnet werden. Genau so entstehen die divergierenden Silo-Zahlen.
- Hierarchien und Dimensionen vernachlässigen: Es reicht nicht aus, nur die Kennzahlenspalte freizugeben, ohne die zugehörigen Dimensionstabellen und CSN-Metadaten. Ohne konsistente Dimensionen führt jeder Drill-down erneut zu abweichenden Ergebnissen.
- Semantik ohne Ownership: Die Definition ist zwar zentral zu dokumentieren, es wird jedoch niemand für deren Pflege benannt.
und neue Verantwortung.
Die zentrale Definition beseitigt divergierende Kennzahlen, erzeugt aber eine Abhängigkeit, die Architekt:innen aktiv steuern sollten.
| Risiko | Worum es geht | Was Architekt:innen tun sollten |
|---|---|---|
| Quell-Abhängigkeit | Wenn das Datasphere Analytic Model ausfällt oder sich fehlerhaft ändert, sind alle spiegelnden Engines gleichzeitig betroffen. | Modelländerungen versionieren, testen und über strukturierte CI/CD-Prozesse ausrollen. |
| Feature-Lücken | Nicht jede SAP-spezifische Speziallogik lässt sich verlustfrei 1:1 in Metric Views oder DAX abbilden. | Die Abbildbarkeit jeder Kennzahl vor dem Produktivgang testen und Ausnahmen explizit im Data Contract dokumentieren. |
| Metadaten-Latenz | Änderungen an der Quelle werden möglicherweise zeitverzögert in externe Kataloge propagiert. | Propagationszeiten messen und bei Bedarf ein Aktualisierungs-SLA je Engine vereinbaren. |
Machen Sie den AI-Readiness-Check.
Ob Datasphere Analytic Models, Unity Catalog, Metric Views oder Power-BI-Reporting: Konsistente Kennzahlen entstehen aus der richtigen semantischen Architektur.
Begriffe.
Analytic Model
Ein semantisches Modell in SAP Datasphere, das Kennzahlen samt Währungs-, Geschäftsjahres- und Hierarchielogik als verbindliche Definition kapselt.
Metric View
Ein Objekt im Databricks Unity Catalog, das eine Kennzahl deklariert beziehungsweise referenziert und sie analytischen Workloads einheitlich bereitstellt.
Direct Lake
Ein Power-BI-/Fabric-Modus, der Delta-Tabellen aus OneLake direkt abfragt, ohne sie klassisch zu importieren oder zu kopieren.
Geschäftsjahresvariante
Die Regel, nach der ein Geschäftsjahr auf Kalenderperioden abgebildet wird – ein häufiger Grund divergierender Kennzahlen zwischen Engines.
Unity Catalog
Die Governance- und Katalogschicht von Databricks, über die Metric Views, Berechtigungen und Lineage verwaltet werden.
Delta Lake & Delta UniForm
Delta Lake ist ein offenes Tabellenformat mit Transaktionslog über Parquet-Dateien. Delta UniForm erzeugt über einem Bestand zusätzlich Metadaten für verschiedene offene Tabellenformate.
Polaris Catalog & OpenSharing
Polaris Catalog ist ein offener, REST-basierter Katalog für Apache Iceberg. OpenSharing bezeichnet das von Databricks weiterentwickelte offene Sharing-Protokoll; «Delta Sharing» bleibt als Bezeichnung für das zugrunde liegende Protokoll gebräuchlich.
