Informazioni sugli slot

Uno slot BigQuery è una CPU virtuale utilizzata da BigQuery per eseguire query SQL. Durante l'esecuzione della query, BigQuery calcola automaticamente il numero di slot richiesti da una query, a seconda della query dimensioni e complessità.

Puoi scegliere se utilizzare un modello di prezzi on demand. o un modello di prezzi basato sulla capacità. Entrambi modelli utilizzano per l'elaborazione dei dati. Con un modello basato sulla capacità, puoi pagare per o capacità di elaborazione delle query con scalabilità automatica. Il modello basato sulla capacità ti offre un controllo esplicito sugli slot e sulla capacità di analisi, mentre il modello on demand no.

I clienti che utilizzano il modello di prezzi basato sulla capacità scelgono esplicitamente il numero di slot da prenotare. Le tue query vengono eseguite all'interno di questa capacità e pagherai per questa capacità ogni secondo di cui viene eseguito il deployment. Ad esempio, se acquisti 2000 gli slot BigQuery, le query aggregate sono limitate all'uso 2000 CPU virtuali in un dato momento. Puoi utilizzare questa capacità fino all'eliminazione e paghi 2000 slot fino all'eliminazione.

I progetti sul modello di prezzi on demand di BigQuery sono soggetti a quota di slot per progetto con burst temporaneo funzionalità. La maggior parte degli utenti del modello on demand trova la capacità slot predefinita più che sufficiente. A seconda del carico di lavoro, l'accesso a più slot migliora le prestazioni della query. Per verificare quanti slot vengono utilizzati dal tuo account, consulta Monitoraggio di BigQuery

Stima il numero di slot da acquistare

BigQuery è progettato per scalare in modo efficiente con un aumento delle risorse. A seconda del carico di lavoro, è probabile che la capacità incrementale offra vantaggi incrementali. Pertanto, la scelta del numero ottimale di slot da acquistare dipende dai tuoi requisiti per prestazioni, throughput e utilità.

Puoi fare esperimenti con gli slot di riferimento e con scalabilità automatica per determinare qual è configurazione degli slot. Ad esempio, puoi testare il carico di lavoro utilizzando di base, quindi 1000, 1500 e 2000 e osservare l'impatto delle prestazioni.

Puoi anche esaminare l'utilizzo corrente degli slot dei tuoi progetti, nonché il prezzo mensile scelto che vuoi pagare. I carichi di lavoro on demand hanno di 2000 slot, ma è importante controllare quanti slot sono effettivamente utilizzato dai tuoi progetti INFORMATION_SCHEMA.JOBS* visualizzazioni, Cloud Logging, API Jobs o controllo BigQuery logaritmi. Per ulteriori informazioni, consulta Visualizzare gli slot disponibili e quelli allocati.

Dopo aver acquistato gli slot ed eseguito i carichi di lavoro per almeno sette giorni, puoi: usa lo strumento di stima degli slot per analizzare le prestazioni e modellare l'effetto dell'aggiunta o riducendo gli slot. Per ulteriori informazioni, vedi Stima i requisiti di capacità degli slot.

Esecuzione di query utilizzando gli slot

Quando BigQuery esegue un job di query, converte l'istruzione SQL declarative in un grafo di esecuzione, suddiviso in una serie di fasi di query, che a loro volta sono composte da insiemi più granulari di passaggi di esecuzione. BigQuery utilizza un parallelismo molto distribuito dell'architettura per eseguire queste query e le fasi modellano le unità di lavoro che molti potenziali worker possono eseguire in parallelo. Le fasi comunicano con usando una velocità architettura shuffle distribuita, che verrà discusso più in dettaglio Blog di Google Cloud.

L'esecuzione delle query in BigQuery è dinamica, il che significa che mentre il piano di query può essere modificato. Le fasi introdotte durante l'esecuzione di una query vengono spesso utilizzate per migliorare la distribuzione dei dati tra i worker di query.

BigQuery può eseguire più fasi contemporaneamente. BigQuery può utilizzare l'esecuzione speculativa per accelerare una query e può ripartire dinamicamente una fase per ottenere una parallelizzazione ottimale.

Gli slot BigQuery eseguono singole unità di lavoro in ogni fase la query. Ad esempio, se BigQuery determina che il coefficiente di parallelizzazione ottimale di una fase è 10, richiede 10 slot per elaborare la fase.

La query GoogleSQL è un DAG dinamico

Esecuzione della query in economia delle risorse slot

