Informazioni sugli slot

Uno slot BigQuery è un'unità di calcolo virtuale utilizzata da BigQuery per eseguire query SQL o altri tipi di job. Durante l'esecuzione di una query, BigQuery determina automaticamente quanti slot vengono utilizzati dalla query. Il numero di slot utilizzati dipende dalla quantità di dati elaborati, dalla complessità della query e dal numero di slot disponibili. In generale, l'accesso a più slot ti consente di eseguire più query simultanee e le query complesse possono essere eseguite più velocemente.

Sebbene tutte le query utilizzino gli slot, hai due opzioni per la modalità di addebito dell'utilizzo: il modello di prezzo on demand o il modello di prezzo basato sulla capacità.

Per impostazione predefinita, l'addebito viene effettuato utilizzando il modello on demand. Con questo modello, ti viene addebitato l'importo dei dati elaborati (misurato in TiB) da ogni query. I progetti che utilizzano il modello on demand sono soggetti a limiti di slot per progetto e per organizzazione con capacità di burst transitorio. La maggior parte degli utenti del modello on demand ritiene che i limiti di capacità degli slot siano più che sufficienti. Tuttavia, a seconda del carico di lavoro, l'accesso a più slot potrebbe migliorare il rendimento delle query. Per verificare quanti slot utilizza il tuo account, consulta la documentazione sul monitoraggio di BigQuery.

Con il modello basato sulla capacità, paghi la capacità degli slot allocata per le tue query nel tempo. Questo modello ti offre un controllo esplicito sulla capacità totale degli slot, a differenza del modello on demand. Scegli esplicitamente la quantità di slot da utilizzare tramite una prenotazione. Puoi specificare la quantità di slot in una prenotazione come quantità di base sempre allocata o come quantità scalata automaticamente, che viene allocata quando necessario.

Esecuzione delle query utilizzando gli slot

Quando BigQuery esegue un job di query, converte l'istruzione SQL in un piano di esecuzione, suddiviso in una serie di fasi della 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. I dati vengono trasferiti tra le fasi utilizzando un'architettura di shuffle distribuito veloce, che viene discussa in modo più dettagliato nel Google Cloud blog.

L'esecuzione delle query BigQuery è dinamica, il che significa che il piano di query può essere modificato mentre una query è in corso. Le fasi introdotte durante l'esecuzione di una query vengono spesso utilizzate per migliorare la distribuzione dei dati tra i worker di query. Inoltre, l'esecuzione delle query potrebbe essere influenzata dalla quantità variabile di capacità disponibile man mano che altre query vengono completate o iniziano l'esecuzione oppure gli slot vengono aggiunti alla prenotazione dallo strumento di scalabilità automatica.

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

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

Grafico di esecuzione delle query di fasi e passaggi

Economia delle risorse slot

Se una query richiede più slot di quelli disponibili, BigQuery mette in coda singole unità di lavoro 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 piuttosto un'indicazione del fattore di parallelizzazione più ottimale scelto da BigQuery per quella fase. Le unità di lavoro vengono messe in coda ed eseguite man mano che gli slot diventano disponibili.

Quando le richieste di query superano gli slot per cui hai effettuato l'impegno, non ti vengono addebitati slot aggiuntivi e non ti vengono addebitate tariffe on demand aggiuntive. Le tue singole unità di lavoro vengono messe in coda.

Ad esempio,

1. Una fase della query richiede 2000 slot, ma ne sono disponibili solo 1000.
2. BigQuery utilizza tutti i 1000 slot e mette in coda gli altri 1000 slot.
3. Successivamente, se 100 slot terminano il lavoro, prelevano dinamicamente 100 unità di lavoro dalle 1000 unità di lavoro in coda. Rimangono 900 unità di lavoro in coda.
4. Successivamente, se 500 slot terminano il lavoro, prelevano 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à

Pianificazione equa in BigQuery

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

Lo scheduler 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. Lo scheduler garantisce l'equità nel tempo. Durante periodi brevi, alcuni job potrebbero ottenere una quota sproporzionata di slot, ma lo scheduler alla fine corregge questo problema. Lo scopo dello scheduler è trovare un equilibrio tra l'eliminazione aggressiva delle attività in esecuzione (che comporta lo spreco di tempo di slot) e l'eccessiva indulgenza (che comporta una quota sproporzionata di tempo di slot per i job con attività a lunga esecuzione).

