Konzeptkarte

SAP HANA Smart Data Access (SDA)

Stand 27. September 2026

Redaktion: Cédric Mary, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist SAP HANA Smart Data Access (SDA)?

Smart Data Access tauscht Replikationskosten gegen Kosten zur Abfragezeit — kein ETL, keine Veralterung, aber jede Abfrage kostet einen Netzwerk-Roundtrip und eine Remote-Last, weshalb es sich bei seltener, explorativer Nutzung lohnt und bei einer Produktionsgröße von 100 Mio. Zeilen deutlich verliert.

Worum es geht

Smart Data Access (SDA) ist die HANA-seitige Datenvirtualisierungsoberfläche — die Fähigkeit, innerhalb von HANA eine virtuelle Tabelle zu definieren, die auf eine entfernte Quelle verweist (Oracle, Microsoft SQL Server, Teradata, Hadoop Hive, PostgreSQL, generisches ODBC), und HANA die entfernte Quelle bei Bedarf abfragen zu lassen, wobei Prädikate und Joins dorthin verlagert werden, wo der entfernte Optimierer sie verarbeiten kann. Es ist das Föderationsmuster von HANA und ein Schlüsselwerkzeug, wenn die Daten des Kunden über heterogene Quellen verstreut sind, die nicht repliziert werden können oder sollen.

Wie SDA tatsächlich funktioniert. Eine Remote Source wird in HANA mit Verbindungsmetadaten registriert (Treiber, Host, Anmeldedaten, Sicherheit). Eine Virtual Table wird gegen die Remote Source erstellt und verweist auf eine bestimmte entfernte Tabelle oder View; die Virtual Table stellt die entfernten Spalten dem HANA-Katalog so dar, als wären sie lokal. Berührt eine SQL-Abfrage die Virtual Table, analysiert die Föderations-Engine von HANA die Abfrage, entscheidet, was an die entfernte Quelle verlagert wird (typischerweise Filter und Joins zwischen zwei Virtual Tables derselben Quelle) und was nach der Rückgabe der Remote-Quelle lokal ausgeführt wird (Joins mit HANA-nativen Daten, Aggregationen, die die Remote-Quelle nicht kann).

Der Trade-off ist entscheidend. SDA eliminiert die Kosten der Replikation (keine ETL-Pipeline, kein Speicher, keine Veralterung), zahlt dafür aber Kosten zur Abfragezeit (Netzwerk-Roundtrip, Last auf der Remote-Quelle, kein HANA-seitiges Caching). Für seltene, explorative Abfragen gegen eine entfernte Quelle ist SDA das richtige Muster. Für hochfrequente operative Abfragen, die große entfernte Tabellen berühren, schlägt die Replikation nach HANA (Smart Data Integration, SDI; oder BDC Native Shares) SDA fast immer bei den Gesamtkosten.

Warum es zählt

Die Föderations-Engine von HANA verlagert Filter und Joins dorthin, wo der entfernte Optimierer sie verarbeiten kann, und führt den Rest lokal aus, nachdem die Remote-Quelle geantwortet hat.
Für hochfrequente operative Abfragen gegen große entfernte Tabellen schlägt die Replikation nach HANA (über SDI oder BDC Native Shares) SDA fast immer bei den Gesamtkosten.
Der klassische Fehlerfall ist die Nutzung von SDA für Produktions-Analytics gegen eine entfernte Tabelle mit 100 Millionen Zeilen — die Abfragelatenz wird innerhalb eines Monats unerträglich.

Kernpunkte

Föderation, keine Replikation — Virtual Tables verweisen auf entfernte Quellen (Oracle, SQL Server, Teradata, Hive, PostgreSQL, ODBC); Abfragen werden bei Bedarf gegen die Remote-Quelle ausgeführt.
Pushdown — die Föderations-Engine von HANA analysiert Abfragen, verlagert Filter/Joins dorthin, wo der entfernte Optimierer sie unterstützt, und führt den Rest lokal aus.
Trade-off — eliminiert Replikationskosten (kein ETL, kein Speicher, keine Veralterung), zahlt aber Kosten zur Abfragezeit (Netzwerk, Remote-Last, kein HANA-Cache).
Wann ja — Exploration, einmaliges Laden, Compliance-Vorgaben verbieten Replikation.
Anti-Muster — Produktions-Analytics gegen entfernte Tabellen mit 100 Millionen Zeilen; stattdessen über SDI oder BDC Native Shares replizieren.
SDA ist genau das Muster der „Live-Föderation“, das die Replikations-für-Grounding-Leitlinie dieser Plattform (C126) bereits als falschen Standard für einen interaktiven KI-Anwendungsfall benennt — seine Latenz zur Abfragezeit ist zu unvorhersehbar für einen konversationellen Agenten.
Datasphere’s eigene „Remote Table“-Funktion basiert im Hintergrund auf demselben SDA-/Föderationsmechanismus — die Wahl zwischen einer Datasphere Remote Table und einem Datasphere Replication Flow spiegelt den SDA-vs.-Replikation-Trade-off dieser Karte eine Ebene höher wider.
Eignung je Abfragemuster neu bewerten, nicht je Quelle: Dieselbe Virtual Table kann für eine enge, seltene Abfrage richtig und für eine breite, häufige Aggregation gegen dieselbe entfernte Tabelle falsch sein.

Begriffe auf dieser Seite

Smart Data Access (SDA): Die Föderationsoberfläche von HANA — Virtual Tables, die entfernte Quellen bei Bedarf abfragen, ohne die Daten zu replizieren; die günstigere, aber langsamere Alternative zur Replikation über Smart Data Integration.
Remote Source: Eine im HANA-Katalog erfasste Verbindung zu einer externen Datenbank (Oracle, MS SQL Server, Hadoop usw.); die Grundlage, unter der Virtual Tables definiert werden.
Virtual Table: Ein HANA-Katalogobjekt, das über eine Remote Source auf eine entfernte Tabelle oder View verweist; erscheint im HANA-Katalog wie eine lokale Tabelle, wird aber zur Abfragezeit gegen die Remote-Quelle ausgeführt.
Query-Pushdown: Das Föderationsmuster, bei dem HANA entscheidet, welche Teile einer SQL-Abfrage (Filter, Joins, Projektionen) der entfernte Optimierer ausführen kann, diese Teile an die Remote-Quelle sendet und den Rest lokal ausführt.
Entscheidungsträger: Die verantwortliche Person, die den Trade-off akzeptiert und die nächste Maßnahme finanziert.
Smart Data Integration (SDI): Das Replikations-Gegenstück zu SDA auf HANA-Seite — verschiebt Daten nach HANA, statt sie zur Abfragezeit vor Ort abzufragen; die übliche Alternative, sobald die Kosten von SDA zur Abfragezeit den Nutzen der Nicht-Replikation übersteigen.
Remote Table (Datasphere): Datasphere’s eigenes Föderationsobjekt, aufgebaut auf demselben SDA-/Virtual-Table-Mechanismus, den diese Karte auf HANA-Ebene beschreibt — die Datasphere-seitige Entscheidung (Remote Table vs. Replication Flow) spiegelt SDA vs. SDI eine Ebene höher im Stack.
Abfragemuster (Query Pattern): Die Form der tatsächlich gegen eine Virtual Table ausgeführten Abfragen — eng/gefiltert/selten gegenüber breit/aggregiert/häufig — der eigentliche Faktor, der bestimmt, ob SDA für einen gegebenen Konsumenten die richtige Architektur ist, unabhängig vom Quellsystem selbst.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.