Foto von Rob Wicks auf Unsplash
Vorwort
Mit den BigQuery Editions kamen für Kunden neue Preismodelle und spürbare Änderungen an den bestehenden Modellen.
Bei DoiT unterstützen wir zahlreiche Kunden dabei, ihre Systeme sauber zu architektieren, Cloud-Dienste effizient zu nutzen und Kosten zu optimieren. Im Zuge der BigQuery-Änderungen kamen viele Kunden mit dem Wunsch auf uns zu, Compute-Kosten zu senken, und prüften den Wechsel von ‚On-Demand‘ zum neuen Preismodell ‚Standard Edition‘.
Im Folgenden zeigen wir Schritt für Schritt, wie Sie beurteilen, ob sich ein Wechsel kostenseitig lohnt, und wie Sie ihn durchführen und überwachen.
Der im Beitrag verwendete SQL-Code setzt Zugriff auf folgende INFORMATION_SCHEMA-Views voraus: JOBS_BY_PROJECT, JOBS_TIMELINE_BY_PROJECT, RESERVATION_CHANGES_BY_PROJECT.
Voraussetzung für den Tabellenzugriff: roles/bigquery.resourceViewer (auf Projektebene)
Das Herzstück der Standard-Edition-Reservierung
Die Standard Edition ist ein compute-basiertes Angebot (Slot-Stunden) und hebt sich von anderen compute-basierten Preisoptionen dadurch ab, dass sie projektbezogen funktioniert (ähnlich wie On-Demand) und nicht organisationsweit.
Ihr größter Vorteil: Zugriff auf das Autoscaling-Feature zu niedrigen Kosten und ohne jede Verpflichtung: "BigQuery passt Ihre Slots dynamisch an die Zu- oder Abnahme Ihrer Workloads an." (Introduction to slots autoscaling)
Die wichtigsten Unterschiede zwischen On-Demand und Standard Edition:
1. Abrechnungseinheiten: On-Demand rechnet nach gescannten Datenmengen ab, die Standard Edition nach einem Slot/Stunden-Modell.
2. Slot-Verfügbarkeit: Bei On-Demand gelten Slots als "hot" und stehen sofort bereit. In der Standard Edition ermittelt der AutoScaler erst die nötige Slot-Kapazität für Query-Jobs, bevor Slots zugewiesen werden (rund 10 Sekunden Verzögerung) – das wirkt sich auf die Query-Latenz aus.
3. Maximal verfügbare Slots: On-Demand bietet 2.000 Slots, die Standard Edition 1.600 Slots.
\[1\] Checkliste der Standard-Funktionen und -Einschränkungen
Im ersten Schritt prüfen Sie, ob Ihr Projekt mit der Standard Edition kompatibel ist. Sehen Sie sich die unten aufgeführten Features genau an und vergewissern Sie sich, dass Sie Möglichkeiten und Grenzen verstehen:
Einen vollständigen, detaillierten Vergleich finden Sie hier: BigQuery editions features.
\[2\] Workload-Nutzung analysieren
Sind Funktionen und Einschränkungen geprüft, geht es im nächsten Schritt darum, die Kosten abzuschätzen – je nachdem, ob Ihr Projekt eher I/O-lastig oder CPU-lastig (Slot) ist. In der View INFORMATION_SCHEMA.JOBS erhalten Sie diese Daten über total_bytes_billed (I/O) und total_slot_ms (CPU).
Ziel ist es, die Ausgaben für gescannte Daten den geschätzten Ausgaben für die Slot-Nutzung gegenüberzustellen. Die I/O-basierten Kosten lassen sich relativ einfach ermitteln – sie ergeben sich aus der Summe aller Query-Kosten. Die slotbasierte Schätzung fällt dagegen tendenziell zu niedrig aus, weil sie das Verhalten des Autoscalers nicht abbildet (Bucket-Größe von 100 Slots und Downscaling erst nach mindestens einer Minute). Um diese Abweichung auszugleichen, multiplizieren wir die slotbasierte Schätzung mit dem Faktor 1,5.
Die folgende Tabelle vergleicht die monatlichen Kosten und zeigt das Verhältnis der Slot-Kosten zu On-Demand – also die geschätzte Kostenveränderung beim Wechsel von On-Demand zur Standard Edition.
Ein Wert unter 100 deutet auf eine mögliche Kostensenkung hin, ein Wert über 100 auf eine mögliche Kostensteigerung.
Beispiel:
Monatliche Kundenausgaben — On-Demand ist teurer
Monatliche Kundenausgaben — On-Demand ist günstiger
Code zum Erstellen der obigen Tabelle: BigQuery OnDemand vs. SE.sql
Da die Standard Edition weniger Funktionen bietet als die On-Demand-Edition, empfiehlt es sich, bei einem Verhältnis von dauerhaft über 75 % bei On-Demand zu bleiben. Die zu erwartenden Einsparungen wären sonst gering – und Sie würden gleichzeitig auf einige Funktionen verzichten.
\[3\] Konfiguration der maximalen Slots
Die Standard Edition braucht im Grunde nur eine Einstellung: die maximale Slot-Konfiguration als Obergrenze für das AutoScaling.
Wie lässt sich der passende Wert ermitteln?
Eine Universallösung gibt es leider nicht. Der Parameter wird sich nach der Erstkonfiguration in der Regel nachjustieren lassen müssen – abhängig von Ihrem Workload-Muster und davon, wie Sie Kosten und Performance gewichten möchten.
Einen Startwert können Sie zum Beispiel mit dieser Formel berechnen:
Ermitteln Sie das 90. Perzentil der Stunden im gewählten Zeitraum, in denen die Slot-Nutzung 100 überschritten hat (Basis-Setup), und runden Sie auf das nächste Vielfache von 100 auf.
Maximalkonfiguration auf Basis der P90-Stunde im gewählten Zeitraum
Beispiel-Code-Snippet zur Bestimmung der initialen Maximalkonfiguration: BQ SE max configuration.sql
Reservierung anlegen
Eine Schritt-für-Schritt-Anleitung zum Anlegen einer Reservierung finden Sie hier: Get started with reservations.
Wählen Sie Standard Edition, legen Sie ‚max Slots‘ fest und wählen Sie die passende Region oder Multi-Region – sonst funktioniert die Reservierung nicht korrekt.
\[4\] Performance-Monitoring und Kostenbewertung
Auswirkungen auf die Performance
Um die Performance Ihrer Anwendung zu beobachten, erfassen Sie vor der Migration Kennzahlen wie Job-Verarbeitungszeiten und Antwortzeiten von Ad-hoc-Queries und vergleichen Sie diese mit den Werten nach der Migration. Es lohnt sich, BigQuery-Nutzer vorab über die zu erwartenden Änderungen zu informieren und ihr Feedback einzuholen.
Aus Systemsicht können Sie die Performance über die im folgenden Abschnitt beschriebenen Administrative resource charts beurteilen.
Kostenvorteile
Um die Kosteneffizienz zu bewerten, prüfen Sie Ihre Ausgaben über das tägliche Billing-Dashboard. Wählen Sie dort im Billing-Bereich die SKUs Analysis und Standard Edition.
Die folgende Tabelle summiert in einem Ein-Stunden-Intervall die gesamte Slot-Zuteilung sowie die geschätzten Kosten. Damit lassen sich die tatsächlichen Kosten basierend auf den Aktionen des Autoscalers grob berechnen.
Beispiel-Code-Snippet: Standard Edition cost estimation.sql
Geschätzte Kostenverteilung pro Stunde
\[5\] Feinabstimmung
Bei der Feinabstimmung der Standard Edition passen Sie die maximale Slot-Konfiguration an – entweder um die Performance zu verbessern (mehr Slots) oder um Kosten zu senken (weniger Slots). Ziel ist ein ausgewogenes System, in dem Ressourcen weder unter- noch überdimensioniert sind.
Über das Monitoring der Effizienz Ihrer Workloads erkennen Sie, ob das System ausgewogen, unterausgelastet oder überdimensioniert läuft. Das gelingt entweder über die Administrative resource charts oder per direkter Abfrage der INFORMATION_SCHMEA Views.
Administrative resource charts:
BigQuery-Administratoren überwachen damit die Slot-Nutzung ihrer Organisation und die Performance der BigQuery-Jobs im Zeitverlauf. Diese Charts finden Sie im Bereich ‚Monitoring‘ in der BigQuery-Sidebar – mit verschiedenen Ansichten für unterschiedliche Fragestellungen. Eine Einführung in die Funktionen bietet der Leitfaden zu den administrative resource charts.
- Slot-Nutzungsanalyse: Nutzen Sie die P90- oder P99-Metrik, um das Verhältnis zwischen Slot-Nutzung und -Zuteilung (umfasst "baseline + Autoscaled slots") sowie die Dauer für Auf- und Abskalierungen zu untersuchen.
Slot-Nutzung
Das obige Diagramm verwendet Daten aus der RESERVATION_CHANGES_BY_PROJECT``view, die Informationen zu Reservierungsänderungen enthält.
Die folgende Tabelle zeigt die Slot-Zuteilung sowie die Dauer bis zur nächsten Änderung (Auf- oder Abskalierung). Die Metrik 'allocated_slots' steht für die Anzahl der zu einem bestimmten Zeitpunkt zugewiesenen Slots, bis ein neues 'UPDATE' erfolgt; 'Estimated total slots' bezeichnet die Gesamtzuteilung über den Zeitraum.
Beispiel-Code-Snippet: Monitor BQ edition autoscaling.sql
Tatsächliche Slot-Zuteilungen mit Dauer
- Job-Parallelität: Um Engpässe im System zu erkennen, betrachten Sie die Metrik ‚pending jobs‘.
Pending Jobs
- Job-Performance: Behalten Sie Jobs mit hoher Latenz über das 90. Perzentil (P90) im Blick.
Job-Latenz
Zusammenfassung und Empfehlung
Bei stark schwankenden Lastspitzen kann es geeignetere Ansätze geben, die einer genaueren Prüfung bedürfen. Dennoch liefern die hier vorgestellten Werkzeuge wertvolle Erkenntnisse für die Analyse.
Der Wechsel hängt vor allem davon ab, wie Nutzer das jeweilige Projekt einsetzen: I/O-lastig (was ‚On-Demand‘ teurer macht) oder CPU-lastig (was zu höheren Kosten bei der ‚Standard Edition‘ führt).
Google empfiehlt die Standard Edition in erster Linie für Forschungs- und Entwicklungsprojekte: "For instance, the Standard Edition is ideal for ad-hoc, development, and testing workloads."
Da der Begriff ‚Production Workload‘ je nach Kunde unterschiedlich verstanden wird, ziehen manche Kunden die Standard Edition auch für ETL/ELT-Production-Workloads in Betracht. Das ist vertretbar, sofern die Einschränkungen der Edition akzeptabel sind (insbesondere das 99,9-SLA), die Last über die Zeit stabil bleibt und keine Endnutzer wegen der Query-Latenz Bedenken haben.
Jetzt, da Sie das Vorgehen kennen: Probieren Sie es aus – und teilen Sie uns Ihre Erfahrungen mit.