La pianificazione equa garantisce che ogni query abbia accesso a tutti gli slot disponibili in qualsiasi momento e che la capacità venga riassegnata in modo dinamico e automatico tra le query attive man mano che cambiano le esigenze di capacità di ciascuna query. Le query vengono completate e vengono inviate nuove query per l'esecuzione alle seguenti condizioni:

• Ogni volta che viene inviata una nuova query, la capacità viene automaticamente riassegnata alle query in esecuzione. Le singole unità di lavoro possono essere sospese, riprese e messe in coda in modo controllato man mano che diventa disponibile più capacità per ogni query.
• Ogni volta che una query viene completata, la capacità consumata da questa query diventa immediatamente disponibile per tutte le altre query.
• Ogni volta che le richieste di capacità di una query cambiano a causa di modifiche al DAG dinamico della query, BigQuery rivaluta automaticamente la disponibilità di capacità per questa e tutte le altre query, riassegnando 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, con una pianificazione equa, tutti gli slot possano essere utilizzati completamente in qualsiasi momento.

Se un job importante ha costantemente bisogno di più slot di quelli che riceve dallo scheduler, valuta la possibilità di creare una prenotazione aggiuntiva con il numero richiesto di slot e di assegnare il job a questa prenotazione.

Come esempio di pianificazione equa, supponiamo di avere la seguente configurazione della prenotazione:

• Prenotazione A, che ha 1000 slot di base senza scalabilità automatica
• Progetto A e progetto B, assegnati alla prenotazione

Scenario 1: nel progetto A esegui la query A (una query simultanea) che richiede un utilizzo elevato degli slot e nel progetto B esegui 20 query simultanee. Anche se ci sono un totale di 21 query che utilizzano A, la distribuzione degli slot è la seguente:

• Il progetto A riceve 500 slot e la query A viene eseguita con 500 slot.
• Il progetto B riceve 500 slot condivisi tra le 20 query.

Scenario 2: nel progetto A, esegui la query A (una query simultanea) che richiede 100 slot per l'esecuzione e nel progetto B esegui 20 query simultanee. Poiché la query A non richiede il 50% della prenotazione, la distribuzione degli slot è la seguente:

• Il progetto A riceve 100 slot e la query A viene eseguita con 100 slot.
• Il progetto B riceve 900 slot condivisi tra le 20 query.

Al contrario, considera la seguente configurazione della prenotazione:

• Prenotazione B, che ha 1000 slot di base senza scalabilità automatica.
• 10 progetti, tutti assegnati alla prenotazione B.

Supponiamo che i 10 progetti eseguano query con una domanda di slot sufficiente, quindi ogni progetto riceve 1/10 degli slot di prenotazione totali (o 100 slot), indipendentemente dal numero di query in esecuzione su ciascun progetto.

Quote e limiti degli slot

Le quote e i limiti degli slot forniscono una salvaguardia per BigQuery. I diversi modelli di prezzo utilizzano tipi di quota slot diversi, come segue:

• Modello di prezzi on demand: sei soggetto a un limite di slot per progetto e organizzazione con capacità di burst temporaneo. A seconda dei tuoi workload, l'accesso a più slot può migliorare il rendimento delle query.

• Modello di prezzi basato sulla capacità: le quote e i limiti delle prenotazioni definiscono il numero massimo di slot che puoi allocare in tutte le prenotazioni in una località. Ti vengono addebitati solo i costi per le prenotazioni e gli impegni, non per le quote. Per informazioni su come aumentare la quota di slot, consulta la pagina Richiesta di aumento della quota.

Per verificare quanti slot stai utilizzando, consulta la sezione Monitoraggio di BigQuery.

Slot inattivi

In un dato momento, alcuni slot potrebbero essere inattivi. Questi possono includere:

• Impegni slot non allocati a nessuna base di riferimento della prenotazione.
• Slot allocati a una base di riferimento della prenotazione, ma non in uso.

Gli slot inattivi non sono applicabili quando utilizzi il modello di prezzo on demand.

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 vengono preempted rapidamente. Potrebbe verificarsi un breve periodo di tempo in cui il consumo totale di slot supera il massimo specificato in tutte le prenotazioni, ma non ti viene addebitato questo utilizzo aggiuntivo di slot.

Ad esempio, supponiamo di avere la seguente configurazione della 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.

