Home Snowflake AI Data Cloud

Snowflake AI Data Cloud

_Snowflake AI Data Cloud

In diesem Artikel beleuchten wir die Integration von SAP BDC mit Snowflake AI Data Cloud etwas genauer. Mit SAP Business Data Cloud (BDC) hat die SAP ihre neue strategische Plattform für Data & AI inzwischen erfolgreich am Markt etabliert. Eine der massgeblichen Neuerungen von BDC ist die Öffnung hin zu anderen Cloud-Plattformen über SAP BDC Connect, sodass semantisch wertvolle und oftmals Business-kritische SAP-Daten in semantisch sauber aufgesetzten (von SAP gemangten) Data Products ohne grössere Engineering-Aufwände in den unterschiedlichen Plattformen verwendet werden können.

Inhaltsverzeichnis
 

1. Was ist und kann Snowflake?

Zuvor sollten wir aber die fundamentale Frage klären, was Snowflake ist und es so besonders macht.
 
Snowflake ist bereits seit 2012 am Markt aktiv und ist einer der grössten Anbieter im Kontext Data Warehousing. Snowflake wurde von Benoit Dageville, Thierry Cruanes (beide ehemalige Oracle-Ingenieure) und Marcin Zukowski (Mitgründer von Vectorwise) gegründet. Mit der Vision, ein analytisches Datenbanksystem (Data Warehouse/OLAP-System) von der Pike aus ausschliesslich für die Cloud zu entwickeln. Die Nutzer sollten sich um nichts anderes als ihre Use-Cases sorgen müssen, weshalb Snowflake als SaaS-Plattform aufgesetzt wurde. Es sollte sich niemand bzgl. Hardware, Updates/Patches oder sonstige Betriebs-Themen kümmern müssen, „It just works“ war das Ziel.
 
Probleme, die Wettbewerbern und deren Kunden schlaflose Nächte bereiteten, sollten auf einen Schlag ausgemerzt werden. War nämlich z.B. die Rechenkapazität eines damaligen Systems (z.B. Teradata oder Netezza) am Limit, musste man neue Hardware samt Storage kaufen, obwohl die zusätzliche Speicherkapazität gar nicht gebraucht wurde, sondern eigentlich nur mehr Rechenleistung benötigt wurde. (Oder eben umgekehrt.)
 
Dies führt zu unnötig hohen Kosten für Hardware und Betriebspersonal und ist insgesamt nicht sonderlich flexibel und bei Bedarf anpassbar. In den Cloud-Plattformen der Hyperscaler (AWS, Azure, GCP) können Ressourcen bei Bedarf in Sekunden schnelle bereitgestellt werden und sind in beinahe unerschöpflichem Ausmass vorhanden. Und genau diese Eigenschaften macht sich Snowflake mit seiner Architektur zunutze:
 
Wie auf der vorherigen Abbildung ersichtlich ist, teilt sich Snowflake von unten nach oben in drei Layer ein:
  1. Storage Layer,
  2. Compute Layer und
  3. Cloud Services Layer.

Im Storage Layer werden die Daten gespeichert, die in Snowflake geladen werden. Hierfür dient der Object Store des Cloud Providers, auf dem der Snowflake-Account gehostet wird (S3 bei AWS, Azure Blob Storage und GCP Cloud Storage). Damit macht sich Snowflake die ungeschlagene Verfügbarkeit und Skalierbarkeit dieser Technologien zunutze, woran man erkennt, dass Snowflake ohne Kompromisse für die Cloud entwickelt wurde. Für Storage in Snowflake wird ein fixer Betrag pro TB pro Monat angesetzt. Der Betrag ist abhängig davon, von dem Cloud-Provider auf dem Snowflake gehostet wird und dessen Region/Data Center.
 
Der Compute Layer stellt eine flexible Möglichkeit zur Verfügung, Rechenkapazitäten für die Datenverarbeitung bereitzustellen und zu managen. Snowflake nutzt hierzu das Konzept eines sogenannten Virtual Warehouses. Dies sind Rechenkapazitäten (VMs), die flexibel abgerufen und wieder dekommissioniert werden können. Die Grösse und damit die Leistung eines Virtual Warehouses werden in Snowflake mit T-Shirt Sizes beschrieben von XS bis 6XL, also zehn verschiedene Grössen.
 
