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 delle dimensioni e della complessità della query.

Puoi scegliere di utilizzare un modello di prezzi on demand o un modello di prezzi basato sulla capacità. Entrambi i modelli utilizzano gli slot per l'elaborazione dei dati. Con un modello basato sulla capacità, puoi pagare per la capacità di elaborazione delle query dedicata o 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 query vengono eseguite in questa capacità e tu la paghi continuamente ogni secondo di deployment. Ad esempio, se acquisti 2000 slotti BigQuery, le query aggregate sono limitate all'utilizzo di 2000 CPU virtuali in un determinato momento. Puoi utilizzare questa capacità fino all'eliminazione e paghi 2000 slot fino all'eliminazione.

I progetti che utilizzano il modello di determinazione dei prezzi on demand di BigQuery sono soggetti a una quota di slot per progetto con capacità di picco transitorio. La maggior parte degli utenti che utilizzano il modello on demand ritiene che la capacità dello slot predefinita sia più che sufficiente. A seconda del carico di lavoro, l'accesso a più slot migliora le prestazioni delle query. Per verificare quanti slot utilizza il 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 di scalabilità automatica per determinare la migliore configurazione degli slot. Ad esempio, puoi testare il tuo carico di lavoro con 500 slot di base, poi 1000, 1500 e 2000 e osservare l'impatto sulle 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 un limite massimo di slot flessibile di 2000, ma è importante verificare quanti slot vengono effettivamente utilizzati dai tuoi progetti utilizzando le visualizzazioni INFORMATION_SCHEMA.JOBS*, Cloud Logging, l'API Jobs o i log di BigQuery Audit. Per ulteriori informazioni, consulta Visualizzare gli slot disponibili e quelli allocati.

Dopo aver acquistato gli slot ed eseguito i workload per almeno sette giorni, puoi utilizzare lo strumento di stima degli slot per analizzare il rendimento e modellare l'effetto dell'aggiunta o della riduzione degli slot. Per ulteriori informazioni, consulta Stimare 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'architettura parallela fortemente distribuita per eseguire queste query e le fasi modellano le unità di lavoro che molti potenziali worker possono eseguire in parallelo. Le fasi comunicano tra loro utilizzando una rapida architettura di ordinamento distribuita, discussa più dettagliatamente nel blog di Google Cloud.

L'esecuzione delle query di BigQuery è dinamica, il che significa che il piano delle query può essere modificato mentre una query è in esecuzione. 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 di BigQuery eseguono singole unità di lavoro in ogni fase della 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 di query in condizioni di risorse slot limitate

Se una query richiede più slot rispetto a quelli attualmente disponibili, BigQuery aggiunge singole unità di lavoro alla coda e attende che gli slot diventino disponibili. Man mano che l'esecuzione delle query procede e gli slot diventano disponibili, queste unità di lavoro in coda vengono acquisite in modo dinamico 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à acquistata, ma è un'indicazione del fattore di parallelizzazione più ottimale scelto da BigQuery per quella fase. Le unità di lavoro si mettono in coda e vengono eseguite 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. Le singole unità di lavoro vengono messe 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 gli altri 1000.
3. In seguito, se 100 slot completano il loro lavoro, raccolgono dinamicamente 100 unità di lavoro dalle 1000 unità di lavoro in coda. Rimangono 900 unità di lavoro in coda.
4. In seguito, se 500 slot completano il loro lavoro, raccolgono dinamicamente 500 unità di lavoro dalle 900 unità di lavoro in coda. Rimangono 400 unità di lavoro in coda.

Slot BigQuery in coda se la domanda supera la disponibilità

Slot inattivi

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

• Impegni di slot non allocati a nessun riferimento di prenotazione.
• Slot allocati a un riferimento di prenotazione, ma non in uso.

Per impostazione predefinita, le query in esecuzione 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 vengono rapidamente prelevati. 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, immagina di avere la seguente configurazione delle prenotazioni:

• 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.

Esegui 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, supponiamo che tu esegua query_a in project_a, che può usare 500 slot.

• Poiché hai 500 slot di base riservati per project_a, query_a si avvia immediatamente e vengono allocati 500 slot.
• Il numero di slot allocati a query_b diminuisce rapidamente fino a 100 slot di base.
• 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 non scade il timeout della query. Le query aggiuntive in project_b rimangono in coda fino a quando non sono disponibili slot inattivi.

Per assicurarti che una prenotazione utilizzi solo gli annunci provisionati, imposta ignore_idle_slots su true. Tuttavia, le prenotazioni con ignore_idle_slots impostato su true possono condividere gli 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. Gli slot con scaling automatico potrebbero essere temporaneamente disponibili, ma non sono condivisibili come slot inattivi per altre prenotazioni perché potrebbero essere ridotti.

Finché ignore_idle_slots è false, una prenotazione può avere un conteggio di slot di 0 e avere comunque accesso agli slot inutilizzati. Se utilizzi solo la prenotazione default, disattiva ignore_idle_slots come best practice. Puoi quindi assegnare un progetto o una cartella alla prenotazione, che utilizzerà solo gli slot inattivi.

Compiti di tipo ML_EXTERNAL sono un'eccezione in quanto gli slot utilizzati dai job di creazione di modelli esterni di BigQuery ML non sono preassegnabili. 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 gli slot inattivi di altre 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.

Il programmatore BigQuery applica la condivisione equa degli slot tra i progetti con query in esecuzione all'interno di una prenotazione e poi all'interno dei job di un determinato progetto. Il programmatore garantisce l'equità. Per brevi periodi, alcuni job potrebbero ricevere una quota sproporzionata di slot, ma lo schedulatore corregge infine il problema. Lo scopo dello scheduler è trovare un equilibrio tra l'espulsione aggressiva delle attività in esecuzione (che comporta lo spreco di tempo di slot) e l'essere troppo permissivo (che comporta l'assegnazione a job con attività in esecuzione prolungata di una quota sproporzionata del tempo di slot).

Se un job importante ha costantemente bisogno di più slot di quelli che riceve dall'organizzatore, valuta la possibilità di creare una prenotazione aggiuntiva con un numero garantito di slot e di assegnarlo a quella prenotazione.

Utilizzo eccessivo degli slot

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 viene attribuito solo ai job che ricevono più della loro quota equa.

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 dall'utilizzo degli slot registrato, ad eccezione di alcune statistiche dettagliate sull'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 di slot è limitato a una piccola parte della tua capacità totale di slot.

Pianificazione equa in BigQuery

Gli slot vengono 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 dinamicamente e automaticamente tra le query attive man mano che le richieste di capacità di ciascuna query cambiano. Le query vengono completate e le 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à consumata dalla query diventa automaticamente disponibile per tutte le altre query.
• Ogni volta che la domanda di capacità di una query cambia a causa di modifiche al DAG dinamico della query, BigQuery rivaluta automaticamente la disponibilità della capacità per questa e per tutte le altre query, riallocando e mettendo in pausa gli slot in base alle necessità.

Pianificazione equa in BigQuery

A seconda della complessità e delle dimensioni, una query potrebbe non richiedere tutti gli slot a 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.