Einleitung
Die Entscheidung für eine Data Warehouse Lösung hat weitreichende Konsequenzen für eine Vielzahl an Stakeholdern. Metriken wie Query-Performance oder monatliche Kosten können zwar in Benchmarks verglichen werden, allerdings sind zumeist andere Argumente viel ausschlaggebender: Welchen Einfluss hat die Wahl der Lösung auf die tägliche Arbeit von Data Engineers, Analysts und Scientists? Wie können Data Owner ihre Daten schützen und teilen? Wie viel Aufwand ist es, bestehende Systeme mit der gewählten Lösung zu integrieren?
Data Warehouses existieren seit den späten 80er Jahren und haben sich seitdem weiterentwickelt. Ihre Grundfunktionalität ist das Halten von großen Datenmengen und das Beantworten von komplexen analytischen Abfragen (Queries). Moderne, cloudbasierte Data Warehouses wie Snowflake, Google BigQuery, Amazon RedShift und Azure Synapse sind Datenplattformen, die mit vielen zusätzlichen Features ausgestattet sein müssen. Nutzer erwarten die Integration mit Data Lakes, Unterstützung für ETL- und ELT-Prozesse, Data Governance, DataOps, Data Sharing und Discovery, Business Intelligence, Machine Learning und vieles weiteres.
BigQuery und Snowflake bieten all das, skalieren automatisch und nahezu unbegrenzt und versprechen eine Performance auf Datensätzen von Gigabytes bis Petabytes. 
Was sind nun die Argumente, die für die eine oder die andere Lösung sprechen?
- Durchschnittliche Performance auf typischen Queries kann interessant sein, aber ob eine komplexe Query ein paar Sekunden länger braucht, sollte nicht ausschlaggebend sein. Jede Lösung hat ihre eigenen Möglichkeiten, Query Performance zu optimieren
- Je nach Nutzung kann es deutliche Unterschiede in den Kosten geben, aber auch hier sind Benchmarks nur begrenzt hilfreich: Viel wichtiger und schwieriger zu messen sind die Auswirkungen auf Betrieb und Weiterentwicklung der Datenplattform. Schlechtes Management von Richtlinien und Reservierungen kann in allen Lösungen zu unerwartet hohen Kosten führen.
Um nun die Entscheidung zu treffen, müssen konkrete Anwendungsfälle, bereits existierende Infrastruktur und Anwendungen sowie persönliche Präferenzen in Betracht gezogen werden. Um dies zu ermöglichen, sollen im Folgenden relevante Unterschiede und Eigenheiten von Snowflake und BigQuery aufgelistet werden.
Getting Started
Manchmal ist es am besten, eine Lösung einfach auszuprobieren, bevor man sich entscheidet. Wie schwierig ist der Einstieg? Wird die Lösung von den Nutzern schnell angenommen und bieten versprochene Features tatsächlich einen praktischen Mehrwert? Beide Lösungen werden als Software-as-a-Service (SaaS) angeboten und sind dementsprechend einfach aufzusetzen.
BigQuery
Google Cloud bietet für neue Accounts ein 90-tägiges Free Trial mit 300$ als Credits an. Zudem gilt die kostenlose Stufe (Free Tier), die monatlich Queries von 1 TB und 10 GB Speicher anbietet.
Um mit BigQuery loszulegen, werden lediglich die entsprechenden Berechtigungen in einem Google Projekt benötigt, darüber hinaus ist keine Konfiguration nötig. In der Cloud Console (im Browser) können Nutzer Daten direkt von lokalen Dateien, Cloud Storage und Google Sheets importieren. Zudem können verschiedene öffentliche Datensätze verwendet werden. [16] Weitere Möglichkeiten, mit BigQuery zu arbeiten, sind das CLI Tool bq und verschiedene Client Libraries von gängigen Programmiersprachen. In beiden Fällen können die normalen Google Cloud Nutzeranmeldeinformationen (User Credentials) genutzt werden. [17]
Snowflake
Snowflake bietet eine 30-tägige Testversion mit 400$ als Credits an. Hier müssen gleich zu Beginn mehrere grundsätzliche Entscheidungen getroffen werden: Welcher Cloud Provider die Infrastruktur hostet (AWS, Azure oder Google), in welcher Region die Ressourcen angelegt werden sollen und welche Edition verwendet werden soll (Standard, Enterprise oder Business Critical). Diese Entscheidungen sind final und haben Auswirkungen auf Kosten und Features. Die gewählte Region limitiert zudem, mit welchen Accounts Daten geteilt werden können.
Daten können in der Browseranwendung Snowsight von lokalen Dateien hochgeladen werden oder auch aus einem Object Storage (Amazon S3, Azure Blob Storage, Google Cloud Storage) importiert werden (ggf. Konfiguration nötig). Zudem können öffentliche Datenbanken im Marketplace gefunden und importiert werden. Für das Abfragen von Daten muss ein Virtual Warehouse gestartet werden (siehe Compute).
Weitere Möglichkeiten, mit Snowflake zu arbeiten, sind das CLI Tool SnowSQL und verschiedene Client Libraries von gängigen Programmiersprachen.
Compute
Neben dem Speichern von Daten ist die Verarbeitung der Hauptkostentreiber eines Data Warehouses. Daher ist es wichtig, zu verstehen, wo Kosten verursacht werden und wie diese reguliert werden können.
BigQuery
In der Grundeinstellung errechnen sich die Compute Kosten, die in BigQuery entstehen anhand der Menge in Queries verarbeiteter Daten. So kosten abgefragte Daten 5$ pro Terabyte. [1] Daraus folgt, dass Queries und Datenmodellierung so gestaltet werden sollten, dass die Menge der abgefragten Daten nicht größer als notwendig ist: Im SELECT sollten nur notwendige Spalten ausgewählt werden. Zudem muss für große Tabellen Partitionierung und Clustering wohl durchdacht sein, sodass mit Hilfe des WHERE-Blocks effizientes Pruning möglich ist (siehe Storage). [2]
Im Regelfall stehen einem Google Cloud Projekt 2000 Slots zur Verfügung, die virtuelle CPUs repräsentieren. Diese werden von allen Queries gemeinsam genutzt und sind nicht garantiert. Das hat zur Folge, dass die Query Performance zu Stoßzeiten schlechter sein kann und nebenläufige Prozesse einander beeinflussen. Alternativ zum standardmäßigen On-Demand Pricing Modell kann das Flat-Rate Pricing (oder eine Kombination aus beiden) genutzt werden. Hier können Slots reserviert und zugewiesen werden. In diesem Fall ergeben sich die Kosten lediglich aus der Reservierung und sind unabhängig von der Query Größe.
Zudem können Queries im Batch Modus ausgeführt werden: In diesem Fall wartet BigQuery auf einen geeigneten Zeitpunkt, sodass andere laufende Prozesse nicht gestört werden. [3] Um Kosten und den übermäßigen Verbrauch von Ressourcen zu regulieren, sollten verschiedene Kontingente und Limits genutzt werden. [4]
Snowflake
Snowflake nutzt Virtual Warehouses, um Queries zu beantworten. Virtual Warehouses sind Compute Cluster, die nach Bedarf (On Demand) gestartet, gestoppt und skaliert werden können. Die entstehenden Kosten bemessen sich schlicht an der Laufzeit und der Größe des Warehouses. Dabei macht es keinen Unterschied, ob das Warehouse genutzt wird. Es können beliebig viele Warehouses erstellt werden, die auf unabhängigen Ressourcen laufen.
Um Kosten minimal zu halten, sollten Virtual Warehouses nicht größer als nötig sein und nicht länger als nötig laufen. Der interne Speicher und die Rechenkapazität skalieren gemeinsam, das heißt, für große und komplexe Queries sollte ein großes Warehouse (scale up) verwendet werden. Werden viele nebenläufige Queries ausgeführt, so kann dies besser mit mehreren Warehouses oder einem elastischen Multi-Cluster Warehouse gelöst werden (scale out). Warehouses können bei Inaktivität automatisch stoppen und bei erneuten Anfragen wieder starten. [5] Weiterhin fallen Kosten durch Metadata Operationen und Serverless Features wie Materialized Views, Snowpipe und Tasks an.
Gerade für den Einstieg sind die Compute Ressourcen von BigQuery einfacher zu managen. Nutzer müssen darauf achten, wie groß die Datensätze sind, die sie abfragen, um unnötige Kosten zu vermeiden. Hier gibt BigQuery im Normalfall eine Schätzung an, bevor die Query ausgeführt wird. Zudem können Limits eingerichtet werden, die verhindern, dass zu teure Queries ausgeführt werden.
Im Fall von Snowflake muss zu Beginn ein wenig herumexperimentiert werden, um herauszufinden, welche Menge an Ressourcen ideal ist. Warehouses werden mit den Standardeinstellungen automatisch nach einer Weile gestoppt, dennoch besteht das Risiko, dass ein unerfahrener Nutzer Kosten verursacht, indem er kleine Queries an große Warehouses stellt. Administratoren können regulieren, ob und welche Warehouses erstellt werden können. In größeren Produktivumgebungen können sich die Kostenmodelle einander annähern: Reservierungen in BigQuery führen dazu, dass die Kosten eher konstant sind. Ebenso wird in Snowflake durch wohldurchdachte Konfigurationen von Auto-suspend, Auto-resume und Elastizität in Kombination mit Reservierungen ein Betrieb geschaffen, in dem nur die Ressourcen gezahlt werden, die auch genutzt werden.
Snowflake bietet hier mehr Möglichkeiten zur Administration, allerdings auch mehr Komplexität und Raum für kostenverursachende Misskonfiguration. In BigQuery kann die Latenz von Queries mitunter mehrere Sekunden betragen. Deshalb ist es für integrierte BI-Anwendungen erforderlich, das zusätzliche Feature BI Engine zu aktivieren. [6, 18] In Snowflake werden gelesene Partitionen im lokalen Speicher des Warehouses zwischengespeichert, sodass weitere Queries auf den gleichen Daten sehr effizient werden. [19]
Storage & Data Modelling
Der benötigte Datenspeicher ist der zweite relevante Kostenpunkt in einem Data Warehouse. Wesentliche Unterschiede bestehen darin, wie die Systeme ihre Daten strukturieren. Dies beeinflusst, wie Nutzer Daten laden und abfragen sollten. Wie bei Datenbanken für analytische Anwendungen (OLAP) üblich, verwenden beide Systeme ein Spaltenformat (column-oriented) zum Speichern der Daten. Das hat zur Folge, dass das Lesen von Daten für Aggregationen effizienter ist, wohingegen SELECT * Operationen vermieden werden sollten. [9]
Partitioning & Clustering
Um die Menge der zu lesenden Daten zu reduzieren, verwenden beide Systeme Pruning auf Partitionen, wenn geeignete Filter in der Query gesetzt sind. Das bedeutet, dass der Optimierer über Metadaten bereits erkennen kann, welche Partitionen er zum Beantworten der Query lesen muss. Ein wesentlicher Unterschied ist, wie Snowflake und BigQuery ihre Daten partitionieren.
BigQuery
In BigQuery muss explizit angegeben werden, auf welchen Spalten die Daten partitioniert werden sollen. Folgende Optionen existieren:
- Zeitstempel oder Datum, möglich nach Stunde, Tag, Monat oder Jahr
- Aufnahmezeit (ingestion time), möglich nach Stunde, Tag, Monat oder Jahr
- Ganzzahlbereiche (integer ranges), Intervallgröße muss definiert werden
Partitionen in BigQuery sollten nicht zu klein sein, eine Größe von mindestens 1 Gigabyte wird empfohlen. Zudem ist die Anzahl von Partitionen pro Tabelle auf 4000 limitiert. Das bedeutet zum Beispiel, dass eine Tabelle, die auf Stunden partitioniert ist, ein halbes Jahr nicht halten kann. Um teure Queries zu vermeiden und Pruning zu erzwingen, können Tabellen konfiguriert werden, sodass ein Partitionsfilter für Queries erforderlich ist. Zudem kann BigQuery im Vorfeld abschätzen, wie viele Bytes bei einer Ausführung gelesen werden.
Ein weiterer Vorteil bei der Verwendung von Partitionen in BigQuery ist, dass Daten auf Partitionsebene gemanagt werden können. So kann zum Beispiel definiert werden, ob Daten automatisch gelöscht werden sollen und Partitionen können überschrieben werden. Für partitionierte Tabellen gelten zusätzlich Kontingente und Limits. Ladeoperationen sollten idealerweise in möglichst wenige verschiedene Partitionen schreiben und die Anzahl an Modifikationen pro Tag pro Partition ist begrenzt.
Clustering kann für zusätzliche Granularität auf bis zu vier Spalten verwendet werden. Der Optimierer kann auch mithilfe geclusterter Spalten Pruning verwenden und somit die Menge gelesener Daten für Queries weiter reduzieren. [3, 4, 20]
Snowflake
Alle Daten, die in Snowflake geladen werden, werden automatisch komprimiert und in einem proprietären Format in sogenannten Mikropartitionen abgelegt. Diese haben eine recht einheitliche Größe (50 bis 500 Megabyte im unkomprimierten Zustand) und sind bis auf Metadaten unveränderlich (immutable). Die Partitionierung wird allein durch die Reihenfolge, in der die Daten geschrieben werden, bestimmt. Anhand der Metadaten ist einsehbar, wie gut oder schlecht die Daten geclustert sind: Für jede Spalte ist in jeder Mikropartition das Minimum und Maximum hinterlegt, sodass effizient und feingranulär Pruning genutzt werden kann. Zudem ist für die Tabelle einsehbar, wie viele Mikropartitionen existieren, und anhand von Metriken wie Clustering-Tiefe, wie gut einzelne Spalten für Pruning geeignet sind.
Es ist möglich, für Tabellen Clustering-Spalten anzugeben. Hierbei ist allerdings empfohlen, darauf zu achten, dass mehrere Bedingungen erfüllt sind, da dies recht teuer ist und die Kosten sonst schnell den Nutzen übersteigen können:
- Die Tabelle sollte sehr viele Mikropartitionen enthalten, typischerweise ist sie mehrere Terabyte groß.
- Ein großer Anteil der Queries sucht nach sehr kleinen Datensätzen oder sortiert Daten anhand von Clustering-Spalten.
- Die Tabelle sollte selten modifiziert werden.
Mikropartitionen und eine große Menge an Metadaten ermöglichen in Snowflake effizienten Datenzugriff. Nutzer müssen sich im Vorfeld selten Gedanken über die interne Struktur der Daten machen. Allerdings kann es gerade beim Laden von vollständigen Datensätzen (Full Load) sinnvoll sein, darauf zu achten, in welcher Reihenfolge die Daten geladen werden – hierüber werden die Mikropartitionen bestimmt.
Im Gegensatz dazu sind Partitionen in BigQuery eher groß und werden häufig vollständig gescannt. Für große Tabellen sollte die richtige Wahl für eine Partitionierung der Daten getroffen werden. Clustering ist für beide Systeme nur für sehr große Datensätze notwendig, wobei in Snowflake zusätzliche Vorbedingungen erfüllt sein sollten, da es ein teurer Prozess ist. Gegebenenfalls müssen hierzu alle Mikropartitionen neu geschrieben werden. Im Unterschied dazu werden Änderungen an Partitionierung und Clustering einer Tabelle in BigQuery nicht auf existierende Daten angewendet.
Pricing
BigQuery rechnet monatlich 20$ pro Terabyte für physische (komprimiert) und 10$ für logische Daten (unkomprimiert) ab. Für Partitionen und Tabellen, die 90 Tage oder länger nicht mehr modifiziert wurden, halbiert sich der Preis. In Snowflake kostet ein Terabyte Speicher, je nach Region, etwa 35 bis 45$ im Monat. Mit reservierter Kapazität kostet der Terabyte etwa 23$.
Data Warehousing
Bisher wurde verglichen, wie Snowflake und BigQuery als Data Warehouse funktionieren. Ein Hauptunterschied ist, dass BigQuery ein grundsätzlich serverloses Modell verwendet und somit Gedanken über physische oder virtuelle Ressourcen selten von Nöten sind. In Snowflake muss Rechenkapazität meist explizit angefordert werden, allerdings ist das genutzte Modell äußerst flexibel und simpel.
Während BigQuery auf eher große Partitionen setzt, die in analytischen Queries dann vollständig gescannt werden, optimiert Snowflake Speicherzugriffe mittels automatisch erstellter Mikropartitionen. Das hat einerseits zur Folge, dass Nutzer einen Blick auf die innere Struktur der Daten behalten sollten, andererseits ermöglicht es Snowflake, diverse Prozesse zu optimieren. So kann Snowflake besser auch für Anwendungen genutzt werden, die nicht nur die typischen analytischen Queries verwenden, beispielsweise mit dem Search Optimization Service. [21] Im zweiten Teil soll betrachtet werden, wie die Integration der beiden Data Warehouses mit weiteren Services und Features funktioniert, sodass eine Data Platform entsteht. Zudem werden einige Case Studies besprochen, anhand derer die Konzepte verdeutlicht werden.
(Autor: Augustin Wilberg)
[1] https://cloud.google.com/bigquery/pricing [2] https://cloud.google.com/bigquery/docs/querying-partitioned-tables [3] https://cloud.google.com/bigquery/docs/running-queries [4] https://cloud.google.com/bigquery/quotas [5] Overview of Warehouses — Snowflake Documentation [6] BQ slow on non-large data sets (~3s initiation time) [67021275] – Visible to Public – Issue Tracker [7] BigQuery-Speicher | Google Cloud [8] Spaltenorientierte Datenbank – Wikipedia [9] https://cloud.google.com/bigquery/docs/partitioned-tables [10] Micro-partitions & Data Clustering — Snowflake Documentation [11] Pricing Guide | Snowflake [12] Snowpark API — Snowflake Documentation [13] Snowflake Ecosystem — Snowflake Documentation [14] Google-provided templates | Cloud Dataflow | Google Cloud [15] Overview of Access Control — Snowflake Documentation [16] BigQuery public datasets | Google Cloud [17] Provide credentials for Application Default Credentials | Authentication | Google Cloud [18] https://cloud.google.com/bigquery/docs/bi-engine-intro [19] Warehouse Considerations — Snowflake Documentation [20] Introduction to partitioned tables | BigQuery | Google Cloud [21] Using the Search Optimization Service — Snowflake Documentation
