SAP Databricks einrichten: was es ist, wie Sie starten, wo die Grenzen liegen

Kein Connector, keine Datenbank, kein Data Lake allein. Ein Praxisleitfaden von der Provisionierung bis zum Reporting, mit einem ehrlichen Kapitel zur Harmonisierung mehrerer ERP-Systeme.

Die Lizenz für SAP Business Data Cloud ist unterschrieben, SAP Databricks steht im Angebot, und im ersten Architektur-Workshop fragt jemand: „Ist das jetzt ein Connector, eine Datenbank oder ein Data Lake?“ Die ehrliche Antwort lautet: nichts davon allein. Und genau an dieser Unschärfe entscheidet sich, ob das Team in drei Monaten Ergebnisse liefert oder noch über Zuständigkeiten für Speicher, Rechte und Kosten diskutiert. Dieser Leitfaden ordnet ein, was SAP Databricks ist, führt durch die Einrichtung und zeigt, wo die Grenzen liegen, besonders wenn neben SAP noch andere ERP-Systeme im Spiel sind.

---

---

Das Ziel: Nach diesem Artikel können Sie entscheiden, ob SAP Databricks zu Ihrem Vorhaben passt, einen Account sauber aufsetzen, SAP- und Nicht-SAP-Daten anbinden und das Ergebnis kontrolliert in Reporting und zurück nach SAP bringen.

Was SAP Databricks eigentlich ist

Die Doku definiert es knapp: SAP Databricks ist „a version of Databricks available as an application in SAP Business Data Cloud (BDC)“. Um zu verstehen, was das heißt, hilft ein Blick auf Databricks selbst. Databricks beschreibt sich als einheitliche, offene Analyseplattform, die auf Apache Spark aufbaut und zwei Kerntechnologien ergänzt: Delta Lake als Speicherschicht mit ACID-Transaktionen und Schema-Durchsetzung, und Unity Catalog als Governance-Schicht für Daten und KI. Das Architekturmuster dahinter heißt Lakehouse: ein Datenmanagementsystem, das die Eigenschaften von Data Lake und Data Warehouse verbindet.

Damit lässt sich die Frage aus dem Workshop beantworten:

Der zugespitzte Satz: SAP Databricks ist eine verwaltete Rechen- und Governance-Umgebung, die auf SAP-Datenprodukte zugreift, ohne sie zu kopieren, und eigene Ergebnisse als neue Datenprodukte zurückgeben kann.

Gegenüber dem eigenständigen Databricks gibt es Unterschiede, die Sie kennen sollten. Die SAP-Edition beschreibt sich als „special edition of Databricks optimized for analytics and AI for data in SAP“. Notebooks unterstützen dort Python und SQL; das allgemeine Databricks nennt zusätzlich R und Scala. Alle Workspaces sind Serverless, Speicher und Rechenleistung werden verwaltet. Und der Datenaustausch ist asymmetrisch: SAP Databricks kann OpenSharing-Freigaben empfangen, aber laut Doku keine Freigaben an Ziele außerhalb von SAP auslösen.

Brauchen Sie das überhaupt?

SAP Databricks lohnt sich, wenn mindestens drei dieser Punkte zutreffen:

1. Sie haben SAP Business Data Cloud lizenziert oder planen es. Ohne BDC gibt es SAP Databricks nicht.
2. Ihre Fragestellungen gehen über Standardberichte hinaus: Prognosen, Machine Learning, Anreicherung mit Nicht-SAP-Daten, KI-Funktionen auf Geschäftsdaten.
3. Sie wollen SAP-Daten nutzen, ohne eigene Extraktionsstrecken zu bauen und zu betreiben.
4. Sie haben oder bekommen Personen, die mit SQL und Python arbeiten. SAP Databricks ist kein Klick-Werkzeug für Fachbereiche.
5. Ergebnisse sollen zurück in die SAP-Welt fließen, etwa als Datenprodukt für andere BDC-Anwendungen.

Wenn Sie ausschließlich Standardreporting auf SAP-Daten brauchen, ist SAP Databricks vermutlich die teurere Antwort auf eine einfachere Frage. Wenn Ihr Schwerpunkt auf Nicht-SAP-Daten liegt und SAP nur eine Quelle unter vielen ist, prüfen Sie die Einschränkungen weiter unten besonders genau.

