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 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 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 usano il modello di prezzi basato sulla capacità scelgono esplicitamente quanti slot di riserva. 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 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 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 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 ti fornisca 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 le prestazioni dei dispositivi.

Puoi anche esaminare l'utilizzo attuale degli slot dei tuoi progetti, insieme 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, vedi Visualizzazione degli slot disponibili e degli slot 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, consulta Stimare i requisiti di capacità degli slot.

Esecuzione di query utilizzando gli slot

Quando BigQuery esegue un job di query, converte il testo L'istruzione SQL in un grafico di esecuzione, suddivisa in una serie di query fasi, che a loro volta sono composte da insiemi di esecuzioni più granulari passaggi. 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 con usando una velocità architettura shuffle distribuita, che verrà discusso più in dettaglio 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. Fasi che introdotte durante l'esecuzione di una query vengono spesso usati per migliorare i dati la distribuzione tra i worker delle query.

BigQuery può eseguire più fasi contemporaneamente. BigQuery può utilizzare l'esecuzione speculativa per accelerare le query e BigQuery può ripartizione dinamica una fase per ottenere il caricamento in contemporanea ottimale.

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

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 illimitato di slot per una fase specifica 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. 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. Il tuo singole unità di lavoro in coda.

Ad esempio,

1. Una fase 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. In seguito, se 100 slot completano il loro lavoro, raccolgono dinamicamente 100 unità di lavoro dalle 1000 unità di lavoro 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. Rimangono 400 unità di lavoro in coda.

Slot BigQuery in coda se la domanda supera la disponibilità

Slot inattivi

Alcuni slot potrebbero essere inattivi in un determinato momento. Ecco alcuni esempi:

• 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 in esecuzione in una prenotazione utilizzano automaticamente gli slot inattivi da ad 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, immagina di avere la seguente configurazione delle prenotazioni:

• project_a è assegnato a reservation_a, che ha 500 slot di riferimento con senza scalabilità automatica.
• project_b è assegnato a reservation_b, che ha 100 slot di riferimento con senza scalabilità automatica.
• Le prenotazioni si trovano nello stesso progetto amministrativo e non esistono con altri progetti assegnati 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 inattivi di reservation_a. Mentre query_b è ancora in esecuzione, può utilizzare fino a 600 slot: 100 slot di riferimento più 500 slot inattivi slot machine.

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 hanno abbastanza slot per l'avvio, vengono messe in coda finché le query attualmente in esecuzione non vengono completate e non diventano disponibili gli slot.

In questo esempio, se project_b è stato assegnato a una prenotazione senza valore di riferimento slot o scalabilità automatica, query_b non avrà slot dopo l'avvio di query_a in esecuzione. 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 assicurarti che una prenotazione utilizzi solo gli annunci provisionati, 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 in slot impegnati. 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 degli slot di0 e avere comunque accesso agli slot inutilizzati. Se utilizzi solo default su prenotazione, disattiva ignore_idle_slots come best practice. Puoi e poi assegnare un progetto cartella a quella prenotazione e userà solo slot inattivi.

Le assegnazioni 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 degli slot all'interno delle prenotazioni

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

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. Lo scheduler fornisce equità finale. Durante la breve periodi di tempo, alcuni job potrebbero ricevere una quota sproporzionata di slot, ma lo scheduler alla fine lo corregge. 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 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 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 generando dei periodi dell'utilizzo totale degli slot superiore alla capacità slot 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 e accumulare l'utilizzo degli slot con la giusta quota fino a quando è coperto dalla capacità normale. Gli slot in eccesso sono esclusi dall'utilizzo degli slot registrato, ad eccezione di alcune statistiche dettagliate sull'esecuzione.

Tieni presente che un po' di prestito preventivo degli slot può avvenire per ridurre il ritardi e per offrire altri vantaggi come la riduzione della variabilità dei costi degli slot e latenza ridotta. Il prestito slot è limitato a una piccola frazione di la capacità totale degli slot.

Buona pianificazione 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 e la capacità viene riallocata in modo dinamico e automatico tra man mano che la capacità di ogni query cambia. 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 da tale query diventa immediatamente 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à.

Pianificazione equa in BigQuery

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