SAP Datasphere is a cloud-native data management and data warehousing platform built on SAP HANA Cloud. It provides data integration, cataloging, semantic modeling, and virtualized access across SAP and non-SAP sources without necessarily moving all data physically.

Compared to BW/4HANA, which is a traditional, more rigid enterprise data warehouse focused on structured, governed InfoProviders and process chains, Datasphere is lighter-weight, cloud-first, favors virtualization over heavy staging, and integrates natively with SAP Analytics Cloud, S/4HANA, and non-SAP tools like Databricks.

It was originally launched as SAP Data Warehouse Cloud (DWC) and was rebranded to SAP Datasphere in 2023, alongside an expanded scope covering data cataloging, data marketplace, and open data ecosystem integration (e.g., Databricks partnership).

The main components are:

• Spaces — isolated tenants of storage, compute, and permissions
• Data Builder — for tables, views, and data flows
• Business Builder — for semantic, business-friendly models
• Connections — for source system connectivity
• Data Integration Monitor — for replication flow and task chain monitoring
• Catalog — for metadata governance and data discovery

A Space is a secure, logically isolated container within a Datasphere tenant that has its own storage allocation, compute resources, users, and connections. Spaces are typically used to separate teams, departments, or projects (e.g., Finance Space vs. Sales Space), and data sharing between spaces is explicit and controlled.

Datasphere runs on SAP HANA Cloud, giving it in-memory columnar processing, and it also supports federated access to open data lake formats via Data Lake and partner integrations such as Databricks.

A Graphical View is built using a drag-and-drop canvas with nodes (join, union, aggregation, projection, etc.) — it's easier to maintain and self-documenting. A SQL View is written directly in SQL, offering more flexibility for complex logic (window functions, subqueries) but is harder to visualize and maintain for non-technical users.

An ER Model lets you visually define relationships (associations) between multiple tables or views — similar to a data model diagram. It's primarily a design/documentation tool that helps you understand table cardinalities before building consumption or analytic models on top.

You can create Local Tables (native to Datasphere, editable and used for staging or manual entry) and Remote Tables (pointers to source-system tables via a connection, which can be either virtualized or replicated).

A Replication Flow moves data (often at scale, including delta/CDC changes) from a source connection into Datasphere with minimal transformation — think bulk load / sync. A Data Flow is used for more complex ETL-style transformations (joins, script nodes, cleansing) as data moves from source to target, typically at a smaller/more curated scale.

Virtual access means Datasphere queries the source system live, in real time, with no data physically stored — good for freshness but dependent on source performance and network latency. Replication physically copies the data into Datasphere's storage (Snapshot or Real-Time with change data capture), improving query performance at the cost of storage and a refresh/sync cadence.

Task Chains orchestrate a sequence of operations — like triggering data flows, replication flows, view persistency refreshes, or even other task chains — in a defined order, optionally on a schedule. They're the Datasphere equivalent of BW process chains.

Data Builder is more technical — it deals with raw tables, joins, and transformations. Business Builder sits a layer above it and lets business users define semantically rich objects: Dimensions, Hierarchies, Fact Models, and Consumption Models — the layer that's exposed for reporting and planning in tools like SAP Analytics Cloud.

A Fact Model defines measures (e.g., Revenue, Quantity) and associates them with dimensions (e.g., Time, Product, Customer) — conceptually similar to a star schema's fact table, but modeled semantically rather than as a physical join.

A Consumption Model combines one or more Fact Models with associated dimensions into a single, reporting-ready model that's exposed to consuming tools (like SAC) as an OData or analytic service. It lets you control exactly which fields, measures, and hierarchies are surfaced to end users.

A standard Dimension holds descriptive attributes for a business entity (e.g., Product ID, Product Name). A Hierarchy Dimension additionally defines parent-child or level-based relationships (e.g., Region → Country → City), enabling drill-down analysis in reporting tools.

Yes — this is one of the key benefits of Business Builder. Dimensions like "Time" or "Cost Center" can be built once and shared across many Fact Models and Consumption Models, ensuring consistency (a conformed-dimension approach).

Typically via ABAP CDS Views exposed through an SAP-managed connection type, or via OData services. CDS Views (especially those with @Analytics.dataCategory annotations) can be consumed directly as remote tables, preserving associations and hierarchies where possible.

ODP (Operational Data Provisioning) is an SAP framework that provides delta-enabled extraction from ABAP-based sources (like extractors, CDS views). Datasphere replication flows can use ODP-based connections to pull both full loads and incremental/delta changes efficiently from S/4HANA or BW systems.

SAC connects via a Live Data Connection for real-time query pass-through (no data duplication, good for large/live data) or an Import Connection that copies data into SAC's in-memory model (better performance for planning, but requires refresh). Datasphere's "SAC Model Import" and "Seamless Planning" features are also built on top of this integration.

Seamless Planning lets SAC planning models write back private/planning-relevant data directly into a Datasphere space, keeping the "single source of truth" in Datasphere rather than duplicating actuals and plan data separately in SAC — reducing data replication and reconciliation effort.

Datasphere supports a broad connector catalog including generic OData, JDBC/ODBC, cloud storage (Amazon S3, Azure Data Lake, Google Cloud Storage), Databricks, and other databases (e.g., Snowflake, Google BigQuery via partner connectors) — supporting a genuinely open, multi-cloud data landscape.

Cross-space sharing lets one Space expose objects (tables/views) to another Space within the same tenant. Data Marketplace extends this concept further, allowing organizations to publish or consume curated third-party datasets directly into their Datasphere landscape.

A Data Access Control is a reusable row-level security rule (e.g., restrict by Region or Cost Center) that can be applied across multiple views/models, so users only see data relevant to their role — without duplicating the logic in every model.

Through a combination of Space-level roles/permissions (who can access a Space and what they can do — model, view, admin) and object-level Data Access Controls for row-level restrictions, often integrated with an identity provider via SAML/SSO.

The Catalog indexes metadata across spaces — glossary terms, data lineage, tags, and quality metrics — so users and admins can discover trustworthy data assets and understand where data originates and how it's transformed, supporting compliance and self-service.

SAP BDC is positioned as a broader, unified data fabric layer that sits above and connects Datasphere, SAC, and other SAP/non-SAP data products — Datasphere remains the modeling and integration engine underneath, while BDC focuses on cross-application data products, harmonized business data, and AI (Joule) readiness at an enterprise-wide scale.

Generally you'd favor replication with real-time/CDC here, since virtualizing a query against 500M rows hourly would put heavy repeated load on the source system and hurt query latency. Replication with delta capture keeps a performant local copy in Datasphere while still reflecting near-real-time changes. The trade-off is the extra storage cost and monitoring the replication flow's health.

By default, views compute results on the fly when queried. View Persistency lets you materialize (snapshot) the view's output into storage on a schedule, which dramatically improves query performance for complex, frequently-accessed views at the cost of data freshness between refresh runs.