Man bezahlt für die Zeit, in der ein Virtual Warehouse aktiv ist. Ein XS-Warehouse (die kleinste Grösse) verbraucht einen Credit pro Stunde, in der das Virtual Warehouse aktiv ist. Jede Stufe verdoppelt die Kapazität und damit im selben Verhältnis den Credit-Verbrauch. Der Preis eines Credits ist vom Hyperscaler, dessen Region und der Snowflake-Edition abhängig:
 
So kostet in diesem Beispiel ein Credit in der Enterprise Snowflake Edition im GCP Data Center in Frankfurt 3,90 USD.
 
Für die Virtual Warehouses können sehr flexible Konfigurationen vorgenommen werden, sodass sich diese z.B. nach einer gewissen Zeit, in der sie nicht benötigt werden, automatisch abschalten und wenn dann wieder Bedarf auf das System zukommt, werden sie wieder automatisch hochgefahren. Also besteht in Snowflake bzgl. der Rechenkapazität (Compute) maximale Flexibilität und Ressourcen-Elastizität.
 
Der Cloud Services Layer ist eine sogenannte Multi-Tenant-Applikation, die das Management aller administrativen Aufgaben für alle Kunden von Snowflake übernimmt. Hierzu zählen v.a. das Metadata- und Access-Management sowie automatisiertes Performance-Tuning.
 

2. Wie hat sich Snowflake seit der Gründung entwickelt?

In der Vergangenheit bzw. zum Start von Snowflake war das System primär als Data Warehouse bzw. Datenbanksystem angedacht und dies ist heute ebenfalls noch so. So fällt in der Nutzung mit Snowflake sofort auf, dass als primäre Interaktionsmöglichkeit SQL-Abfragen/-Statements angedacht sind. In Snowflake lässt sich nämlich alles über SQL managen, von der Anlage von Usern und Berechtigungen über das Laden und die Prozessierung von Daten bis hin zum Deployment von autoskalierenden Web-Applikationen. Ein weiterer Aspekt, der Snowflake von Anfang an ausgemacht hat, ist die bereits angesprochene Trennung von Storage und Compute, sodass beides unabhängig voneinander skaliert werden kann. Deshalb wird das Billing in Snowflake auch bezogen auf diese beiden Grössen getrennt voneinander gehandhabt. Über die Jahre wurden zu den Kern-Features noch zusätzliche Fähigkeiten und Funktionalitäten hinzugefügt. Allen voran in der jüngsten Vergangenheit wurden mannigfaltige AI-Features mit Snowflake Cortex AI und Snowflake Intelligence, welche Large Language Models (LLMs) und AI Agents in die Plattform integrieren. Hierauf wird stark gesetzt, weshalb Snowflake auch ein Rebranding zu Snowflake AI Data Cloud erfahren hat.
 

3. Wie passen nun Snowflake und SAP Business Data Cloud zusammen?

Im Zuge von SAP BDC Connect wurde nun auch eine Kooperation bzw. Kompatibilität von Zero-Copy-Data-Sharing zu Snowflake angekündigt. Hierdurch erhalten Snowflake-Bestandskunden die Möglichkeit, über SAP BDC Connect bidirektional SAP Data Products zu nutzen und auch zur Verfügung zu stellen. Hierfür muss SAP BDC Connect für den Snowflake-Account konfiguriert und gemanagt werden.
 
Aber es gibt auch die Möglichkeit, Snowflake als von SAP gemanagte Solution Extension zu nutzen, SAP Snowflake. Dies ist vergleichbar mit SAP Databricks, allerdings gibt es auch Unterschiede. Während SAP Databricks deutlich weniger Funktionsumfang bietet als Native Databricks, muss bei SAP Snowflake auf deutlich weniger Features verzichtet werden. Zum Verfassungszeitpunkt war bisher nicht bekannt, dass auf signifikante Snowflake-Features verzichtet werden muss.
 

4. Was ist der Vorteil von SAP Snowflake?

