Cloud Data Warehouse: Was es löst und wo die Grenze als alleinige Plattform liegt
Die Kernaussagen auf einen Blick.
- Ein Cloud Data Warehouse ist ein analytisches Datenbanksystem, das Speicher und Rechenleistung trennt, elastisch skaliert und als verwalteter Dienst läuft.
- Die Cloud vereinfacht Betrieb und Skalierung, die grundlegende SQL-orientierte Architektur des Warehouse bleibt jedoch bestehen.
- Vor der Entscheidung sollte eine zentrale Frage geklärt werden: Bleibt es bei reiner SQL-Analyse, oder greifen später auch Data Science, Streaming und KI auf dieselben Daten zu?
- Mein Vorschlag: Das Cloud Data Warehouse gezielt als leistungsfähige SQL- und BI-Schicht einsetzen und die Lakehouse-Option prüfen, bevor die Datenplattform langfristig an ein proprietäres Format gebunden wird.
Inhaltsverzeichnis
Cloud ist ein Liefermodell, keine Architektur-Entscheidung
Ein Unternehmen migriert sein Data Warehouse in die Cloud und nutzt künftig einen verwalteten Dienst, dessen Kosten sich nach Speicher und Nutzung richten. Betrieb und Skalierung werden dadurch deutlich einfacher. Später kommt das erste produktive Machine-Learning-Projekt hinzu. Für das Modelltraining müssen die Daten zunächst aus dem Warehouse in eine separate Umgebung übertragen werden, mit eigener Kopie und eigener Pflege.
In wachsenden Datenplattformen entsteht diese Situation häufig schrittweise. Aus betrieblicher Sicht war die Modernisierung erfolgreich. An der grundlegenden Architektur hat sich jedoch wenig geändert. Das Warehouse bleibt auf SQL-basierte Analyse ausgerichtet. Andere Workloads benötigen zusätzliche Werkzeuge oder separate Systeme.
Brauchen wir wirklich ein zweites System für Data Science, oder wurde das Warehouse für einen Anwendungsfall eingesetzt, für den eine andere Plattform besser geeignet wäre? Was kostet das Modell, wenn die Abfragelast und die Datenmenge weiter steigen? Wie stark bindet das gewählte Datenformat die Plattform an einen einzelnen Anbieter? Ab wann reicht ein Cloud Data Warehouse nicht mehr aus, weil sich die Anforderungen an die Plattform verändert haben?
Ein Cloud Data Warehouse löst Betriebs- und Skalierungsfragen sehr gut. Es ist jedoch nicht automatisch die passende Grundlage für sämtliche Daten- und KI-Workloads.
Was ist ein Cloud Data Warehouse?
Ein Cloud Data Warehouse ist ein analytisches Datenbanksystem, das strukturierte und teils halbstrukturierte Daten zentral sammelt, um darauf Reporting, Business Intelligence und analytische Auswertungen durchzuführen. Es läuft als verwalteter Dienst beim Cloud-Anbieter, der Hardware, Skalierung und Wartung übernimmt. Der Begriff DWH (Data Warehouse) bezeichnet eine zentrale Plattform für analytische Datenverarbeitung, im Unterschied zur operativen Datenbank, die das Tagesgeschäft bedient.
Der prägende Unterschied zum klassischen Warehouse ist die Trennung von Speicher und Rechenleistung (Storage und Compute). Die Daten werden zentral gespeichert, während die benötigte Rechenleistung unabhängig davon bereitgestellt und bei Bedarf skaliert wird. Unterschiedliche Workloads können auf getrennten Compute-Ressourcen parallel ausgeführt werden. Die Kosten für die Rechenleistung richten sich in der Regel nach der tatsächlichen Nutzung. Snowflake hat diese getrennte Architektur als Produktkern bekannt gemacht und dokumentiert sie als Multi-Cluster-Shared-Data-Architektur.
Dadurch verlagert sich der Schwerpunkt von der langfristigen Hardwareplanung auf die laufende Steuerung der Nutzung. Klassische Warehouse-Systeme mussten häufig bereits bei der Beschaffung auf erwartete Lastspitzen ausgelegt werden. Im Cloud-Modell skaliert die Rechenleistung mit der Last, und es entstehen überwiegend laufende, nutzungsabhängige Kosten; hohe Anfangsinvestitionen entfallen. Unverändert bleibt jedoch die grundlegende Ausrichtung: Das System bleibt primär für SQL-basierte Analyse und Reporting optimiert. Wie sich Warehouse, Lake und Lakehouse als Architekturen voneinander abgrenzen, ordnen wir im Lakehouse-Hub ein.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Wie funktioniert ein Cloud Data Warehouse?
Cloud Data Warehouses nutzen in der Regel spaltenorientierte Speicherung und massiv parallele Verarbeitung. Spaltenorientierte Speicherung heißt, dass die Werte einer Spalte gemeinsam gespeichert werden. Das reduziert bei analytischen Abfragen, die wenige Spalten über viele Millionen Zeilen aggregieren, die Menge der zu lesenden Daten. Massiv parallele Verarbeitung (MPP) verteilt eine Abfrage über viele Rechenknoten. Jeder Rechenknoten verarbeitet einen Teil der Daten; anschließend werden die Ergebnisse zusammengeführt.
Typischerweise laufen Lade-Compute, BI-Compute und Ad-hoc-Compute auf getrennten Clustern über demselben Cloud Object Storage (S3, GCS, Azure Blob mit Parquet/ORC).
Lade-Compute
ELT-Transformation über Fivetran, dbt oder Airbyte.
BI-Compute
Snowflake- oder BigQuery-Warehouses für Reporting und Analyse.
Ad-hoc-Compute
Data-Science-Sandbox für explorative Auswertungen.
Die Data-Warehouse-Architektur folgt in der Regel einem dimensionalen Modell, etwa einem Star Schema, in dem Faktentabellen von beschreibenden Dimensionen umgeben sind. Die Daten werden über ETL- (erst transformieren, dann laden) oder ELT-Prozesse (erst laden, dann im Warehouse transformieren) in das Warehouse geladen. Im Cloud-Umfeld wird häufig ELT eingesetzt, da Transformationen direkt mit der Rechenleistung des Warehouse ausgeführt werden können.
Für Betrieb und Kostensteuerung ist insbesondere die elastische Skalierung relevant. Die Rechenleistung kann bei Bedarf erhöht und bei geringer Nutzung reduziert oder angehalten werden. Dadurch werden die Kosten flexibel, aber zugleich stärker nutzungsabhängig. Überdimensionierte Compute-Ressourcen oder ineffiziente Abfragen erhöhen unmittelbar die laufenden Kosten.
Was die Cloud löst und was sie nicht ändert
Der Wechsel zu einem Cloud Data Warehouse löst mehrere betriebliche Probleme zuverlässig.
Weniger Kapazitätsplanung
Die Kapazität skaliert mit dem Bedarf. Die Kosten verlagern sich von einmaligen Investitionen zu laufenden Ausgaben.
Getrennte Workloads
Reporting, Ad-hoc-Analysen und Ladestrecken laufen auf getrennten Rechenklassen und damit häufiger parallel.
Weniger operativer Aufwand
Patches, Backups, Verfügbarkeit und Skalierung liegen beim Anbieter samt vertraglicher SLAs. Das Team konzentriert sich auf Datenmodelle und Analysen.
Für viele Unternehmen ist das eine deutliche betriebliche Verbesserung und für klassische Reporting-Landschaften genau die richtige Modernisierung. Diese Vorteile betreffen jedoch in erster Linie Betrieb und Bereitstellung. Die grundlegende Warehouse-Architektur verändert sich dadurch nicht automatisch. Die Daten werden häufig in einem anbieterspezifischen Format gespeichert, das besonders eng mit der jeweiligen Engine verbunden ist. Der primäre Zugriff erfolgt über SQL. Andere Workloads wie Machine Learning, Streaming-Verarbeitung oder KI auf Rohdaten benötigen häufig zusätzliche Schnittstellen, Exporte oder separate Datenkopien.
Die Modernisierung in die Cloud beantwortet damit die Betriebsfrage, nicht die Architekturfrage. Wer Betriebsmodell und Architektur gleichsetzt, riskiert, spätere Anforderungen an Data Science, Streaming oder KI zu unterschätzen.
Cloud Data Warehouse, Data Lake und Lakehouse: wo die Grenze verläuft
Sobald neben SQL und BI weitere Workloads auf dieselben Daten zugreifen sollen, muss die grundlegende Plattformarchitektur betrachtet werden. Dabei lassen sich drei Ansätze unterscheiden.
Ein Data Lake speichert beliebige Daten, auch unstrukturierte, günstig in offenen Dateiformaten auf Objektspeicher. Er ist flexibel, benötigt für Struktur, Transaktionssicherheit und Governance jedoch zusätzliche Komponenten. Ein Cloud Data Warehouse bietet diese Funktionen bereits integriert, ist dafür aber stärker an SQL-Workloads und die Technologie des Anbieters gebunden. Ein Lakehouse kombiniert offenen Objektspeicher mit Tabellenformaten wie Delta Lake oder Apache Iceberg, die Transaktionen, Governance und strukturierte Abfragen unterstützen.
| Achse | Cloud Data Warehouse | Data Lake | Lakehouse |
|---|---|---|---|
| Datenformat | proprietär, anbieter-gebunden | offen, aber unstrukturiert | offen und strukturiert (Delta, Iceberg) |
| Typische Workloads | SQL, BI, Reporting | Rohdaten-Ablage, Data Science | BI, Data Science, Streaming, KI auf einer Kopie |
| Datenstruktur und Transaktionen | stark, eingebaut | schwach bis keine | stark, über das Tabellenformat |
| Governance | reif, aber im System eingeschlossen | muss zugebaut werden | zentral über einen Katalog möglich |
| Bindung an den Anbieter | hoch | niedrig | niedrig bis mittel |
Besonders relevant ist die Frage nach dem Datenformat. Im Cloud Data Warehouse liegen die Daten in einem Format, das an die Engine des Anbieters gebunden ist. Solange nur Reporting darauf läuft, ist das kein Problem. Sobald ein Data-Science-Team, eine KI-Strecke oder eine Streaming-Pipeline dieselben Daten braucht, müssen Daten häufig in eine zusätzliche Umgebung übertragen werden. Dadurch entstehen zusätzliche Speicherung, weitere Betriebsaufwände und mögliche Inkonsistenzen zwischen den Datenbeständen. Eine Lakehouse-Architektur soll diese zusätzlichen Datenkopien reduzieren. Dazu greifen unterschiedliche Workloads auf einen gemeinsamen Datenbestand in einem offenen Tabellenformat zu. Wie sich Warehouse, Lake und Lakehouse Achse für Achse unterscheiden, führen wir im Vergleich von Warehouse, Lake und Lakehouse aus.
Welche Anbieter es gibt und wohin sich der Markt bewegt
Der Markt für Cloud Data Warehouses wird von mehreren etablierten Plattformanbietern bestimmt. Snowflake gehört zu den Anbietern, die die Trennung von Speicher und Rechenleistung früh als zentrales Architekturprinzip etabliert haben, und ist anbieterneutral über mehrere Clouds verfügbar. Google BigQuery ist tief in die Google Cloud integriert und rechnet standardmäßig nach abgefragtem Datenvolumen ab. Amazon Redshift ist die etablierte Warehouse-Option im AWS-Umfeld. Microsoft bündelt Warehouse-, Lake- und Analysefunktionen zunehmend in Microsoft Fabric.
Wichtiger als die einzelnen Anbieter ist die Entwicklung des Marktes. Unternehmen bewerten zunehmend konkrete Plattformen und weniger isolierte Produktkategorien. Zugleich gewinnen Plattformen an Bedeutung, die Warehouse und offene Daten verbinden. Databricks, ursprünglich aus dem Lakehouse-Lager, baut seine SQL- und BI-Fähigkeiten aus; Snowflake öffnet sich umgekehrt für offene Tabellenformate wie Iceberg. Die funktionalen Grenzen zwischen Warehouse- und Lakehouse-Plattformen werden zunehmend unschärfer.
Für die Auswahl sollte deshalb die benötigte Architektur wichtiger sein als die Positionierung eines einzelnen Anbieters. Welcher Ansatz geeignet ist, hängt wesentlich vom erwarteten Workload-Profil ab. Entscheidend sind die absehbaren Anforderungen an BI, Data Engineering, Streaming, Data Science und KI.
Wann ein Cloud Data Warehouse die richtige Wahl ist
Ein Cloud Data Warehouse bleibt für klar abgegrenzte Analyse- und Reporting-Anforderungen eine geeignete Lösung. Für klar definierte SQL- und BI-Workloads ist es häufig die einfachste und effizienteste Wahl.
Cloud Data Warehouse wählen, wenn
- Die Plattform bedient überwiegend Reporting und Business Intelligence
- Die Daten liegen strukturiert und in stabilen Modellen vor
- Keine umfangreichen ML-, Streaming- oder KI-Workloads auf derselben Datenbasis geplant sind
- Eine bestehende On-Premise-Reporting-Landschaft modernisiert werden soll
Lakehouse-Architektur prüfen, wenn
- Data Science, KI oder Streaming absehbar auf dieselbe Datenbasis zugreifen sollen
- Mehrere Workload-Typen dieselbe Datenkopie nutzen sollen
- Ein reines Warehouse eine zusätzliche Plattform und weitere Datenkopien erfordern würde
Ein typischer Anwendungsfall findet sich beispielsweise im Handel. Ein Unternehmen mit Filialnetz fährt sein Umsatz-, Bestands- und Warenkorb-Reporting auf strukturierten Daten aus Kassensystemen und Warenwirtschaft. Die Datenmodelle sind stabil, die Analyseanforderungen wiederkehrend, die Workloads bestehen überwiegend aus SQL-basierten Auswertungen. Hier liefert ein solches System genau die richtige Mischung aus Abfrage-Performance, eingebauter Governance und schlankem Betrieb. Sobald dasselbe Unternehmen aber Absatzprognosen oder eine Empfehlungslogik auf Roh- und Verhaltensdaten bauen will, beginnt das Herauskopieren in eine zweite Umgebung, und die bestehende Architektur unterstützt diese zusätzlichen Anforderungen dann nur noch eingeschränkt.
Dann gehört das Cloud Data Warehouse als eine Schicht in die Plattform, und die grundlegende Architektur sollte vor der Auswahl eines konkreten Produkts festgelegt werden.
Was das Cloud Data Warehouse nicht zeigt
Ein Cloud Data Warehouse beantwortet die Frage „Wie betreiben wir SQL-Analyse skalierbar?“ gut. Andere Fragen rund um offene Speicherung, Machine Learning und Streaming werden dadurch jedoch nicht beantwortet. Mit zunehmenden ML- und KI-Anforderungen gewinnen diese Aspekte an Bedeutung.
- Wer Rohdaten und unstrukturierte Quellen offen ablegen will, ohne sie unmittelbar in ein festes relationales Modell überführen zu müssen, kommt schnell zum Data Lake und seinen Stärken und Lücken.
- Transaktionssicherheit und Zeitreisen auf offenem Speicher liefern offene Tabellenformate wie Delta Lake, die genau diese Funktionen auf offenem Objektspeicher ermöglichen.
- Den klassischen Warehouse-Begriff im heutigen Cloud-Kontext ordnet das moderne Data Warehouse ein.
Ein Cloud Data Warehouse deckt damit einen klar abgegrenzten Teil der Datenarchitektur ab. Es verarbeitet SQL- und BI-Workloads zuverlässig; die Frage, ob es zugleich als zentrale Grundlage für weitere Daten- und KI-Workloads dienen kann, beantwortet es nicht selbst.
Grenzen
Ein Cloud Data Warehouse bietet eine klare und leistungsfähige Grundlage für strukturierte Analysen und reduziert den Aufwand für Infrastruktur und technischen Betrieb. Für eine Plattform, die zusätzlich Data Science, Streaming oder KI unterstützen soll, reicht diese Sicht allein jedoch nicht aus.
Bindung an ein proprietäres Format
Die Tabellen liegen in einem Format, das die Engine des Anbieters effizient liest. Wechsel oder Parallelnutzung bedeuten Export, Konvertierung oder eine zweite Kopie. Diese Abhängigkeit sollte vor der Plattformentscheidung bewertet werden.
Zugeschnitten auf SQL-Workloads
Machine Learning, Streaming-Verarbeitung und KI auf Rohdaten laufen außerhalb des Warehouse oder über eine herauskopierte Kopie. Mit zunehmenden Anforderungen außerhalb von SQL steigt der Bedarf an zusätzlichen Systemen und Datenkopien.
Kosten brauchen aktive Steuerung
Pay-per-use senkt die Einstiegshürde, verschiebt die Kostenkontrolle aber in den laufenden Betrieb. Zu groß gewählte Rechenklassen, unkontrollierte Abfragen und schlecht modellierte Tabellen treiben die Rechnung, wenn niemand sie überwacht.
Löst keine Governance-Lücke von selbst
Integrierte Berechtigungen gelten zunächst nur innerhalb des Systems. Sobald Daten in andere Systeme fließen, braucht es ein übergreifendes Governance-Modell, etwa über einen zentralen Katalog wie Unity Catalog.
Das Warehouse ist eine geeignete Lösung, solange das Workload-Profil überwiegend aus SQL und BI besteht. Sobald Data Science, Streaming und KI auf dieselben Daten greifen sollen, muss die zugrunde liegende Plattformarchitektur neu bewertet werden. Dann sollte geprüft werden, ob eine Lakehouse-Architektur oder eine kombinierte Plattform besser geeignet ist.
Fazit
Ein Cloud Data Warehouse eignet sich für SQL- und BI-Workloads, wird aber zur Grenze, sobald Data Science, Streaming oder KI auf dieselben Daten zugreifen sollen.
Ein Cloud Data Warehouse ist besonders geeignet, wenn die Plattform hauptsächlich strukturierte SQL-Analysen und Business-Intelligence-Workloads unterstützt und der Betrieb ohne Infrastruktur-Aufwand laufen muss. Das gilt vor allem für Teams, die eine bestehende Reporting-Landschaft modernisieren, klare Datenmodelle haben und mittelfristig keine umfangreichen ML- oder Streaming-Anforderungen erwarten.
Geeignete Einsatzszenarien sind insbesondere:
- eine Reporting-Plattform mit stabilen Kennzahlen und strukturierten Quellen
- ein Team, das den Betrieb verschlanken will, ohne die Architektur umzubauen
- eine Landschaft, in der SQL und BI auch künftig die wesentlichen Workloads darstellen
Steht dagegen absehbar Data Science, Streaming und KI auf derselben Datenbasis an, reicht ein reines Cloud Data Warehouse als zentrale Plattformgrundlage häufig nicht aus. Dann sollte insbesondere das zugrunde liegende Datenfundament bewertet werden. Ein offenes Tabellenformat kann den Bedarf an zusätzlichen Datenkopien und separaten Plattformen reduzieren.
Mein Vorschlag: Das Cloud Data Warehouse gezielt für seine Stärken in SQL und Business Intelligence einsetzen. Vor der Entscheidung die erwarteten Workloads der kommenden Jahre systematisch bewerten und dabei auch eine Lakehouse-Architektur als Alternative oder Ergänzung prüfen. Die Wahl des Cloud-Betriebsmodells ist meist einfacher als die Entscheidung über die langfristige Plattformarchitektur.
Die erwarteten Workloads der kommenden Jahre systematisch bewerten, bevor die Cloud-Data-Warehouse- oder Lakehouse-Entscheidung final getroffen wird.
Cloud Data Warehouse oder Lakehouse: was passt zu euch?
Das lässt sich in einem ersten Data & AI Assessment gut einordnen.
- welche eurer Workloads echte Kandidaten für ein Warehouse sind und welche eine offene Plattform brauchen
- welche Governance-, Kosten- und Lock-in-Risiken vor der Festlegung auf ein Format geprüft werden müssen
- welcher Architektur- und Migrationspfad für eure Ausgangslage trägt
FAQ
Ein Cloud Data Warehouse ist ein analytisches Datenbanksystem, das strukturierte Daten zentral für Reporting und Business Intelligence sammelt und als verwalteter Dienst in der Cloud läuft. Kennzeichnend ist die Trennung von Speicher und Rechenleistung: Die Daten liegen in günstigem Objektspeicher, die Abfrage-Engine skaliert unabhängig davon und kostet nur, solange sie arbeitet.