Voraussetzungen

• Sie haben ein SAP-Business-Data-Cloud-Abonnement. (Kostet Geld und eine Vertragsentscheidung.)
• Sie haben eine Person mit BDC-Administrationsrechten, die SAP Databricks aus dem Portal „SAP for Me“ provisionieren darf.
• Sie haben festgelegt, wer der erste Account-Admin wird. Diese Person erhält nach der Provisionierung die Einladung und hat danach die höchsten Rechte im Account.
• Sie nutzen SAP Cloud Identity Services oder planen es. SAP Databricks arbeitet ausschließlich mit Single Sign-on; Passwörter werden laut Doku nicht unterstützt.
• Sie haben entschieden, in welcher Cloud-Region der Account laufen soll (dazu gleich mehr, das ist eine Einbahnstraße).
• Für Nicht-SAP-Daten: Sie haben Zugriff auf einen Speicher-Bucket in derselben Cloud (S3, Azure Data Lake Storage oder Google Cloud Storage) und die Rechte, dort Zugangsdaten anzulegen.
• Für Reporting: Sie haben Power BI Desktop oder den Power-BI-Dienst, falls Sie dort berichten wollen.

Die Landkarte: welcher Weg, und warum

Dieser Artikel geht den ersten Weg, weil er der ist, den die meisten SAP-Kunden mit BDC-Lizenz zuerst prüfen.

Schritt für Schritt

Schritt 1: Account aus „SAP for Me“ provisionieren

Was Sie tun: Eine BDC-Administratorin provisioniert SAP Databricks im Portal „SAP for Me“ nach der SAP-Dokumentation. Danach führt der Ablauf in die Databricks-Registrierung, wo die erste Person ihre E-Mail-Adresse bestätigt und den Bedingungen zustimmt.

Woran Sie den Erfolg erkennen: Die erste eingeladene Person erhält eine E-Mail, sobald der Account bereit ist. Der erste Workspace wird automatisch angelegt.

Häufigste Fehlerursache: Die falsche Person wird als erste eingeladen. Laut Doku wird der erste Nutzer automatisch Account-Admin. Legen Sie das vorher fest, nicht im Moment der Provisionierung.

Schritt 2: Region festlegen, bevor Sie weitere Workspaces anlegen

Was Sie tun: Prüfen Sie, in welcher Region der Account steht, und entscheiden Sie, ob das zu Ihren Vorgaben passt. Für Europa nennt die Doku Frankfurt (AWS eu-central-1 und GCP europe-west3) sowie West Europe in den Niederlanden (Azure westeurope).

Woran Sie den Erfolg erkennen: Die Region ist dokumentiert und von Datenschutz und IT-Sicherheit abgezeichnet.

Häufigste Fehlerursache: Die Annahme, man könne später eine zweite Region ergänzen. Die Doku ist eindeutig: „Accounts can only deploy workspaces in a single region.“ Das ist der Point of no Return dieses Leitfadens. Beachten Sie außerdem, dass einzelne Funktionen regional eingeschränkt sind; Foundation Model Fine-tuning etwa setzt laut Doku die Region us-east-1 voraus.

Schritt 3: Identitäten und Gruppen anbinden

Was Sie tun: Aktivieren Sie die Integration mit SAP Cloud Identity Services, Identity Provisioning. Nutzer und Gruppen werden per SCIM synchronisiert. Databricks empfiehlt, Cloud Identity Services als einzige Quelle für Identitäten in der SAP-Landschaft zu nutzen und Rechte über Gruppen auf Account-Ebene zu vergeben, nicht an Einzelpersonen.

Woran Sie den Erfolg erkennen: Nutzer melden sich über login.databricks.com mit ihren SSO-Zugangsdaten an, und die Gruppen aus dem Identity Provider erscheinen im Account.

Häufigste Fehlerursache: Gruppen werden zusätzlich manuell in Databricks gepflegt. Extern synchronisierte Gruppen lassen sich laut Doku standardmäßig nicht in Databricks ändern; doppelte Pflege führt zu Rechten, die niemand mehr erklären kann.

Schritt 4: Netzwerk absichern, ohne die BDC-Verbindung zu kappen