Se una query richiede più slot rispetto a quelli attualmente disponibili, BigQuery mette in coda le singole unità di lavoro e attende che gli slot siano disponibili. Man mano che si procede nell'esecuzione della query e che gli slot si liberano, le unità di lavoro in coda vengono selezionate dinamicamente per l'esecuzione.

BigQuery può richiedere un numero qualsiasi di slot per una determinata fase di una query. Il numero di slot richiesti non è correlato alla quantità di capacità di acquisto, ma piuttosto un'indicazione della capacità ottimale fattore di parallelizzazione scelto da BigQuery per quella fase. Unità di lavoro entrano in coda e vengono eseguiti man mano che gli slot diventano disponibili.

Quando le richieste di query superano gli slot che hai impegnato, non ti vengono addebitati gli slot aggiuntivi né le tariffe on demand aggiuntive. Il tuo singole unità di lavoro in coda.

Ad esempio,

1. Un'etapa di query richiede 2000 slot, ma ne sono disponibili solo 1000.
2. BigQuery consuma tutti i 1000 slot e mette in coda l'altro 1000 slot.
3. Successivamente, se 100 slot terminano il lavoro, vengono selezionati dinamicamente di 100 unità di lavoro dalle 1.000 in coda. 900 unità di i lavori in coda rimangono.
4. Successivamente, se 500 slot terminano il loro lavoro, vengono selezionati dinamicamente 500 unità di lavoro dalle 900 in coda. 400 unità di i lavori in coda rimangono.

Slot BigQuery in coda se la domanda supera la disponibilità

Slot inattivi

In un determinato momento, alcuni slot potrebbero essere inattivi. ad esempio:

• Impegni slot non allocati a nessuna base di riferimento per le prenotazioni.
• Slot allocati a un riferimento di prenotazione, ma non in uso.

Per impostazione predefinita, le query eseguite in una prenotazione utilizzano automaticamente gli slot inattivi di altre prenotazioni all'interno dello stesso progetto di amministrazione. BigQuery alloca immediatamente gli slot a una prenotazione assegnata quando sono necessari. Gli slot inattivi utilizzati da un'altra prenotazione sono rapidamente prerilasciata. Per un breve periodo di tempo potresti notare che il consumo totale degli slot supera il massimo specificato per tutte le prenotazioni, ma non ti verrà addebitato alcun costo per questo utilizzo aggiuntivo degli slot.

Ad esempio, supponiamo che tu abbia la seguente configurazione di prenotazione:

• project_a è assegnato a reservation_a, che ha 500 slot di riferimento senza scalabilità automatica.
• project_b è assegnato a reservation_b, che ha 100 slot di riferimento senza scalabilità automatica.
• Entrambe le prenotazioni si trovano nello stesso progetto amministrativo e non sono assegnati altri progetti a queste prenotazioni.

Corri query_b in project_b. Se non è in esecuzione alcuna query in project_a, query_b ha accesso ai 500 slot inutilizzati di reservation_a. Mentre query_b è ancora in esecuzione, potrebbe utilizzare fino a 600 slot: 100 slot di base più 500 slot inattivi.

Mentre query_b è in esecuzione, supponi di eseguire query_a in project_a che può e utilizzare 500 slot.

• Poiché hai 500 slot di riferimento prenotati per project_a, query_a inizia immediatamente e vengono allocati 500 slot.
• Il numero di slot assegnati a query_b diminuisce rapidamente fino a 100 slot di riferimento.
• Le query aggiuntive eseguite in project_b condividono questi 100 slot. Se le query successive non dispongono di slot sufficienti per l'avvio, vengono messe in coda fino al completamento delle query in esecuzione e alla disponibilità degli slot.

In questo esempio, se project_b è stato assegnato a una prenotazione senza slot di base o scalabilità automatica, query_b non avrà slot dopo l'avvio di query_a. BigQuery mette in pausa query_b finché non sono disponibili slot inattivi o il tempo di attesa della query scade. Le query aggiuntive in project_b verranno messe in coda finché non sono disponibili slot inattivi.

Per garantire che una prenotazione utilizzi solo i dati di cui è stato eseguito il provisioning slot, imposta ignore_idle_slots su true. Prenotazioni con ignore_idle_slots impostato su true può, tuttavia, condividere i suoi slot inattivi con altre prenotazioni.

Non puoi condividere gli slot inattivi tra prenotazioni di versioni diverse. Puoi condividere solo gli slot di riferimento o quelli assegnati. Slot a scalabilità automatica potrebbero essere temporaneamente disponibili, ma non sono condivisibili come slot inattivi per altre prenotazioni perché potrebbero scalare verso il basso.