SAP Snowflake ist gänzlich ins SAP-Ökosystem eingebettet, weshalb SAP auch zum primären Support-Partner wird. Ausserdem ist SAP Snowflake nach der Provisionierung direkt fähig SAP Data Products zu konsumieren und bereitzustellen, ohne ein umfangreiches Setup von SAP BDC Connect. Durch die Einbettung ins SAP-Ökosystem sind auch Security- und Governance-Themen wie User-Management, Konnektivität etc. leichter zu managen.
 
Weiterhin bestehen auch keine lizenz-technischen Einschränkungen für die Nutzung von SAP Data Products innerhalb von SAP Snowflake, während bei Native Snowflake wie auch bei anderen SAP BDC Connect Plattformen hierbei einige Einschränkungen gelten. Hinsichtlich Lizenz- bzw. Abrechnungs-Modell ist SAP Snowflake recht simpel. Es wird nicht per SAP Capacity Units (CUs), sondern in Form zweier gesonderter SKUs abgerechnet, nämlich analog zu Native Snowflake über Compute und Storage.
 

5. Wie gestaltet sich die Kostenstruktur für Zero-Copy-Data-Sharing?

Unabhängig davon, ob SAP Data Products über Native oder über SAP Snowflake genutzt werden, fallen in beiden Fällen – zusätzlich zum plattformeigenen Ressourcenverbrauch – Infrastructure Fees an.

Diese Fees entstehen, weil die Nutzung der SAP Data Products auf dem zugrunde liegenden Cloud-Provider Kosten verursacht – vor allem für I/O-Workloads im Object Store (Daten speichern, lesen, übertragen).

Exkurs: Wie werden SAP Data Products und Snowflake Tables gespeichert?

SAP Data Products werden als Delta-Lake-Tabellen im Object Store des Cloud-Providers abgelegt. Ein hilfreicher Hintergrundartikel dazu ist: https://delta.io/blog/delta-lake-vs-parquet-comparison/
Kurz gesagt: Eine Tabelle liegt nicht als „eine Datei“ vor, sondern ist in viele einzelne Dateien (Data Files) aufgeteilt, die jeweils nur einen Teil der Tabellendaten enthalten. Metadaten (z. B. welche Dateien zu welcher Tabelle gehören und wie sie optimal gelesen werden) werden separat verwaltet.

Die Speicherung in Snowflake ist im Prinzip sehr ähnlich: Auch dort werden Daten im Hintergrund in Files + Metadaten organisiert.

Warum entstehen dadurch zusätzliche Kosten?

Jeder Zugriff auf den Object Store – also ein API-Call / Processing Request, um ein File zu lesen – verursacht Kosten beim Hyperscaler, die entsprechend weiterverrechnet werden.

Diese Kosten sind meistens geringer, wenn die konsumierende Anwendung in derselben Cloud-Region arbeitet. Sobald Daten jedoch Regionsgrenzen überschreiten (oder das Data Center verlassen müssen), können die Transferkosten deutlich steigen.

Woraus setzen sich die Infrastructure Fees zusammen?

Die Infrastructure Fees bestehen typischerweise aus zwei Komponenten:

  1. Inter-Region Data Transfer Fee
    Für SAP-Data-Product-Daten, die das BDC Data Center verlassen müssen.

  2. Processing Requests
    Für API-Calls an den Object Store (z. B. Lesen von Dateien/Objekten).

Zusätzliche Gebühren bei Nutzung über Native Snowflake / BDC Connect

Wenn SAP Data Products über Native Snowflake und BDC Connect genutzt werden, kommen zusätzlich zu:

  • Infrastructure Fees und
  • den regulären Snowflake-Kosten

auch Premium Fees hinzu.

Dabei misst Snowflake die Compute-Workloads, die innerhalb der Snowflake-Plattform bei der Verarbeitung von SAP Data Products anfallen, und übermittelt diese Werte regelmäßig an SAP. SAP berechnet darauf einen Uplift, und die Abrechnung erfolgt anschließend in Form von CUs (Consumption Units) über SAP BDC Connect.

6. Fazit: architektonische Eleganz vs. kommerzielle Realität

