In Teil 1 unserer Serie über Cloud-Data-Warehouse-Preise haben wir die wichtigsten Berechnungs- und Preisvariablen für BigQuery, Redshift und Snowflake verglichen und zusammengefasst. Besuchen Sie diesen ersten Blog der Serie erneut, um die detaillierte vergleichende Übersichtstabelle anzuzeigen.
In Teil 2 beginnen wir mit der Betrachtung hypothetischer Szenarien, die einen Leitfaden für das Verständnis von Preisoperationen bieten. Wir sind eine agnostische iPaaS-Lösung, die Datenflüsse zwischen lokalen Anwendungen und Daten, SaaS-Anwendungen in der Cloud und einer Vielzahl von Cloud-Data-Warehouses miteinander verbindet und orchestriert.
Im Folgenden wird ein hypothetisches Setup vorgestellt, das ein gängiges On-Demand-Compute-Szenario umfasst, das zur Veranschaulichung der grundlegenden Preisunterschiede zwischen Cloud Data Warehouses nützlich sein kann. Künftige Blogs werden weitere, fortgeschrittenere Preisszenarien behandeln.
Hypothetisches On-Demand-Szenario - BigQuery vs. Redshift vs. Snowflake Preisgestaltung
Anstelle einer Mindestkonfiguration, die zu irreführenden Vergleichen führen würde, gehen wir von einer hypothetischen Konfiguration aus, die typisch für große Datenabfragen auf Abruf ist - ein idealer Anwendungsfall für cloudbasierte Abfragetools. Heutzutage, wo Unternehmen mit Daten überschwemmt werden, ist es selbst bei On-Demand- oder explorativen Abfragen nicht ungewöhnlich, dass Unternehmen eine bestimmte maximale Antwortzeit für große Datensätze benötigen.
In unserem hypothetischen Szenario haben wir also drei verschiedene rechenintensive Abfragen. Jede Abfrage muss innerhalb von 30 Sekunden (oder weniger) ein Ergebnis liefern und einen gesamten Datensatz von einem halben Terabyte (500 GB) durchsuchen, um das Abfrageergebnis zu erhalten. Die Daten stammen aus einem lokalen System of Record und werden über das jeweilige SnapLogic Snap Pack - für BigQuery, Redshift oder Snowflake- in das Cloud Data Warehouse geladen. In diesem Szenario werden die Abfragen sporadisch über einen Monat hinweg ausgeführt - also nicht in einer ständig laufenden 24×7-Umgebung, die in einem anderen hypothetischen Szenario untersucht wird.
Zur Veranschaulichung der Preisunterschiede gehen wir davon aus, dass die folgenden Cloud-Data-Warehouse-Größen erforderlich sind, um die geforderte maximale Antwortzeit von 30 Sekunden zu erreichen (es wird davon ausgegangen, dass kleinere Konfigurationen zu langsameren, inakzeptablen Ergebnissen führen würden):
- BigQuery: 2.000 Slots, nach Bedarf oder mit flexibler Preisgestaltung
- Redshift: 8 Knoten x dc2.8xlarge oder 5 Knoten von ra3.xlarge, nach Bedarf
- Schneeflocke: Standard Edition in der Größe X-Large, auf Anfrage
Unterschiede in der Preisgestaltung
Google BigQuery
Verwenden Sie den BigQuery-Snap in Ihrer SnapLogic-Pipeline, um Daten zu BigQuery zu übertragen. Dort beträgt der Preis für die Ausführung einer der 30-Sekunden-Abfragen bei On-Demand-Preisen 2,50 US-Dollar (,5 * 1 TB * 5 US-Dollar pro gescanntem TB). Führen Sie die Abfragen aus, wenn - im Stapel oder unabhängig voneinander. Unabhängig davon zahlen Sie immer 2,50 $ pro Abfrage, da pro Abfrage ein halbes Terabyte an Daten gescannt wird.
Bei der flexiblen Preisgestaltung von BigQuery betragen die Kosten 80 $ pro Stunde für 2.000 Slots (4 $ pro Stunde für 100 Slots * 20). Da eine 30-Sekunden-Abfrage alle 2.000 Slots verbraucht, zahlen Sie bei sporadischen Abfragen immer die 60-Sekunden-Mindestgebühr, d. h. 1,34 $ pro Abfrage (60 Sekunden * (80 $ / 3.600 Sek./Std.)) für jede einzelne Abfrage.
Angesichts des 60-Sekunden-Minimums sind Sie daher motiviert, die Abfragen nach Möglichkeit zu bündeln und auf ein gewisses Maß an Gleichzeitigkeit zu hoffen, wobei Sie davon ausgehen, dass Sie maximal 90 Sekunden für die Ausführung aller drei Abfragen zu Kosten von 2 $ (90 * 80 $ / 3.600 (Sek./Std.)) bezahlen werden.
Beachten Sie jedoch, dass es sich bei der flexiblen Preisgestaltung für BigQuery um eine Spot-Preisgestaltung handelt und nicht garantiert werden kann, dass die Slot-Ressourcen zum Zeitpunkt Ihrer Abfrage verfügbar sind. Darüber hinaus läuft der Zähler weiter, bis Sie die Slot-Ressourcen stornieren. Daher können Ihre tatsächlichen Rechenkosten höher sein als die oben genannten Schätzungen für BigQuery-Flexpreise.
Da die Daten von einer externen Quelle stammen, müssen Sie auch für den Google Cloud-Speicher bezahlen, der ca. 9,80 $ pro Monat (500 GB - 10 GB (kostenlos))/1.000 GB * 20 $) beträgt, was anteilig berechnet werden kann, wenn die Daten nicht für einen ganzen Monat genutzt werden.
Bei diesem Rechenszenario ist der Pauschalpreis für BigQuery, der die Abhängigkeit von der Menge der gescannten Daten aufhebt, möglicherweise keine preislich praktikable Option, da die Abfrageaktivität sporadisch ist und nicht ausreicht, um BigQuery so auszulasten, dass der Pauschalpreis von 40.000 US-Dollar pro Monat (20 * 2.000 US-Dollar pro Monat für 100 Slots) gerechtfertigt ist.
Redshift
Dank der relativ neuen Funktionen zum Anhalten und Fortsetzen haben Sie bei der Verwendung von Redshift on-demand jetzt eine bessere Kontrolle über die Redshift-Kosten. Verwenden Sie das Redshift Snap Pack in Ihrer SnapLogic-Pipeline, um Daten nach Redshift zu verschieben. Solange die drei Abfragen innerhalb einer Stunde gebündelt oder einzeln ausgeführt werden, können Sie die Redshift-Kosten niedrig halten. Andernfalls entstehen ohne Pause und Resume bei dc2.8xlarge-Knoten stündliche Kosten von 38,40 $ (8 Knoten * 4,80 $ pro Stunde und Knoten) für die drei Abfragen. Bei ra3-16xgroßen Knoten liegen die Kosten bei 65 $ (5 Knoten * 13,04 $ pro Stunde pro Knoten).
Die Herausforderung in diesem Fall besteht jedoch darin, dass Redshift-Pausen und -Fortsetzungen manuell festgelegt oder geplant werden. Sie müssen im Voraus wissen, wann die Abfragen auf dem Redshift-Cluster ausgeführt werden müssen. Wenn der Redshift-Administrator die Kontrolle darüber hat, kann das Timing von Pause und Wiederaufnahme eng an den Zeitpunkt angepasst werden, an dem die Abfragen ausgeführt werden müssen. Das hält die Kosten niedrig, denn natürlich fallen Kosten an, die unter dem vollen Stundensatz liegen. Hat der Administrator keine Kontrolle über die Zeitsteuerung, steigen die Kosten aufgrund der Leerlaufzeit, wenn der Redshift-Cluster zwar aktiv ist, aber keine Abfrage ausgeführt wird.
Wenn der Redshift-Cluster angehalten wird, müssen Sie weiterhin für den Speicher bezahlen. Für Redshift dc2.8xlarge-Knoten, die 2,56 TB Live-Speicher enthalten, belaufen sich Ihre geschätzten Kosten auf 492 US-Dollar pro Monat für Speicher (8 Knoten * 2,56 TB pro Knoten * 24 TB pro Monat). Die Speicherkosten für Redshift ra3-12xlarge-Knoten werden anders berechnet. Bei ra3-Knoten zahlen Sie nur für den verbrauchten Speicherplatz, d. h. 12 US-Dollar pro Monat (.5 TB * 24 TB pro Monat).
Schneeflocke
Verwenden Sie den Snowflake Snap in Ihrer SnapLogic-Pipeline, um Daten nach Snowflake zu verschieben. Sobald die Daten nach Snowflake verschoben werden, fallen sofort Speichergebühren in Höhe von 40 US-Dollar pro TB pro Monat an, komprimiert. Die typische Datenkomprimierung für Snowflake wird mit ~3:1 angenommen, die tatsächliche Komprimierung kann jedoch variieren. Daher belaufen sich Ihre geschätzten Speichergebühren auf 7 US-Dollar pro Monat (.5 TB / 3 * 40 US-Dollar pro TB pro Monat).
Snowflake hat den Vorteil, dass es automatisch angehalten und fortgesetzt werden kann, so dass es wie eine Abfrage-Engine funktioniert, ähnlich wie BigQuery. Aktivieren Sie das automatische Anhalten und Fortsetzen zum Zeitpunkt der Erstellung eines Snowflake-Warehouses oder zu einem beliebigen Zeitpunkt nach der Erstellung über SQL-Skripte.
Sobald sich das Lager im Leerlauf befindet, wird die automatische Unterbrechung nach einer bestimmten Zeit, die Sie auswählen können, aktiviert. Bei Auswahl aus dem Dropdown-Menü der Snowflake-Konfiguration "Lager erstellen" sind fünf Minuten das Minimum. Dieser Wert kann durch SQL-Skripte noch weiter reduziert werden. Mit "AUTO_SUSPEND = 60" (der Wert ist immer in Sekunden angegeben) wird die Zeit beispielsweise auf 1 Minute verkürzt. Es mag zwar verlockend sein, die Zeit so kurz wie möglich zu halten, um Kosten zu sparen, doch sollten Sie sich darüber im Klaren sein, dass eine zu kurze Suspendierungszeit bei häufigen und sporadischen Abfragen und einer großen Data Warehouse-Größe potenzielle Folgen für den Betrieb des Warehouse haben kann.
Bei Snowflake gibt es eine Mindestberechnungszeit von einer Minute. Wenn die drei hypothetischen Abfragen gleichzeitig ausgeführt werden und alle drei Abfragen innerhalb von 30 Sekunden abgeschlossen sind, belaufen sich die geschätzten Rechenkosten für eine Snowflake-Standard-Edition in einer X-Large-Größe auf $.53 ($2 pro Stunde für den Standardtyp * 16 Credits für die X-Large-Größe / 60 Minuten pro Stunde) + die Kosten für die automatische Wartezeit. Wenn die Wartezeit für die automatische Unterbrechung auf zwei Minuten eingestellt ist, betragen die Kosten für die Wartezeit $1,07 (gerundet) - Dies ergibt Gesamtkosten von 1,60 $ (53 $ + 1,07 $).
Wenn die drei hypothetischen Abfragen nacheinander ausgeführt werden, betragen die Kosten insgesamt 1,87 $ (90 Sekunden Rechenzeit (80 $) + 2 Minuten Wartezeit (1,07 $)).
Insbesondere bei On-Demand-Operationen, wie im Redshift-Beispiel, ist es wichtig, dass die Snowflake-Funktionen zum automatischen Aussetzen und Wiederaufnehmen aktiviert sind. Andernfalls läuft der Zähler, während das Data Warehouse im Leerlauf ist, was zu höheren Kosten als nötig führt.
Vorsicht beim Betrieb auf Abruf
Wie das hypothetische Szenario veranschaulicht, bieten Google BigQuery, Amazon Redshift und Snowflake die Möglichkeit, mit geringen Kosten im On-Off-Betrieb zu arbeiten, was ideal ist, wenn die Abfragelast gering und sporadisch ist. Die vergleichbaren Rechenkosten sind ähnlich. Der On-Off-Betrieb ist der Schlüssel, um ausufernde Kosten zu vermeiden. BigQuery eignet sich am besten für den On-Off-Betrieb, da es Abfragen nur dann ausführt, wenn sie gestellt werden, während Redshift und Snowflake entsprechende Einstellungen erfordern.
Im nächsten Teil dieser Blogserie werden wir uns mit Szenarien für den Dauerbetrieb befassen und Preise vergleichen.
