Informationen zu Slots

Ein BigQuery-Slot ist eine virtuelle Recheneinheit, die von BigQuery zum Ausführen von SQL-Abfragen oder anderen Jobtypen verwendet wird. Während der Ausführung einer Abfrage ermittelt BigQuery automatisch, wie viele Slots von der Abfrage verwendet werden. Die Anzahl der verwendeten Slots hängt von der Menge der verarbeiteten Daten, der Komplexität der Abfrage und der Anzahl der verfügbaren Slots ab. Im Allgemeinen können Sie durch den Zugriff auf mehr Slots mehr gleichzeitige Abfragen ausführen und komplexe Abfragen schneller ausführen.

Für alle Abfragen werden Slots verwendet. Sie haben jedoch zwei Optionen für die Abrechnung der Nutzung: das On-Demand-Preismodell oder das kapazitätsbasierte Preismodell.

Standardmäßig erfolgt die Abrechnung nach dem On-Demand-Modell. Bei diesem Modell wird Ihnen die Datenmenge in Rechnung gestellt, die bei jeder Abfrage verarbeitet wird (gemessen in TiB). Projekte, die das On-Demand-Modell verwenden, unterliegen Slot-Limits pro Projekt und Organisation mit vorübergehender Burst-Funktion. Die meisten Nutzer des On-Demand-Modells finden die Slotkapazitätslimits mehr als ausreichend. Je nach Arbeitslast kann der Zugriff auf mehr Slots jedoch die Abfrageleistung verbessern. Informationen zur Anzahl der von Ihrem Konto genutzten Slots finden Sie unter BigQuery-Monitoring.

Mit dem kapazitätsbasierten Modell bezahlen Sie für die Slotkapazität, die Ihren Abfragen im Laufe der Zeit zugewiesen wird. Dieses Modell ermöglicht Ihnen die explizite Kontrolle über die gesamte Slotkapazität, während das On-Demand-Modell nicht funktioniert. Sie wählen die Anzahl der zu verwendenden Slots explizit über eine Reservierung aus. Sie können die Anzahl der Slots in einer Reservierung als Baseline-Betrag angeben, der immer zugewiesen wird, oder als automatisch skalierter Betrag, der bei Bedarf zugewiesen wird.

Abfrage mit Slots ausführen

Bei der Ausführung eines Abfragejobs in BigQuery wird die SQL-Anweisung in einen Ausführungsplan 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. Daten werden zwischen den Phasen über eine schnelle verteilte Shuffle-Architektur übergeben. 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. Außerdem kann sich die Ausführung von Abfragen durch die sich ändernde Menge an verfügbarer Kapazität auswirken, wenn andere Abfragen abgeschlossen oder ausgeführt werden oder dem Autoscaler Slots zur Reservierung hinzugefügt werden.

BigQuery kann mehrere Phasen gleichzeitig ausführen, 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.

Diagramm zur Abfrageausführung mit Phasen und Schritten

Slotressourcen

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:

1. In einer Abfragephase werden 2.000 Slots angefordert, es sind jedoch nur 1.000 verfügbar.
2. BigQuery nutzt alle 1.000 Slots, während die verbleibenden Arbeitseinheiten in der Warteschlange auf die übrigen 1.000 Slots warten.
3. 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.
4. 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.

BigQuery-Slots in der Warteschlange – der Bedarf übersteigt die Verfügbarkeit

Faire Planung in BigQuery

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.

Die faire Planung sorgt dafür, 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.

Faire Planung in BigQuery

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.

Wenn ein wichtiger Job durchgängig mehr Slots benötigt, als der Planer ihm bereitstellt, sollten Sie eventuell eine zusätzliche Reservierung mit der erforderlichen Anzahl von Slots erstellen und den Job der Reservierung zuweisen.

Angenommen, Sie haben die folgende Reservierungskonfiguration:

• Reservierung A mit 1.000 Referenz-Slots ohne Autoscaling
• Projekt A und Projekt B, die Ihrer Reservierung zugewiesen sind

Szenario 1: Im Projekt A führen Sie die Abfrage A (eine gleichzeitige Abfrage) aus, die eine hohe Slot-Auslastung erfordert. Im Projekt B führen Sie 20 gleichzeitige Abfragen aus. Obwohl insgesamt 21 Abfragen die Reservierung A verwenden, sieht die Slot-Verteilung so aus:

• Projekt A erhält 500 Slots und die Abfrage A wird mit 500 Slots ausgeführt.
• Projekt B erhält 500 Slots, die auf die 20 Abfragen aufgeteilt werden.

Szenario 2: In Projekt A führen Sie die Abfrage A (eine gleichzeitige Abfrage) aus, für die 100 Slots erforderlich sind. In Projekt B führen Sie 20 gleichzeitige Abfragen aus. Da für die Abfrage A nicht 50% der Reservierung erforderlich sind, sieht die Verteilung der Slots so aus:

• Projekt A erhält 100 Slots und die Abfrage A wird mit 100 Slots ausgeführt.
• Projekt B erhält 900 Slots, die auf die 20 Abfragen aufgeteilt werden.

Betrachten Sie im Gegensatz dazu die folgende Reservierungskonfiguration:

• Reservierung B mit 1.000 Referenz-Slots ohne Autoscaling.
• 10 Projekte, die alle der Reservierung B zugewiesen sind.

Angenommen, in den 10 Projekten werden Abfragen mit ausreichendem Slotbedarf ausgeführt. Dann erhält jedes Projekt 1/10 der gesamten Reservierungsslots (also 100 Slots), unabhängig davon, wie viele Abfragen in den einzelnen Projekten ausgeführt werden.

Kontingente und Limits für Slots

Slot-Kontingente und -Limits schützen BigQuery. Bei den verschiedenen Preismodellen werden unterschiedliche Slot-Kontingenttypen verwendet:

• On-Demand-Preismodell: Sie unterliegen einem Pro-Projekt- und Organisations-Slot-Limit mit vorübergehender Burst-Funktion. Abhängig von Ihren Arbeitslasten kann der Zugriff auf mehr Slots die Abfrageleistung verbessern.

• Kapazitätsbasiertes Preismodell: Reservierungskontingente und -limits definieren die maximale Anzahl von Slots, die Sie allen Reservierungen an einem Standort zuweisen können. Ihnen werden nur die Reservierungen und Zusicherungen in Rechnung gestellt, nicht die Kontingente. Informationen zum Erhöhen des Slot-Kontingents finden Sie unter Kontingenterhöhung anfordern.

Informationen darüber, wie viele Slots Sie nutzen, finden Sie unter BigQuery-Monitoring.

Inaktive Slots

Es kann jederzeit vorkommen, dass einige Slots inaktiv sind. Beispiel:

• Slotzusicherungen, die keiner Reservierungsreferenz zugewiesen sind.
• Slots, die einer Reservierungsreferenz zugewiesen sind, aber nicht verwendet werden.

Bei Verwendung des On-Demand-Preismodells sind keine Leerlauf-Slots verfügbar.

Standardmäßig verwenden Abfragen, die in einer Reservierung ausgeführt werden, inaktive Slots aus anderen Reservierungen innerhalb desselben Administrationsprojekts automatisch. BigQuery weist einer zugewiesenen Reservierung sofort Slots zu, wenn sie benötigt werden. Inaktive Slots, die von einer anderen Reservierung verwendet wurden, werden schnell aufgelöst. Es kann vorkommen, dass die Gesamtzahl der verwendeten Slots für kurze Zeit das für alle Reservierungen angegebene Maximum überschreitet. Diese zusätzliche Slotnutzung wird Ihnen jedoch nicht in Rechnung gestellt.

Angenommen, Sie haben folgende Reservierungseinstellungen:

• project_a ist reservation_a zugewiesen, das 500 Referenz-Slots ohne Autoscaling hat.
• project_b ist reservation_b zugewiesen, das 100 Referenz-Slots ohne Autoscaling hat.
• Beide Reservierungen befinden sich im selben Verwaltungsprojekt und es sind keine anderen Projekte zugewiesen.

Sie führen query_b in project_b aus. Wenn in project_a keine Abfrage ausgeführt wird, hat query_b Zugriff auf die 500 inaktiven Slots von reservation_a. Solange query_b noch ausgeführt wird, können bis zu 600 Slots belegt werden: 100 Referenz-Slots plus 500 inaktive Slots.

Angenommen, Sie führen während der Ausführung von query_b query_a in project_a aus, das 500 Slots nutzen kann.