Se ignore_idle_slots è false, una prenotazione può avere un numero di slot pari a 0 e hai ancora accesso agli slot inutilizzati. Se utilizzi solo default su prenotazione, disattiva ignore_idle_slots come best practice. Puoi quindi assegnare un progetto o una cartella alla prenotazione, che utilizzerà solo gli slot inutilizzati.

Compiti di tipo ML_EXTERNAL costituiscono un'eccezione perché gli slot utilizzati I job di creazione di modelli esterni di BigQuery ML non sono prerilasciabili. Gli slot di una prenotazione con tipi di assegnazione sia ML_EXTERNAL che QUERY sono disponibili per altri job di query solo quando non sono occupati dai job ML_EXTERNAL. Inoltre, questi job non possono utilizzare slot inattivi di altri prenotazioni.

Allocazione di slot all'interno delle prenotazioni

BigQuery alloca la capacità dello slot all'interno di una singola prenotazione utilizzando un algoritmo chiamato pianificazione equa.

Lo scheduler BigQuery applica la stessa condivisione degli slot tra con query in esecuzione all'interno di una prenotazione e poi all'interno di job di un dato progetto. Lo scheduler fornisce equità finale. Per brevi periodi, alcuni job potrebbero ricevere una quota sproporzionata di slot, ma lo schedulatore corregge infine il problema. L'obiettivo dello scheduler è trovare un equilibrio tra la rimozione aggressiva delle attività in esecuzione (il che si traduce sprecare il tempo di slot) ed essere troppo permissivi (il che si traduce in lavori con lunghi di attività in esecuzione che ricevono una quota sproporzionata del tempo di slot).

Se un job importante ha sempre bisogno di più slot di quelli che riceve scheduler, valuta la possibilità di creare una prenotazione aggiuntiva con un numero garantito di slot e assegnando il job a quella prenotazione.

Utilizzo slot eccessivo

Quando un job mantiene gli slot per troppo tempo, può ricevere una quota ingiusta di slot come descritto sopra. Per evitare ritardi, altri job possono prendere in prestito slot aggiuntivi, con periodi di utilizzo totale degli slot superiori alla capacità specificata. L'eventuale utilizzo eccessivo degli slot attribuiti solo ai lavori che ricevono più della loro giusta quota.

Gli slot in eccesso non ti vengono addebitati direttamente. I job continuano invece a essere eseguiti e ad accumulare l'utilizzo degli slot in base alla loro quota fino a quando tutto l'utilizzo in eccesso non viene coperto dalla tua capacità standard. Gli slot in eccesso sono esclusi da è stato segnalato l'utilizzo degli slot, ad eccezione di alcuni le statistiche di esecuzione.

Tieni presente che può verificarsi un prelievo preventivo di slot per ridurre i ritardi futuri e offrire altri vantaggi, come la riduzione della variabilità del costo degli slot e della latenza del tempo di coda. Il prestito slot è limitato a una piccola frazione di la capacità totale degli slot.

Buona pianificazione in BigQuery

Gli slot sono distribuiti equamente tra i progetti e poi all'interno dei job del progetto. Ciò significa che ogni query ha accesso a tutti gli slot disponibili in qualsiasi momento e la capacità viene riallocata in modo dinamico e automatico tra le query attive man mano che le richieste di capacità di ciascuna query cambiano. Query completate e nuove query vengono inviate per l'esecuzione alle seguenti condizioni:

• Ogni volta che viene inviata una nuova query, la capacità viene riallocata automaticamente tra le query in esecuzione. Le singole unità di lavoro possono essere messe in pausa, riprese e messe in coda in modo graduale man mano che diventa disponibile più capacità per ogni query.
• Ogni volta che una query viene completata, la capacità utilizzata dalla query diventa automaticamente disponibile per tutte le altre query.
• Ogni volta che la capacità di una query richiede una modifica a causa di modifiche nella con un DAG dinamico, BigQuery rivaluta automaticamente la capacità la disponibilità per questa e per tutte le altre query, gli slot machine in base alle necessità.

Una pianificazione equa in BigQuery

A seconda della complessità e delle dimensioni, una query potrebbe non richiedere tutti gli slot di cui ha diritto o potrebbe richiederne di più. BigQuery garantisce dinamicamente che, in base a una pianificazione equa, tutti gli slot possano essere utilizzati al massimo in qualsiasi momento.