Was Sie tun: Entscheiden Sie, ob Sie IP-Access-Lists (Zugriff nur aus bestimmten Netzen), Serverless Egress Control (Begrenzung ausgehender Verbindungen) oder eine Network Connectivity Configuration (Zugriff auf Quellen in Ihrem Netz, nur AWS und Azure) brauchen.

Woran Sie den Erfolg erkennen: Die Einstellungen sind aktiv, und SAP-Datenprodukte sind danach weiterhin abfragbar.

Häufigste Fehlerursache: IP-Listen oder Egress-Regeln, die die Verbindung zu BDC unterbrechen. Die Doku warnt an beiden Stellen ausdrücklich davor und verweist vorher auf die SAP-Dokumentation. Testen Sie jede Netzwerkänderung zuerst in einem Nicht-Produktions-Workspace.

Schritt 5: Zugriff durch Support-Personal regeln

Was Sie tun: Legen Sie in den Workspace-Einstellungen (Settings, Advanced, Access Control) fest, ob und wie lange Personal von SAP Databricks zur Fehleranalyse auf den Workspace zugreifen darf. Möglich sind laut Doku bis zu 48 Stunden oder dauerhafter Zugriff, oder kein Zugriff.

Woran Sie den Erfolg erkennen: Die Einstellung ist bewusst gesetzt und dokumentiert, nicht der Standard.

Häufigste Fehlerursache: Dauerhafter Zugriff wird aus Bequemlichkeit eingeschaltet. Für regulierte Umgebungen ist eine befristete Freigabe pro Supportfall die verteidigbare Variante.

Schritt 6: Workspaces nach Umgebung oder Team schneiden

Was Sie tun: Legen Sie in der Account Console (Workspaces, Create workspace) weitere Workspaces an, etwa für Entwicklung, Test und Produktion, und vergeben Sie Rechte über den Reiter Permissions. Entscheiden Sie zwischen Trennung nach Umgebung und Trennung nach Team. Faustregel: Trennen Sie nach Umgebung, sobald produktive Ergebnisse nach SAP zurückgeschrieben werden; nach Team, wenn Teams mit unterschiedlich sensiblen Daten arbeiten.

Woran Sie den Erfolg erkennen: Jeder Workspace hat einen dokumentierten Zweck und eine verantwortliche Gruppe.

Häufigste Fehlerursache: Der automatisch angelegte erste Workspace wird stillschweigend zur Produktion. Jeder Workspace bringt einen eigenen Workspace-Catalog mit, in dessen Schema „default“ laut Doku alle Nutzer des Workspaces Objekte anlegen dürfen. Ohne bewusste Trennung entsteht dort ein ungeordneter Mischbestand.

Schritt 7: SAP-Datenprodukte freigeben und Rechte eingrenzen

Was Sie tun: Fordern Sie im BDC-Katalog Zugriff auf das benötigte Datenprodukt an und geben Sie es nach der Genehmigung an SAP Databricks frei (die SAP-seitigen Schritte stehen in der SAP-Dokumentation). Danach erscheint das Datenprodukt in Unity Catalog als eigener Catalog.

Danach kommt der Schritt, der oft vergessen wird: Laut Doku haben standardmäßig alle Nutzer eines Workspaces Lesezugriff auf freigegebene SAP-Schemas und -Tabellen. Grenzen Sie das über das Rechtemodell von Unity Catalog auf die Gruppen ein, die die Daten wirklich brauchen.

Woran Sie den Erfolg erkennen: Eine Abfrage wie SELECT * FROM <catalog>.<schema>.<tabelle> liefert im SQL-Editor Daten, und DESCRIBE TABLE EXTENDED zeigt die von SAP übernommenen Spaltenbeschreibungen und Schlüssel.

Häufigste Fehlerursache: Personenbezogene Daten sind für alle lesbar, weil die Standardrechte nie angepasst wurden. SAP Databricks übernimmt die SAP-Kennzeichnungen für personenbezogene und sensible Daten als Tags im Namensraum sap.PersonalData. Nutzen Sie diese Tags in attributbasierten Zugriffsregeln (ABAC), statt Tabelle für Tabelle von Hand zu sperren. Ändern Sie die Tags selbst nicht; die Doku warnt, dass manuell gesetzte Werte im Namensraum sap.* wieder entfernt werden können.

