Informationen zu Slots
Ein BigQuery-Slot ist eine virtuelle CPU, die von BigQuery zum Ausführen von SQL-Abfragen verwendet wird. Während der Abfrageausführung berechnet BigQuery automatisch je nach Größe und Komplexität der Abfrage, wie viele Slots für eine Abfrage erforderlich sind.
Sie können zwischen einem On-Demand-Preismodell oder einem kapazitätsbasierten Preismodell wählen. Beide verwenden Slots für die Datenverarbeitung. Mit einem kapazitätsbasierten Modell können Sie für eine dedizierte oder automatisch skalierte Abfrageverarbeitungskapazität bezahlen. Das kapazitätsbasierte Modell ermöglicht Ihnen die explizite Kontrolle über Slots und Analysekapazität, während das On-Demand-Modell nicht funktioniert.
Kunden, die das kapazitätsbasierte Preismodell verwenden, wählen explizit aus, wie viele Slots zu reservieren sind. Ihre Abfragen werden innerhalb dieser Kapazität ausgeführt und Sie bezahlen für jede bereitgestellte Sekunde kontinuierlich. Wenn Sie beispielsweise 2.000 BigQuery-Slots erwerben, sind Ihre Abfragen insgesamt zusammen jederzeit auf 2.000 virtuelle CPUs beschränkt. Sie haben diese Kapazität, bis Sie sie löschen, und Sie zahlen für 2.000 Slots, bis Sie sie löschen.
Projekte nach dem On-Demand-Preismodell von BigQuery unterliegen einem Pro-Projekt-Slot-Kontingent mit vorübergehender Burst-Funktion. Die meisten Nutzer des On-Demand-Modells finden die Standard-Slot-Kapazität mehr als ausreichend. Abhängig von der Arbeitslast verbessert der Zugriff auf mehr Slots die Abfrageleistung. Informationen zur Anzahl der von Ihrem Konto genutzten Slots finden Sie unter BigQuery-Monitoring.
Anzahl der zu kaufenden Slots schätzen
BigQuery ist so konzipiert, dass es mit zunehmenden Ressourcen effizient skaliert. Je nach Arbeitslast ist es wahrscheinlich, dass eine inkrementelle Kapazitätssteigerung entsprechende inkrementelle Vorteile mit sich bringt. Die optimale Anzahl Slots hängt also von der gewünschten Leistung, dem Durchsatz und den verwendeten Dienstprogrammen ab.
Sie können mit Referenz- und Autoscaling-Slots experimentieren, um die beste Konfiguration von Slots zu ermitteln. Beispielsweise können Sie Ihre Arbeitslast mit 500 Referenz-Slots, dann mit 1.000, 1.500 und schließlich mit 2.000 testen und die Auswirkungen auf die Leistung beobachten.
Sie können auch die aktuelle Slot-Nutzung Ihrer Projekte sowie den gewählten monatlichen Preis prüfen, den Sie zu zahlen bereit sind. On-Demand-Arbeitslasten haben eine weiche Slot-Obergrenze von 2.000 Slots. Es ist aber wichtig, mithilfe von INFORMATION_SCHEMA.JOBS*-Ansichten, Cloud Logging, der Jobs API oder der BigQuery-Audit-Logs zu prüfen, wie viele Slots tatsächlich von Ihren Projekten verwendet werden. Weitere Informationen finden Sie unter Verfügbare und zugewiesene Slots visualisieren.
Nachdem Sie Slots gekauft und Ihre Arbeitslasten mindestens sieben Tage lang ausgeführt haben, können Sie den Slot-Estimator verwenden, um die Leistung zu analysieren und die Auswirkungen des Hinzufügens oder Reduzierens von Slots zu modellieren. Weitere Informationen finden Sie unter Anforderungen an die Slotkapazität schätzen.
Abfrage mit Slots ausführen
Bei der Ausführung eines Abfragejobs in BigQuery wird die deklarative SQL-Anweisung in einen Ausführungsgraphen umgewandelt. Dieser wird in mehrere Abfragephasen aufgeteilt, die sich wiederum aus detaillierten Ausführungsschritten zusammensetzen. BigQuery nutzt zum Ausführen dieser Abfragen eine stark verteilte parallele Architektur. In den Phasen werden dabei die Arbeitseinheiten modelliert, die viele potenzielle Worker parallel ausführen können. Die Phasen kommunizieren über eine schnelle verteilte Shuffle-Architektur miteinander. Diese wird im Google Cloud-Blog ausführlicher erläutert.
Das Ausführen von Abfragen erfolgt in BigQuery dynamisch. Das bedeutet, der Abfrageplan kann sich während einer laufenden Abfrage ändern. Häufig werden bei der Ausführung einer Abfrage Phasen eingeführt, um die Datenverteilung auf die Worker der Abfrage zu verbessern.
BigQuery kann mehrere Phasen gleichzeitig ausführen. BigQuery kann eine spekulative Ausführung nutzen, um eine Abfrage zu beschleunigen, und eine Phase dynamisch neu partitionieren, um eine optimale Parallelisierung zu erzielen.
In jeder Phase der Abfrage werden die einzelnen Arbeitseinheiten von BigQuery-Slots ausgeführt. Wenn BigQuery beispielsweise feststellt, dass der optimale Parallelisierungsfaktor einer Phase 10 beträgt, fordert es 10 Slots an, um diese Phase zu verarbeiten.
Abfragen entsprechend der Slotressourcen ausführen
Wenn eine Abfrage mehr Slots benötigt als verfügbar sind, stellt BigQuery einzelne Arbeitseinheiten in die Warteschlange und wartet auf verfügbare Slots. Während der Ausführung der Abfragen werden diese zurückgestellten Arbeitseinheiten dynamisch für die Ausführung ausgewählt.
BigQuery kann für eine bestimmte Phase einer Abfrage eine beliebige Anzahl an Slots anfordern. Die Anzahl der angeforderten Slots hat nichts mit der Kapazität zu tun, die Sie erwerben, sondern weist eher auf den optimalen Parallelisierungsfaktor hin, den BigQuery für diese Phase ausgewählt hat. Arbeitseinheiten werden in die Warteschlange aufgenommen und ausgeführt, sobald Slots verfügbar werden.
Überschreiten Abfrageanforderungen die von Ihnen erworbenen Slots, werden Ihnen keine zusätzlichen Slots in Rechnung gestellt und Ihnen wird kein zusätzlicher On-Demand-Preis berechnet. Stattdessen werden Ihre Arbeitseinheiten in die Warteschlange verschoben.
Beispiel:
- In einer Abfragephase werden 2.000 Slots angefordert, es sind jedoch nur 1.000 verfügbar.
- BigQuery nutzt alle 1.000 Slots, während die verbleibenden Arbeitseinheiten in der Warteschlange auf die übrigen 1.000 Slots warten.
- Ist die Arbeit von 100 Slots abgeschlossen, werden diese dynamisch an 100 Arbeitseinheiten von den 1.000 Arbeitseinheiten in der Warteschlange vergeben. 900 Arbeitseinheiten verbleiben in der Warteschlange.
- Ist danach die Arbeit von 500 weiteren Slots erledigt, werden 500 Arbeitseinheiten dieser 900 Arbeitseinheiten dynamisch aus der Warteschlange genommen. 400 Arbeitseinheiten verbleiben in der Warteschlange.
Inaktive Slots
Es kann jederzeit vorkommen, dass einige Slots inaktiv sind. Beispiel:
- Slotzusicherungen, die keiner Reservierung zugewiesen sind.
- Slots, die einer Reservierungsreferenz zugewiesen sind, aber nicht verwendet werden.
Standardmäßig verwenden Abfragen, die in einer Reservierung ausgeführt werden, inaktive Slots aus anderen Reservierungen innerhalb desselben Administrationsprojekts automatisch. Ein Job kann also immer ausgeführt werden, solange Kapazität vorhanden ist. Nicht genutzte Kapazitäten können bei Bedarf sofort wieder der ursprünglich zugewiesenen Reservierung zugewiesen werden, unabhängig von der Priorität der Abfrage, die die Ressourcen benötigt. Das Ganze geschieht automatisch und in Echtzeit.
Um dieses Verhalten zu vermeiden und sicherzustellen, dass eine Reservierung nur die bereitgestellten Slots verwendet, setzen Sie ignore_idle_slots auf true. Wenn ignore_idle_slots für Reservierungen auf true gesetzt ist, können diese ihre inaktiven Slots jedoch für andere Reservierungen freigeben.
Inaktive Slots können nicht zwischen Reservierungen verschiedener Versionen geteilt werden. Sie können nur die Referenzslots oder die zugesicherten Slots freigeben. Automatisch skalierte Slots sind möglicherweise vorübergehend verfügbar, können aber nicht freigegeben werden, da sie herunterskaliert werden können.
Solange ignore_idle_slots "false" ist, kann eine Reservierung mit der Slot-Anzahl 0 trotzdem auf ungenutzte Slots zugreifen. Wenn Sie nur die default-Reservierung verwenden, deaktivieren Sie ignore_idle_slots als Best Practice. Sie können dieser Reservierung dann ein Projekt oder einen Ordner zuweisen, der nur inaktive Slots verwendet.
Aufgaben vom Typ ML_EXTERNAL bilden eine Ausnahme, da Slots, die von externen BigQuery ML-Modellerstellungsjobs verwendet werden, nicht auf Abruf sind. Die Slots in einer Reservierung mit den Zuweisungstypen ML_EXTERNAL und QUERY sind nur für andere Abfragejobs verfügbar, wenn die Slots nicht von den ML_EXTERNAL-Jobs belegt werden. Darüber hinaus können diese Jobs keine inaktiven Slots aus anderen Reservierungen verwenden.
Slotzuweisung innerhalb von Reservierungen
BigQuery weist die Slotkapazität innerhalb einer einzelnen Reservierung mithilfe eines Algorithmus namens faire Planung zu.
Der BigQuery-Planer erzwingt die gleichmäßige Aufteilung von Slots zwischen Projekten mit in Ausführung befindlichen Abfragen innerhalb einer Reservierung und anschließend zwischen Jobs eines bestimmten Projekts. Der Planer sorgt für eine finale Gleichmäßigkeit. Während kurzer Zeit können einige Jobs einen unverhältnismäßig hohen Anteil an Slots erhalten, aber der Planer korrigiert dies schließlich. Das Ziel des Planers besteht darin, ein Gleichgewicht zwischen aggressiven Beenden von laufenden Aufgaben (was zu einer Verschwendung von Slot-Zeit führt) und zu viel Nachsicht (was dazu führt, dass Jobs mit lang andauernden Aufgaben einen unverhältnismäßig hohen Anteil an Slot-Zeit erhalten) zu finden.
Wenn ein wichtiger Job durchgängig mehr Slots benötigt, als der Planer ihm bereitstellt, sollten Sie eventuell eine zusätzliche Reservierung mit einer garantierten Anzahl von Slots erstellen und den Job der Reservierung zuweisen.
Faire Planung in BigQuery
Slots werden gleichmäßig auf Projekte und dann auf die Jobs innerhalb des Projekts verteilt. Das heißt, dass jede Abfrage jederzeit Zugriff auf alle verfügbaren Slots hat und dass die Kapazität dynamisch und automatisch zwischen den aktiven Abfragen neu zugewiesen wird, wenn sich die Kapazitätsanforderungen der Abfragen ändern. Unter den folgenden Bedingungen werden Abfragen abgeschlossen und neue Abfragen zur Ausführung gesendet:
- Wenn eine neue Abfrage gesendet worden ist, wird die Kapazität automatisch neu an die ausgeführten Abfragen zugewiesen. Einzelne Arbeitseinheiten können unterbrochen, fortgesetzt und in die Warteschlange aufgenommen werden, je nachdem, wie viel Kapazität für die einzelnen Abfragen zur Verfügung steht.
- Sobald eine Abfrage abgeschlossen worden ist, wird die von dieser Abfrage genutzte Kapazität für alle anderen Abfragen verfügbar.
- Wenn sich die Kapazitätsanforderungen einer Abfrage aufgrund von Änderungen im dynamischen DAG der Abfrage ändern, bewertet BigQuery die Kapazitätsverfügbarkeit für diese und alle anderen Abfragen automatisch neu. Wenn nötig, werden Slots neu zugewiesen oder unterbrochen.
Je nach Komplexität und Größe benötigt eine Abfrage eventuell nicht alle Slots, die ihr zustehen, oder sie benötigt mehr. BigQuery stellt unter Beachtung der fairen Planung dynamisch sicher, dass alle Slots jederzeit voll genutzt werden können.