Python in SAP-Datenpipelines
Stand 2026-09-03
Python betritt SAP-Pipelines durch vier verschiedene Türen — hana-ml-Push-down-Analytics, hdbcli-Skripting, Datasphere's governte Notebooks und BDC-/Databricks-Orchestrierung —, und die erste Entscheidung in jedem Projekt ist, die richtige Tür zu wählen, nicht den Code zu schreiben. Wird das falsch gemacht, geht entweder der Push-down-Vorteil von HANA verloren (Millionen Zeilen werden in Pandas gezogen, die HANA an Ort und Stelle aggregiert hätte), oder die ODP-Delta-Queue wird durch selbstgebaute Checkpoint-Logik in PySpark dupliziert. Berater, die diese Entscheidung treffen, sie mit einer idempotenten MERGE-Pipeline absichern und ihre Abhängigkeitskette gegen SAPs verwaltete Container-Upgrades fixieren können, besetzen die SAP-plus-Python-Schnittstelle, für die der EMEA-Markt 900-1.400 € am Tag zahlt. Dieses Modul ist die Entscheidungskarte für diese Schnittstelle, keine Syntax-Tour.
Was Sie lernen
- hana-ml-Pipelines architektieren, die die Berechnung innerhalb der HANA-Engine belassen — DataFrame-Transformationsketten entwerfen, die `.collect()` bis zum letzten Schritt aufschieben, und PAL-Modellartefakte in HANA statt in lokalem Python-Zustand speichern
- Idempotente, hdbcli-basierte Datenlade-Skripte mit MERGE-Anweisungen und Batch-executemany-Mustern erstellen, mit korrektem Verbindungslebenszyklus-Management für Multi-Tenant-HANA-Cloud-Umgebungen
- Python innerhalb der eingebetteten Notebook-Umgebung von Datasphere für explorative Profilierung, verwaltete ML-Inferenz und operatives Monitoring der Tabellen-Gesundheit anwenden — ohne Daten außerhalb der verwalteten Fabric zu exportieren
- Die angemessene Rolle von Python in der BDC-/Databricks-Orchestrierung von der ABAP-ODP-Extraktionsmechanik unterscheiden und doppelte Verarbeitung verhindern, indem redundante Delta-Logik im PySpark-Transformationscode vermieden wird
Die wirkliche Rolle von Python in SAP-Datenpipelines
Python ist durch drei unterschiedliche Türen in die SAP-Analytics-Landschaft eingetreten, und sie zu vermischen führt zu architektonischen Fehlern. Die erste Tür ist hana-ml, SAPs eigener Python-Client für die HANA Predictive Analysis Library (PAL) und HANA-Machine-Learning-Funktionen — er stellt PAL-Algorithmen (K-Means, Random Forest, Zeitreihenzerlegung) als Python-Objekte bereit, die die Berechnung in die HANA-Engine verlagern und die Trainingsdaten in der Datenbank belassen. Die zweite Tür ist hdbcli, der Low-Level-Python-DB-API-2.0-Treiber für HANA, geeignet zum Skripten von Datenladevorgängen, zum Ausführen von DDL-Migrationen und zum Aufbau leichtgewichtiger operativer Werkzeuge. Die dritte Tür sind Datasphere's eingebettete Notebooks, eine im Datasphere-Tenant laufende JupyterLab-Umgebung mit direktem Zugriff auf die virtuellen und lokalen Tabellen des Space — hier trifft Python auf die Datasphere-Data-Access-Schicht ohne Connector-Overhead.
Voraussetzungen
- Fortgeschrittene praktische Erfahrung in SAP-Analytics-Projekten
- Zuerst die Kernkonzepte wiederholen: C087, C083, C047
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: Ein europäischer Industriehersteller migriert das BW/4HANA-Vertriebsreporting auf Datasphere und SAP Business Data Cloud.
- Das Anti-Pattern erkennen und vermeiden: Eine HANA-Tabelle vor dem Filtern in pandas materialisieren — verlagert die Berechnung von der HANA-Engine auf den Python-Host.
- Die Kernentscheidung des Moduls anwenden: hana-ml-DataFrame vs. hdbcli für eine gegebene Pipeline-Aufgabe — wählen Sie hana-ml für Push-down-Analytics und PAL-Modelltraining, wobei .collect() bis zum letzten und engsten Schritt aufgeschoben wird.
- Die Beherrschung mit dem KPI verfolgen: Push-down-Quote (Ziel: >= 90 % der Pipeline-Schritte werden innerhalb von HANA ausgeführt, bevor der erste .collect erfolgt).
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.