Schritt 8: Nicht-SAP-Daten anbinden

Was Sie tun: Die Doku nennt drei Wege für Nicht-SAP-Daten: Cloud-Speicher-Buckets über External Locations, externe APIs und empfangene OpenSharing-Freigaben. Für den häufigsten Fall, Dateien in einem Bucket, legen Sie im Catalog Explorer unter External data eine External Location an. Auf AWS gibt es dafür einen Schnellstart per CloudFormation, der die nötigen Zugangsdaten mit anlegt.

Woran Sie den Erfolg erkennen: Die External Location ist in Unity Catalog sichtbar, und Sie können darauf externe Tabellen oder Volumes anlegen und Rechte darauf vergeben.

Häufigste Fehlerursache: Die Erwartung, Ergebnisse direkt in den eigenen Bucket zurückschreiben zu können. Die Doku verlangt, dass External Locations und Storage Credentials schreibgeschützt sind, damit SAP-Daten im SAP-verwalteten Speicher bleiben. Hier ist die Doku allerdings nicht einheitlich: Die Seite zu S3 sagt zugleich, nur AWS-Accounts könnten S3-Buckets „with read and write access“ anbinden, und warnt im selben Absatz, External Locations müssten schreibgeschützt sein. Planen Sie mit schreibgeschütztem Zugriff, bis SAP Ihnen etwas anderes schriftlich bestätigt.

Schritt 9: Rechenleistung, Kosten und Reporting einrichten

Was Sie tun: Workspace-Admins legen Serverless SQL Warehouses an; Nutzer brauchen mindestens die Berechtigung CAN USE, um darauf Abfragen auszuführen. Parallel richten Sie die Kostenkontrolle ein: Serverless Usage Policies (in Preview) hängen Kostenstellen-Tags an jede Serverless-Nutzung, und die Systemtabellen system.billing.usage und system.billing.list_prices zeigen Verbrauch und Listenpreise je SKU. Ein vorgefertigtes Usage-Dashboard ist laut Release Notes seit März 2026 allgemein verfügbar. Für Power BI verbinden Sie Desktop oder Dienst mit dem SQL Warehouse über den Databricks-Connector.

Woran Sie den Erfolg erkennen: Ein Power-BI-Bericht liest aus dem SQL Warehouse, und der Verbrauch dieses Berichts taucht mit dem richtigen Kostenstellen-Tag in system.billing.usage auf.

Häufigste Fehlerursache: Kostenkontrolle wird nachgerüstet, wenn die erste Rechnung überrascht. Die Billing-Tabellen sind nicht automatisch für alle lesbar: Eine Person, die gleichzeitig Metastore-Admin und Account-Admin ist, muss die Rechte darauf vergeben.

Schritt 10: Ergebnisse als Datenprodukt zurück nach SAP geben

Was Sie tun: Jeder Workspace hat einen vorkonfigurierten OpenSharing-Empfänger namens sap-business-data-cloud. Sie legen einen Share an (Catalog Explorer, SQL oder CLI), fügen die Daten hinzu und geben sie frei. Damit das Ergebnis in BDC auffindbar ist, müssen Sie es laut Doku mit dem SDK von SAP Business Data Cloud in CSN und ORD beschreiben.

Wie ein eigenes Datenprodukt auf SAP-Seite aufgebaut ist und welche Entscheidungen Sie dafür vorher treffen müssen, beschreibt der Leitfaden SAP Data Products bauen. Dort heißt das Freigabeprotokoll noch Delta Sharing; die SAP-Databricks-Doku verwendet heute durchgängig den Namen OpenSharing.

Woran Sie den Erfolg erkennen: Das Datenprodukt ist im BDC-Katalog auffindbar und für andere BDC-Anwendungen nutzbar.

Häufigste Fehlerursache: Der Share ist angelegt, aber die semantische Beschreibung fehlt. Dann ist das Ergebnis technisch freigegeben, aber in BDC nicht auffindbar.

Reihenfolge: Die Schritte 1 bis 3 sind streng sequenziell. Schritt 2 ist der Point of no Return. Die Schritte 4 bis 6 können parallel laufen. Schritt 7 setzt 3 und 6 voraus, Schritt 10 setzt 7 voraus.