Die strategische Öffnung der SAP Business Data Cloud hin zur Snowflake AI Data Cloud markiert einen Wendepunkt im modernen Datenmanagement. Durch das native Zero-Copy-Data-Sharing wird das klassische, fehleranfällige und wartungsintensive ETL-Paradigma für SAP-Daten endgültig aufgebrochen. Daten stehen ohne Replikationsaufwand plattformübergreifend zur Verfügung. Für Unternehmen stellt sich bei der Implementierung primär die Frage nach dem passenden Betriebs- und Lizenzmodell:

  • Native Snowflake mit BDC Connect bietet maximale Unabhängigkeit im bestehenden Cloud-Setup, verlangt Architekten jedoch ein genaues Monitoring der Lizenzrestriktionen sowie der durch SAP erhobenen Premium-Fees (Uplift auf Compute-Workloads via CUs) ab.
  • SAP Snowflake (Solution Extension) punktet als gänzlich eingebettete Lösung mit direktem SAP-Support, wegfallenden Setup-Hürden und einer unkomplizierten, rein ressourcenbasierten Abrechnung über dedizierte SKUs – ohne Lizenz-Einschränkungen bei der Nutzung von SAP Data Products.
Am Ende entscheidet jedoch nicht nur die vertragliche Ausgestaltung über den wirtschaftlichen Erfolg, sondern die physische Cloud-Topologie. Da die Datenbereitstellung auf API-Calls gegen Object Stores (Delta Lake Format) basiert, bleibt die Platzierung von Snowflake- und BDC-Instanzen in derselben Hyperscaler-Region der wichtigste Hebel, um die Infrastructure-Fees (insbesondere Inter-Region Data Transfers) minimal zu halten. Wer diese Aspekte berücksichtigt, erhält eine hochmoderne Datenarchitektur, die geschäftskritische SAP-Semantik nahtlos mit der Skalierbarkeit und den KI-Fähigkeiten von Snowflake verknüpft.
 


Sie möchten die Kostenlogik rund um Zero-Copy Data Sharing, Infrastructure Fees und Premium Fees im Detail verstehen – und wissen, was das konkret für Ihren Use Case bedeutet? Dann kontaktieren Sie uns hier!

Published by:

Tobias Vogler

autor:IN

Wie hat Ihnen der Artikel gefallen?

Wie hilfreich war dieser Beitrag?

Klicken Sie auf einen Stern, um zu bewerten!

Durchschnittliche Bewertung 0 / 5.
Anzahl Bewertungen: 0

Bislang keine Stimmen! Seien Sie die erste Person, die diesen Beitrag bewertet!

INFORMATIONEN

Weitere Informationen

Sapphire Opinion Piece Header with Michael May

Sapphire 2026: Von Reporting und Planning zu Directing

Die Sapphire Announcements 2026 habenordentlich Wellen geschlagen, aber was bedeutet es wirklich für Unternehmen? Während die meisten Kommentatoren über...

Die Raumstation: Medallion-Architektur als Herzstück der Lakehouse-Mission

Wie funktioniert das in der Datasharing mit SAP und Databricks? Die strategische Partnerschaft zwischen SAP und Databricks ermöglicht eine...

Mission Control: Die Architektur des Databricks Unity Catalog im modernen Enterprise-Datennetzwerk

Wie funktioniert das in der Datasharing mit SAP und Databricks? Die strategische Partnerschaft zwischen SAP und Databricks ermöglicht eine...

BDC Connect: Der direkte Draht zu Databricks, Snowflake und Co.

Die Integration von SAP-Daten in moderne Cloud-Plattformen wie Databricks oder Snowflake gleicht oft einem Hürdenlauf: Komplexe ETL-Prozesse, kostspielige Datenkopien...

Was ist SAP S/4HANA?

SAP S/4HANA ist mehr als ein technisches Upgrade – es ist eine grundlegende Systemtransformation. In diesem Artikel erfahren Sie,...

AI meets BI: Modernes Reporting im Databricks Lakehouse

In der traditionellen IT-Welt existieren oft zwei getrennte Universen: Die Business Intelligence (BI), die sich mit der Analyse historischer...
Symbolbild für Datenformate in Databricks. Ein Icon stellt den schichtweisen Aufbau von Parquet-Dateien mit einer darüberliegenden Delta-Lake-Schicht dar.

Der richtige Treibstoff: Die Evolution der Tabellenformate im Lakehouse

Die Auswahl des richtigen Datenformats ist ein kritischer, aber oft unterschätzter Faktor für die Performance und Effizienz in Databricks....