Datasphere Spaces: Definition, Rollen und Abgrenzung

Spaces sind die logischen Isolations- und Governance-Einheiten in SAP Datasphere, in denen Modellierungs-Objekte, Rollen sowie Speicher- und Compute-Kontingente pro Fachbereich, Projekt oder Mandant getrennt verwaltet werden. Jeder Space enthält eigene Data-Builder- und Business-Builder-Objekte, hat eigene Nutzer- und Rollenzuweisungen, ein eigenes Storage- und Ressourcen-Kontingent und tauscht Objekte mit anderen Spaces ausschließlich über explizites Sharing aus.

Was sind Datasphere Spaces?

Ein Space ist ein benannter Container innerhalb eines Datasphere-Tenants. Er trägt eine unveränderliche technische Space-ID (Großbuchstaben, ohne Sonderzeichen) und einen sprechenden Business-Namen. Innerhalb eines Space liegen alle Modellierungs-Artefakte: Local Tables, Views, Analytic Models, Business-Builder-Objekte, Task Chains, Replication Flows, Transformation Flows, Data Flows und die Remote-Connections des Space. Jeder Space hat außerdem ein zugeordnetes Open-SQL-Schema als externen SQL-Zugangspunkt für Drittwerkzeuge.

Der Space existiert, weil ein Cloud-Data-Warehouse in einer Instanz mehrere Fachbereiche, Projekte oder Mandanten parallel bedienen soll, ohne dass sie sich gegenseitig sehen oder Ressourcen wegziehen. In einem klassischen relationalen Warehouse übernehmen Datenbank-Schema und Berechtigungslisten Teile dieser Aufgabe. Ein Datasphere Space bündelt zusätzlich Speicher-Quota, Rollen, Modellierungsraum und Sharing-Grenzen in einem Objekt.

Pro Space werden Disk-Speicher für Local Tables, Memory für den In-Memory Column Store und eine Compute-Priorität konfiguriert. Diese Kontingente sind der operative Hebel, mit dem die Plattform-Verantwortung Fairness zwischen Fachbereichen steuert und den Capacity-Unit-Verbrauch pro Fachbereich messbar macht. Space-Rollen (Space Administrator, Modeler, Integrator, Viewer) regeln, wer im Space modellieren, ausführen oder nur lesen darf. Ein Datasphere-User kann Mitglied in mehreren Spaces mit unterschiedlichen Rollen sein; die globale Tenant-Rolle ist davon getrennt.

Datenaustausch zwischen Spaces geschieht über Sharing. Ein Objekt, etwa ein Analytic Model, wird aus dem Quell-Space explizit an einen oder mehrere Ziel-Spaces freigegeben. Ohne Sharing existiert kein Zugriff über die Space-Grenze hinweg. Der Business Builder und der Datasphere-Katalog liegen dagegen tenant-weit; ein Objekt bleibt in seinem Space, kann aber im Katalog tenant-weit sichtbar gemacht werden.

Abgrenzung: Workspaces, Katalog, HANA-Schema, Hugging Face Spaces

Der Begriff „Space" wird häufig mit Nachbar-Konstrukten aus dem Databricks-Kosmos und mit dem gleichnamigen Deployment-Konzept von Hugging Face verwechselt. Die Unterschiede liegen in Funktion und Ebene.

Begriff	Verhältnis zu Datasphere Spaces
Databricks Workspaces	Multi-User-Arbeitsumgebung in Databricks mit Notebooks, Jobs, Clusters und Repos. Ein Workspace bündelt Compute-Zugriff, User-Verwaltung und Assets im Databricks-Account. Datasphere Spaces sind SAP-eigene Modellierungs- und Governance-Container innerhalb einer Datasphere-Instanz und teilen keine Objekte mit Databricks-Workspaces.
Unity-Catalog-Katalog	Oberste Namensraum-Ebene im Unity-Catalog-Objektmodell (Catalog → Schema → Table) in Databricks. Ein Katalog gruppiert Schemata und Tabellen, trägt aber keine eigenen Compute- oder Storage-Kontingente. Ein Datasphere Space ist eine höherwertige Governance-Grenze mit eigenen Quotas und Rollen.
HANA-Cloud-Schema	Relationale Namensraum-Grenze im engeren Sinn: SQL-Schema mit Tabellen, Views und Berechtigungen auf Datenbank-Ebene. Ein Datasphere Space hat zwar ein Open-SQL-Schema als SQL-Zugangspunkt, transportiert aber zusätzlich Modellierungs-Objekte, Rollen, Storage-Quota und Business-Semantik.
Hugging Face Spaces	Gehostete Apps für ML-Demos und Modell-Deployment auf huggingface.co. Namensgleicher, sachfremder Begriff aus dem ML-Ökosystem, ohne Beziehung zu einer Datenplattform.
BW-Infoareas	Organisatorische Gruppierung von Infoprovidern in SAP BW/4HANA ohne eigene Ressourcen- oder Berechtigungs-Isolation. Datasphere Spaces übernehmen diese Gliederungs-Rolle im Cloud-Modell und ergänzen sie um Rollen und Kontingente.

Beispiel: Finance-, Sales- und Data-Science-Space in einem Tenant

Ein Industrieunternehmen betreibt eine gemeinsame Datasphere-Instanz und richtet darin drei Spaces ein. Der Finance-Space enthält S/4HANA-Fakten und wird von der Konzern-Finanz-IT verwaltet. Der Sales-Space trägt CRM- und Bestell-Daten der Vertriebs-BI. Der Data-Science-Space dient als Sandbox für explorative Modelle, bekommt eine höhere Compute-Priorität und keinen direkten Zugriff auf die Finance-Rohtabellen.

Das Analytic Model „Umsatz pro Kunde" wird im Finance-Space auf Basis der S/4HANA-Local-Tables gebaut. Über Sharing wird es an den Sales-Space und den Data-Science-Space freigegeben, die es in eigenen Views und Modellen weiterverwenden. Jeder Space hat eigene Space-Rollen, eigenes Storage-Kontingent und eigene Nutzerlisten. Ein Vertriebs-Analyst mit Viewer-Rolle im Sales-Space sieht ausschließlich das geteilte Analytic Model, nie die Finance-Rohtabellen. Das Kostencockpit weist den Capacity-Unit-Verbrauch pro Space aus, sodass die Plattform-Verantwortung Fairness und Chargeback pro Fachbereich abbilden kann.