So holen Sie die volle Effizienz heraus

Effizienz entscheidet sich bei SAP Databricks an drei Stellen: wo die Geschäftslogik liegt, wie das Reporting abfragt und ob die Kosten zuordenbar sind.

Geschäftslogik in die Plattform, nicht in den Bericht. Die Power-BI-Empfehlungen in der SAP-Databricks-Doku sind hier deutlich: Transformationen „nach links“ schieben, also Kernlogik als SQL-Views in Databricks statt in Power Query und DAX. Für Faktentabellen DirectQuery, für Dimensionstabellen den Modus Dual, und DirectQuery wo möglich gegenüber Import bevorzugen, weil Governance und Nachvollziehbarkeit erhalten bleiben.

Kennzahlen einmal definieren. Das allgemeine Databricks beschreibt Metric Views als gemeinsame semantische Schicht: Kennzahlen werden einmal definiert und über beliebige Dimensionen abgefragt. Die Release Notes von SAP Databricks führen Metric Views mehrfach (unter anderem Parameter in Preview seit Juni 2026), und das Excel-Add-in in Preview kann laut Release Notes aus Metric Views importieren. Wenn Sie Kennzahlen in Power BI, Excel und Notebooks gleichzeitig nutzen, ist das der Hebel gegen drei abweichende Umsatzzahlen.

Die SAP-Semantik mitnehmen. SAP-Tabellen- und Spaltennamen sind schwer lesbar; die Doku räumt das selbst ein. Beim Zugriff auf ein BDC-Datenprodukt übernimmt SAP Databricks Tabellen- und Spaltenbeschreibungen, Primär- und Fremdschlüssel sowie die Datenschutz-Tags automatisch. Das macht die Daten für Analysten, für Genie Code im Editor und für Genie Agents in natürlicher Sprache nutzbar, ohne SAP-Namenskonventionen zu kennen.

Kosten zuordnen, bevor sie entstehen. Ein Usage-Policy-Tag pro Projekt oder Kostenstelle, eine regelmäßige Abfrage auf system.billing.usage, und die Frage „Wer hat das verbraucht?“ ist in Minuten beantwortet statt in einer Abstimmungsrunde.

Mehrere SAP- und Nicht-SAP-ERP-Systeme harmonisieren: was passt, was nicht

Die zweite häufige Frage lautet: Kann SAP Databricks die Harmonisierungsschicht über mehrere ERP-Systeme sein, damit ein gemeinsames Reporting möglich wird? Die Antwort hat zwei Teile.

Was passt. Das Muster, das Databricks dafür empfiehlt, heißt Medallion-Architektur: Bronze für Rohdaten im Originalzustand, Silver für Bereinigung und Validierung, Gold für fachlich modellierte, aggregierte Daten. Die Doku beschreibt die Silver-Schicht ausdrücklich als den Ort für „data cleansing, deduplication, and normalization“, inklusive Schema-Durchsetzung, Typkonvertierung und Joins. Gold-Schichten dürfen nach Fachdomäne getrennt sein, etwa Finanzen, HR und IT. Genau das ist die Arbeit einer Harmonisierungsschicht für Bewegungsdaten: Buchungen, Aufträge und Rechnungen aus verschiedenen Systemen in ein gemeinsames Format bringen und daraus konzernweite Kennzahlen bilden.

Wo SAP Databricks Grenzen setzt. Drei Punkte aus der Doku prägen diese Architektur:

1. Nicht-SAP-Systeme sind in der SAP-Edition nicht als Quellsysteme angebunden, sondern kommen über Cloud-Speicher, externe APIs oder OpenSharing. Praktisch heißt das: Ihre anderen ERP-Systeme müssen ihre Daten zuerst in einen Bucket exportieren. Diese Exportstrecke liegt außerhalb von SAP Databricks und muss betrieben werden.
2. Fremdschlüssel aus SAP-Datenprodukten werden nur innerhalb desselben Shares übernommen. Beziehungen über Datenproduktgrenzen hinweg modellieren Sie selbst.
3. Harmonisierte Ergebnisse verlassen SAP Databricks nur Richtung BDC oder über Abfragen (SQL Warehouse, Power BI, Excel). Ein OpenSharing-Share an ein Nicht-SAP-Ziel ist laut Doku nicht möglich.