• Da Sie 500 Referenz-Slots für project_a reserviert haben, wird query_a sofort gestartet und erhält 500 Slots.
• Die Anzahl der query_b zugewiesenen Slots sinkt schnell auf 100 Referenz-Slots.
• Zusätzliche Abfragen, die in project_b ausgeführt werden, teilen sich diese 100 Slots. Wenn für nachfolgende Abfragen nicht genügend Slots verfügbar sind, werden sie in die Warteschlange gestellt, bis die derzeit ausgeführten Abfragen abgeschlossen sind und Slots frei werden.

Wenn project_b in diesem Beispiel einer Reservierung ohne Baseline-Slots oder Autoscaling zugewiesen wurde, hat query_b nach dem Start von query_a keine Slots mehr. BigQuery würde query_b pausieren, bis inaktive Slots verfügbar sind oder die Abfrage abläuft. Zusätzliche Abfragen in project_b werden in die Warteschlange gestellt, bis inaktive Slots verfügbar sind.

Damit 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 als inaktive Slots für andere Reservierungen 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.

Reservierungsbasierte Fairness

Hinweis :Sie müssen die reservierungsbasierte Fairness aktivieren, bevor Sie eine vorhersagbare Reservierung erstellen können.

Bei der reservierungsbasierten Fairness priorisiert BigQuery inaktive Slots und weist sie gleichmäßig allen Reservierungen im selben Administrationsprojekt zu, unabhängig von der Anzahl der Projekte, in denen Jobs in den einzelnen Reservierungen ausgeführt werden. Jede Reservierung erhält einen ähnlichen Anteil der verfügbaren Kapazität im Leerlauf-Slotpool. Die Slots werden dann gleichmäßig auf die Projekte verteilt. Diese Funktion wird nur in den Enterprise- oder Enterprise Plus-Versionen unterstützt.

Das folgende Diagramm zeigt, wie inaktive Slots ohne aktivierte reservierungsbasierte Fairness verteilt werden:

In diesem Diagramm werden inaktive Slots gleichmäßig auf die Projekte verteilt.

Wenn die reservierungsbasierte Fairness nicht aktiviert ist, werden die verfügbaren inaktiven Slots gleichmäßig auf die Projekte in den Reservierungen verteilt.

Das folgende Diagramm zeigt, wie inaktive Slots verteilt werden, wenn die reservierungsbasierte Fairness aktiviert ist:

In diesem Diagramm werden inaktive Slots gleichmäßig auf Reservierungen, nicht auf Projekte aufgeteilt.

Wenn die reservierungsbasierte Fairness aktiviert ist, werden die verfügbaren inaktiven Slots gleichmäßig auf die Reservierungen verteilt.

Wenn Sie die reservierungsbasierte Fairness aktivieren, sollten Sie Ihren Ressourcenverbrauch im Blick behalten, um die Verfügbarkeit von Slots und die Abfrageleistung zu optimieren.

Verlassen Sie sich bei Produktionsarbeitslasten mit strengen Zeitvorgaben nicht ausschließlich auf inaktive Slots. Für diese Jobs sollten Baseline- oder Autoscaling-Slots verwendet werden. Wir empfehlen, inaktive Slots für Jobs mit niedrigerer Priorität zu verwenden, da die Slots jederzeit unterbrochen werden können.

Übermäßige Slot-Nutzung

Wenn ein Job zu lange Slots belegt, kann er einen unverhältnismäßig hohen Anteil an Slots erhalten. Um Verzögerungen zu vermeiden, können andere Jobs in BigQuery zusätzliche Slots ausleihen, was zu Zeiträumen führt, in denen die Gesamtnutzung der Slots über der angegebenen Slotkapazität liegt. Eine übermäßige Slot-Nutzung wird nur den Jobs zugeordnet, die mehr als ihren gerechten Anteil erhalten.

Die zusätzlichen Slots werden Ihnen nicht direkt in Rechnung gestellt. Stattdessen werden Jobs weiter ausgeführt und die Slotnutzung wird nach ihrem Anteil aufgerechnet, bis die gesamte zusätzliche Nutzung durch Ihre zugewiesene Kapazität abgedeckt ist. Überschüssige Slots werden von der gemeldeten Slotnutzung ausgeschlossen, mit Ausnahme bestimmter detaillierter Ausführungsstatistiken.

Beachten Sie, dass einige Slots vorab geliehen werden können, um zukünftige Verzögerungen zu vermeiden und andere Vorteile zu bieten, z. B. eine geringere Slotspreisvariabilität und eine geringere Tail-Latenz. Die Ausleihe von Slots ist auf einen kleinen Teil Ihrer gesamten Slotkapazität beschränkt.