Hai corso query_b in project_b. Se non è in esecuzione alcuna query in project_a, allora query_b ha accesso ai 500 slot inattivi di reservation_a. Mentre query_b è ancora in esecuzione, può 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ò utilizzare 500 slot.

• Poiché hai 500 slot di base riservati per project_a, query_a inizia immediatamente e gli vengono assegnati 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 hanno slot sufficienti per essere avviate, vengono messe in coda finché le query in esecuzione non vengono completate e gli slot non diventano disponibili.

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 metterebbe in pausa query_b finché non sono disponibili slot inattivi o la query non va in timeout. Le query aggiuntive in project_b verranno messe in coda finché non saranno disponibili slot inattivi.

Per assicurarti che una prenotazione utilizzi solo gli slot di cui è stato eseguito il provisioning, imposta ignore_idle_slots su true. Tuttavia, le prenotazioni con ignore_idle_slots impostato su true possono condividere i propri slot inattivi con altre prenotazioni.

Non puoi condividere slot inattivi tra prenotazioni di versioni diverse. Puoi condividere solo gli slot di base o gli slot impegnati. Gli slot con scalabilità automatica 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 numero di slot pari a 0 e avere comunque accesso agli slot inutilizzati. Se utilizzi solo la default prenotazione, disattiva ignore_idle_slots come best practice. Puoi quindi assegnare un progetto o una cartella a quella prenotazione e utilizzerà solo gli slot inattivi.

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

Equità basata sulla prenotazione

Con la distribuzione equa basata sulla prenotazione, BigQuery assegna la priorità e alloca gli slot inattivi in modo equo a tutte le prenotazioni all'interno dello stesso progetto amministrativo, indipendentemente dal numero di progetti che eseguono job in ogni prenotazione. Ogni prenotazione riceve una quota simile della capacità disponibile nel pool di slot inattivi, quindi i suoi slot vengono distribuiti equamente all'interno dei progetti. Questa funzionalità è supportata solo con le versioni Enterprise o Enterprise Plus.

Il seguente grafico mostra come vengono distribuiti gli slot inattivi senza l'equità basata sulla prenotazione attivata:

In questo grafico, gli slot inattivi vengono condivisi equamente tra i progetti.

Se l'equità basata sulle prenotazioni non è attivata, gli slot inattivi disponibili vengono distribuiti in modo uniforme tra i progetti all'interno delle prenotazioni.

Il seguente grafico mostra come vengono distribuiti gli slot inattivi con l'equità basata sulla prenotazione abilitata:

In questo grafico, gli slot inattivi vengono condivisi equamente tra le prenotazioni, non tra i progetti.

Con l'equità basata sulla prenotazione attivata, gli slot inattivi disponibili vengono distribuiti equamente tra le prenotazioni.

Quando abiliti la distribuzione equa basata sulla prenotazione, esamina il consumo di risorse per gestire la disponibilità degli slot e le prestazioni delle query.

Evita di fare affidamento esclusivamente sugli slot inattivi per i carichi di lavoro di produzione con requisiti di tempo rigorosi. Questi job devono utilizzare slot di base o con scalabilità automatica. Ti consigliamo di utilizzare slot inattivi per i job a priorità più bassa, perché gli slot possono essere interrotti in qualsiasi momento.

Utilizzo eccessivo degli slot

Quando un job mantiene gli slot per troppo tempo, può ricevere una quota ingiusta di slot. Per evitare ritardi, BigQuery consente ad altri job di prendere in prestito slot aggiuntivi, con conseguenti periodi di utilizzo totale degli slot superiore alla capacità specificata. L'utilizzo di slot in eccesso viene attribuito solo ai job che ricevono più della loro quota equa.

Gli slot in eccesso non ti vengono addebitati direttamente. I job continuano a essere eseguiti e ad accumulare l'utilizzo degli slot in modo equo finché tutto l'utilizzo in eccesso non viene coperto dalla capacità allocata. Gli slot in eccesso sono esclusi dall'utilizzo degli slot segnalato, ad eccezione di alcune statistiche di esecuzione dettagliate.

Tieni presente che è possibile un prestito preventivo di slot per ridurre i ritardi futuri e fornire altri vantaggi, come una variabilità ridotta dei costi degli slot e una latenza finale ridotta. Il prestito di slot è limitato a una piccola frazione della capacità totale degli slot.