Wo die Aufgabe eine andere wird. Die schwierigste Frage einer ERP-Harmonisierung ist selten das Format, sondern die Identität: Ist Kunde 4711 in ERP A derselbe wie Kunde K-0815 in ERP B? Ist das Material in Werk Nord dasselbe wie in Werk Süd? Das ist Stammdatenmanagement, also Abgleich, Dublettenauflösung und ein gepflegter „Golden Record“ mit Verantwortlichen und Freigabeprozess. Deduplizieren kann man technisch auch in einer Silver-Tabelle. Aber die Entscheidung, welcher Datensatz gilt, und die laufende Pflege dieser Entscheidung gehören in eine MDM-Disziplin, in vielen Unternehmen in eine eigene Plattform wie Reltio. Die saubere Arbeitsteilung: Das MDM liefert die Zuordnungstabelle (welche lokale ID gehört zu welchem globalen Objekt), Databricks wendet sie in der Silver-Schicht an und baut darauf die Gold-Schicht für das Reporting.

Der zugespitzte Satz für den Lenkungskreis: SAP Databricks harmonisiert Bewegungsdaten. Wer welcher Kunde ist, entscheidet es nicht.

---

Stolperfallen

Ein Hinweis für die Planung: Die Funktionslisten der SAP-Edition nennen geplante Notebooks und geplante Abfragen. Jobs und Lakeflow-Pipelines tauchen nur am Rand auf, in Seiten zu Netzwerk und Kostenzuordnung. Wenn Ihre Harmonisierung auf Pipelines mit Abhängigkeitssteuerung aufbauen soll, lassen Sie sich die Verfügbarkeit in der SAP-Edition vorher bestätigen.

---

Checkliste

• ☐ BDC-Abonnement vorhanden, BDC-Admin benannt
• ☐ Erster Account-Admin festgelegt
• ☐ Region gewählt und freigegeben (nicht änderbar)
• ☐ SAP Cloud Identity Services angebunden, Gruppen per SCIM synchronisiert
• ☐ Netzwerkregeln entschieden und gegen die BDC-Verbindung getestet
• ☐ Zugriff durch Support-Personal bewusst eingestellt
• ☐ Workspaces nach Umgebung oder Team getrennt, Zweck dokumentiert
• ☐ Erste SAP-Datenprodukte freigegeben, Standard-Leserechte eingegrenzt
• ☐ ABAC-Regeln auf Basis der sap.PersonalData-Tags angelegt
• ☐ External Locations für Nicht-SAP-Daten angelegt, schreibgeschützt
• ☐ Serverless SQL Warehouse eingerichtet, CAN-USE-Rechte vergeben
• ☐ Usage Policies mit Kostenstellen-Tags aktiv, Billing-Tabellen freigegeben
• ☐ Power BI angebunden (DirectQuery für Fakten, Dual für Dimensionen)
• ☐ Kennzahlen als Metric Views statt im Bericht definiert
• ☐ Rückweg nach BDC getestet, inklusive CSN/ORD-Beschreibung
• ☐ Bei mehreren ERP-Systemen: Exportstrecke in Buckets und Verantwortung für Stammdatenzuordnung geklärt

---

Häufige Fragen

Ist SAP Databricks ein Connector zwischen SAP und Databricks? Nein. SAP-Datenprodukte werden per OpenSharing freigegeben und erscheinen als Catalog, laut Doku ohne Replikation. Es gibt keinen Ladeprozess, den Sie betreiben.

Wo liegen meine Daten? Im von SAP verwalteten Speicher. Die Doku betont, dass Compute und Storage vollständig verwaltet sind und keine zusätzlichen Cloud-Ressourcen nötig sind. Externe Buckets binden Sie schreibgeschützt an.

Kann ich harmonisierte Daten an ein Nicht-SAP-System weitergeben? Nicht per OpenSharing-Share. Abfragen über SQL Warehouses, Power BI oder Excel sind möglich, ein Share an Ziele außerhalb von SAP laut Doku nicht.

