dbt mit SAP-Daten
Stand 2026-09-03
dbt ist überall dort zur Standard-Transformationsschicht geworden, wo Datasphere oder BDC die SAP-Extraktion und -Governance übernimmt, die Modellierung aber in Snowflake, BigQuery oder Databricks läuft. Die entscheidende Frage in Woche eins ist, wo die Grenze verläuft: Währungsrundung, Mengeneinheiten-Umrechnung und Berechtigungsprüfungen bleiben in Datasphere/HANA; quellenübergreifende Joins, aufwendige Aggregation und alles, was ein Nicht-SAP-Analytics-Engineer warten muss, wandern zu dbt. Werden die SAP-spezifischen Fallstricke falsch gehandhabt — MANDT implizit belassen, Fiskalperioden mit Datumsabschneidung gelesen, Kopf/Position auf falscher Granularität verbunden —, ist der Data Mart lautlos fehlerhaft, lange bevor es jemand bemerkt. Engineers, die beide Welten verbinden können, rechnen in EMEA 750-950 €/Tag ab, gegenüber 550-650 €/Tag für reine SAP-Profile.
Was Sie lernen
- dbt-Projekte aufbauen, die aus SAP stammende Daten innerhalb eines Cloud-Data-Warehouse oder Databricks-Lakehouse beziehen, bereinigen und modellieren
- dbt-Modellschichten (Staging, Intermediate, Mart) entwerfen, die SAPs Kopf-/Positionsstruktur und Geschäftsjahresperioden-Logik respektieren
- dbt-Tests schreiben und Dokumentation erzeugen, die den Datenqualitätserwartungen eines SAP-Analytics-Konsumenten genügen
- Bewerten, wann dbt-Transformationen versus Datasphere-native Data Flows einzusetzen sind, und beide in einer hybriden Architektur kombinieren
Warum dbt Einzug in den SAP-Analytics-Stack gehalten hat
Die meiste Zeit des letzten Jahrzehnts lebten SAP-Analytics-Transformationen innerhalb von SAP selbst — ABAP-Transformationen in BW, Calculation Views in HANA, Data Flows in Datasphere. Das funktionierte gut, solange die Daten das SAP-Ökosystem nie verließen. Die Welt hat sich verschoben: Unternehmen betreiben SAP heute als eine Quelle unter vielen, landen alles in einem Cloud-Data-Warehouse oder einem Databricks-Lakehouse und erwarten eine einzige Transformationsschicht über alle Quellen hinweg. dbt (data build tool) hat diese Lücke gefüllt und wurde 2024-2025 zur De-facto-Standard-Transformationsschicht genau in jenen Architekturen, in denen Datasphere oder BDC als Extraktions- und Governance-Ebene fungiert, während die eigentliche Modellierung in Snowflake, BigQuery, Redshift oder Databricks stattfindet.
Für einen SAP-Analytics-Engineer entsteht dadurch eine konkrete Kompetenzlücke: Sie verstehen BW-InfoObjects, Datasphere-Entities und HANA-Calculation-Views, müssen aber nun wissen, wie sich die Modellschicht-Philosophie von dbt auf SAPs Datenstrukturen überträgt, wo die Reibungspunkte liegen und welche Transformationen innerhalb von SAP bleiben sollten gegenüber jenen, die zu dbt wandern sollten.
Voraussetzungen
- Fortgeschrittene praktische Erfahrung in SAP-Analytics-Projekten
- Zuerst die Kernkonzepte wiederholen: C087, C083, C047
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: Ein europäischer Industriehersteller, der S/4HANA betreibt, repliziert GL- und Vertriebsdaten über Datasphere nach Databricks.
- Das Anti-Pattern erkennen und vermeiden: Kopf- und Positionstabellen im Staging joinen — erzeugt einen Fan-out, sobald jemand auf Kopfebene aggregiert.
- Die Kernentscheidung des Moduls anwenden: Wo die Grenze zwischen dbt und Datasphere verläuft — wählen Sie: Währungsumrechnung, Mengeneinheiten-Umrechnung und Berechtigungsprüfungen in Datasphere/HANA belassen; quellenübergreifende Joins verschieben.
- Die Beherrschung mit dem KPI verfolgen: dbt-Test-Erfolgsquote bei Staging-Modellen.
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.