Brauche ich zusätzlich ein MDM-System, wenn ich mehrere ERPs harmonisiere? Für Bewegungsdaten nicht zwingend. Sobald Kunden, Lieferanten oder Materialien systemübergreifend als dasselbe Objekt erkannt und gepflegt werden müssen, ja. Das ist eine Stammdatenentscheidung mit eigenem Prozess, keine reine Transformation.

Welche Sprachen kann ich in Notebooks nutzen? In SAP Databricks Python und SQL. Das allgemeine Databricks nennt zusätzlich R und Scala.

Darf Support-Personal auf meinen Workspace zugreifen? Nur wenn Sie es erlauben, befristet bis zu 48 Stunden oder dauerhaft. Zugriffe unterliegen laut Doku einem Genehmigungsprozess und werden in Audit-Logs protokolliert.

---

Quellen und Sicherheit

Alle Quellen am 31.10.2026 im Rohtext abgerufen.

1. SAP Databricks documentation, What is SAP Databricks? https://docs.databricks.com/sap/en/ (Stand 29.10.2026)
2. SAP Databricks admin guide. https://docs.databricks.com/sap/en/admin-guide (Stand 29.10.2026)
3. SAP Databricks user guide. https://docs.databricks.com/sap/en/user-guide (Stand 29.10.2026)
4. Set up your SAP Databricks account. https://docs.databricks.com/sap/en/provision-account (Stand 11.09.2026)
5. SAP Databricks admin best practices. https://docs.databricks.com/sap/en/admin-best-practices (Stand 29.10.2026)
6. Share SAP data into SAP Databricks. https://docs.databricks.com/sap/en/share-data (Stand 15.10.2026)
7. Publish data from SAP Databricks to SAP BDC. https://docs.databricks.com/sap/en/publish-data-bdc (Stand 11.09.2026)
8. Connect to external data sources. https://docs.databricks.com/sap/en/external-data (Stand 29.10.2026)
9. Connect to an S3 bucket. https://docs.databricks.com/sap/en/external-locations (Stand 06.10.2026)
10. Access data shared with you using OpenSharing. https://docs.databricks.com/sap/en/read-share (Stand 08.10.2026)
11. Networking and security. https://docs.databricks.com/sap/en/network-security (Stand 11.09.2026)
12. Workspace access for SAP Databricks personnel. https://docs.databricks.com/sap/en/sap/workspace-access (Stand 11.09.2026)
13. Data analysis with notebooks. https://docs.databricks.com/sap/en/notebooks (Stand 15.10.2026)
14. Business intelligence with Databricks SQL. https://docs.databricks.com/sap/en/sql (Stand 15.10.2026)
15. AI and machine learning. https://docs.databricks.com/sap/en/machine-learning (Stand 06.10.2026)
16. Database objects in SAP Databricks. https://docs.databricks.com/sap/en/database-objects
17. View and query the billing logs. https://docs.databricks.com/sap/en/cost-management (Stand 11.09.2026)
18. Attribute usage with serverless usage policies. https://docs.databricks.com/sap/en/admin/usage/budget-policies (Stand 28.09.2026)
19. Power BI cheat sheet. https://docs.databricks.com/sap/en/cheat-sheet/power-bi (Stand 11.09.2026)
20. SAP Databricks Release Notes März und Juni 2026. https://docs.databricks.com/sap/en/release-notes/2026/march, https://docs.databricks.com/sap/en/release-notes/2026/june
21. What is Databricks? https://docs.databricks.com/aws/en/introduction (Stand 29.10.2026)
22. What is a data lakehouse? https://docs.databricks.com/aws/en/lakehouse (Stand 29.10.2026)
23. What is the medallion lakehouse architecture? https://docs.databricks.com/aws/en/lakehouse/medallion (Stand 29.10.2026)

Nicht als Beleg verwendet: die SAP-Produktseite (https://www.sap.com/germany/products/data-cloud/databricks.html, HTTP 403 beim Abruf) und die SAP-Hilfeseiten unter help.sap.com (Inhalt nur per JavaScript).

Sicherheit der tragenden Aussagen

---

Sascha Theismann begleitet Unternehmen bei messbarer digitaler Transformation – von KI- und Automatisierungs-Governance bis zur Enterprise-Architektur im SAP-Umfeld.