Incorporato nei job di query, BigQuery include la diagnostica
sul piano di query e sulle tempistiche. Queste informazioni sono simili alle informazioni fornite
da istruzioni come EXPLAIN
in altri database e sistemi di analisi. Questo
le informazioni possono essere recuperate dalle risposte API di metodi come
jobs.get
BigQuery aggiornerà periodicamente le query a lunga esecuzione statistiche. Questi aggiornamenti vengono eseguiti indipendentemente dalla frequenza con cui il job lo stato è oggetto di polling, ma in genere non si verifica più di 30 volte secondi. Inoltre, i job di query che non utilizzano risorse di esecuzione, come come richieste dry run o risultati che possono essere forniti dai risultati memorizzati nella cache, includere informazioni diagnostiche aggiuntive, sebbene altre statistiche possano presenti.
Sfondo
Quando BigQuery esegue un job di query, converte un'istruzione SQL dichiarativa in un grafico di esecuzione, suddiviso in una serie fasi delle query, che a loro volta sono composte da insiemi più granulari di steps di esecuzione. BigQuery sfrutta un'ampia gamma di un'architettura parallela distribuita per eseguire queste query. Le fasi modellano le unità di lavoro che molti potenziali worker possono eseguire in parallelo. Le fasi comunicano tramite un'architettura di shuffle distribuita e veloce.
All'interno del piano di query, i termini unità di lavoro e lavoratori vengono utilizzati per indicare
informazioni specifiche sul parallelismo. Altrove,
in BigQuery, potresti incontrare il termine slot, ovvero una
rappresentazione astratta di più facet dell'esecuzione di una query, tra cui
risorse di computing, memoria e I/O. Le statistiche di primo livello sui job offrono
stima del costo di una singola query utilizzando la stima totalSlotMs
della query
utilizzando questa contabilità astratta.
Un'altra importante proprietà dell'architettura di esecuzione delle query è che dinamico, il che significa che il piano di query può essere modificato mentre è in esecuzione una query. Le fasi introdotte mentre una query è in esecuzione sono spesso utilizzate per migliorare la distribuzione dei dati tra i worker di query. Nei piani di query in cui ciò si verifica, queste fasi sono in genere etichettate come fasi di ripartizione.
Oltre al piano di query, i job di query espongono anche una sequenza temporale di dell'esecuzione, che fornisce una contabilità delle unità di lavoro completate in attesa e attivi all'interno dei worker di query. Una query può avere più fasi con i lavoratori attivi contemporaneamente e la sequenza temporale ha lo scopo di mostrare l'avanzamento complessivo della query.
Visualizzazione delle informazioni con la console Google Cloud
Nella console Google Cloud, puoi vedere i dettagli del piano di query per una query completata facendo clic Pulsante Dettagli esecuzione (vicino al pulsante Risultati).
Informazioni sul piano di query
All'interno della risposta dell'API, i piani di query sono rappresentati come un elenco di fasi della query. Ogni voce dell'elenco mostra le statistiche di panoramica per fase, i passaggi dettagliati informazioni e le classificazioni delle tempistiche delle fasi. Non vengono visualizzati tutti i dettagli all'interno della console Google Cloud, ma possono essere tutte presenti all'interno dell'API diverse.
Panoramica della fase
I campi Panoramica di ogni fase possono includere quanto segue:
Campo API | Descrizione |
---|---|
id |
ID numerico univoco per la fase. |
name |
Nome semplice riepilogativo della fase. Il steps all'interno della fase fornisce ulteriori dettagli sui passaggi di esecuzione. |
status |
Stato di esecuzione della fase. I possibili stati sono IN ATTESA, IN ESECUZIONE, COMPLETATA, NON RIUSCITA e ANNULLATA. |
inputStages |
Un elenco degli ID che formano il grafico delle dipendenze della fase. Ad esempio, una fase di JOIN spesso ha bisogno di due fasi dipendenti che preparano i dati sul lato sinistro e destro della relazione di JOIN. |
startMs |
Timestamp, in millisecondi di epoca, che rappresenta quando ha iniziato l'esecuzione del primo worker nella fase. |
endMs |
Timestamp, in millisecondi di epoca, che rappresenta il momento in cui l'ultimo worker ha completato l'esecuzione. |
steps |
Elenco più dettagliato dei passaggi di esecuzione nella fase. Per ulteriori informazioni, consulta la sezione successiva. |
recordsRead |
Inserisci le dimensioni della fase come numero di record, tra tutti i worker della fase. |
recordsWritten |
Dimensioni di output della fase come numero di record, tra tutti i worker della fase. |
parallelInputs |
Numero di unità di lavoro parallelizzabili per la fase. A seconda della fase e della query, questo può rappresentare il numero di segmenti a colonne all'interno di una tabella o il numero di partizioni in uno shuffling intermedio. |
completedParallelInputs |
Numero di unità nella fase completate. Per alcune query, non è necessario completare tutti gli input all'interno di una fase affinché quest'ultima venga completata. |
shuffleOutputBytes |
Rappresenta i byte totali scritti su tutti i worker in una fase di query. |
shuffleOutputBytesSpilled |
Per le query che trasmettono dati significativi tra le fasi potrebbe essere necessario ricorrere alla trasmissione basata su disco. La statistica dei byte sversati comunica la quantità di dati sversati sul disco. Dipende da un algoritmo di ottimizzazione, quindi non è deterministico per una determinata query. |
Informazioni sui passaggi per fase
I passaggi rappresentano le operazioni più granulari che ogni worker all'interno di una fase devono essere eseguite, presentate come un elenco ordinato di operazioni. I passaggi sono classificati, e alcune operazioni forniscono informazioni più dettagliate. L'operazione le categorie presenti nel piano di query includono:
Passaggio | Descrizione |
---|---|
LEGGI | Lettura di una o più colonne da una tabella di input o da uno shuffling intermedio. Nei dettagli del passaggio vengono restituite solo le prime sedici colonne lette. |
SCRIVI | Una scrittura di una o più colonne in una tabella di output o risultato intermedio. Per gli output partizionati HASH di una fase, sono incluse anche le colonne utilizzate come chiave di partizione. |
COMPUTING | Operazioni come la valutazione delle espressioni e le funzioni SQL. |
FILTRO | Operatore che implementa le clausole WHERE, OMIT IF e HAVING. |
ORDINA | Operazione di ordinamento o Ordine per, include le chiavi di colonna e la direzione di ordinamento. |
AGGREGA | Un'operazione di aggregazione, ad esempio GROUP BY o COUNT. |
LIMIT | Operatore che implementa la clausola LIMIT. |
JOIN | Un'operazione JOIN, che include il tipo di join e le colonne utilizzate. |
ANALYTIC_FUNCTION | Il richiamo di una funzione finestra (nota anche come "funzione analitica"). |
USER_DEFINED_FUNCTION | Una chiamata a una funzione definita dall'utente. |
Classificazione delle tempistiche per fase
Le fasi della query forniscono inoltre classificazioni delle tempistiche della fase, sia in termini e in forma assoluta. Poiché ogni fase dell'esecuzione rappresenta il lavoro intrapreso da una più indipendenti, le informazioni sono fornite sia nella media che nei momenti peggiori. Questi tempi rappresentano le prestazioni medie di tutti i worker in una fase, nonché le prestazioni dei worker più lenti della coda lunga per un classificazione. I tempi medi e massimi sono inoltre suddivisi in rappresentazioni assolute e relative. Per la statistica basata su un rapporto, i dati vengono fornita come frazione del tempo più lungo trascorso da un worker in qualsiasi segmento.
La console Google Cloud presenta le tempistiche della fase utilizzando le tempistiche relative rappresentazioni grafiche.
Le informazioni sulle tempistiche della fase sono riportate come segue:
Tempistica relativa | Tempistica assoluta | numeratore di rapporto |
---|---|---|
waitRatioAvg |
waitMsAvg |
Tempo che il worker medio ha trascorso in attesa di essere pianificato. |
waitRatioMax |
waitMsMax |
Tempo trascorso dal worker più lento in attesa di essere pianificato. |
readRatioAvg |
readMsAvg |
Tempo che il worker medio ha trascorso a leggere i dati di input. |
readRatioMax |
readMsMax |
Tempo trascorso dal worker più lento a leggere i dati di input. |
computeRatioAvg |
computeMsAvg |
Tempo di utilizzo medio della CPU da parte del worker. |
computeRatioMax |
computeMsMax |
Tempo in cui il worker più lento ha speso il limite della CPU. |
writeRatioAvg |
writeMsAvg |
Tempo medio impiegato dal worker per scrivere i dati di output. |
writeRatioMax |
writeMsMax |
Tempo impiegato dal worker più lento a scrivere dati di output. |
Spiegazione per le query federate
Le query federate ti consentono di inviare una query
l'istruzione di query a un'origine dati esterna
Funzione EXTERNAL_QUERY
.
Le query federate sono soggette alla tecnica di ottimizzazione nota come
Push-down SQL e
di query mostra le eventuali operazioni sottoposte a push all'origine dati esterna.
Ad esempio, se esegui questa query:
SELECT id, name
FROM EXTERNAL_QUERY("<connection>", "SELECT * FROM company")
WHERE country_code IN ('ee', 'hu') AND name like '%TV%'
Il piano di query mostrerà i seguenti passaggi di fase:
$1:id, $2:name, $3:country_code
FROM table_for_external_query_$_0(
SELECT id, name, country_code
FROM (
/*native_query*/
SELECT * FROM company
)
WHERE in(country_code, 'ee', 'hu')
)
WHERE and(in($3, 'ee', 'hu'), like($2, '%TV%'))
$1, $2
TO __stage00_output
In questo piano, table_for_external_query_$_0(...)
rappresenta
Funzione EXTERNAL_QUERY
. Tra parentesi puoi vedere la query
un'origine dati esterna. Di conseguenza, puoi notare che:
- Un'origine dati esterna restituisce solo tre colonne selezionate.
- Un'origine dati esterna restituisce solo le righe per le quali
country_code
è'ee'
o'hu'
. - L'operatore
LIKE
non esegue il push-down e viene valutato da in BigQuery.
Per fare un confronto, se non sono presenti creatività push-down, il piano di query mostrerà i seguenti passaggi della fase:
$1:id, $2:name, $3:country_code
FROM table_for_external_query_$_0(
SELECT id, name, description, country_code, primary_address, secondary address
FROM (
/*native_query*/
SELECT * FROM company
)
)
WHERE and(in($3, 'ee', 'hu'), like($2, '%TV%'))
$1, $2
TO __stage00_output
Questa volta un'origine dati esterna restituisce tutte le colonne e tutte le righe da
la tabella company
e BigQuery applica i filtri.
Metadati Timeline
La sequenza temporale delle query riporta l'avanzamento in momenti specifici, fornendo di istantanee dell'avanzamento complessivo delle query. La sequenza temporale è rappresentata da serie di esempi che riportano i seguenti dettagli:
Campo | Descrizione |
---|---|
elapsedMs |
Sono trascorsi i millisecondi dall'inizio dell'esecuzione della query. |
totalSlotMs |
Una rappresentazione cumulativa dei millisecondi di slot utilizzati dalla query. |
pendingUnits |
Unità totali di lavoro pianificate e in attesa di esecuzione. |
activeUnits |
Unità di lavoro attive totali elaborate dai worker. |
completedUnits |
Unità totali di lavoro completate durante l'esecuzione di questa query. |
Una query di esempio
La seguente query conteggia il numero di righe nel pubblico di Shakespeare set di dati e ha un secondo conteggio condizionale che limita i risultati alle righe che fanno riferimento ad "hamlet":
SELECT
COUNT(1) as rowcount,
COUNTIF(corpus = 'hamlet') as rowcount_hamlet
FROM `publicdata.samples.shakespeare`
Fai clic su Dettagli esecuzione per visualizzare il piano di query:
Gli indicatori di colore mostrano i tempi relativi per tutti i passaggi in tutte le fasi.
Per ulteriori informazioni sui passaggi delle fasi di esecuzione, fai clic su
per espandere i dettagli della fase:In questo esempio, il tempo più lungo in un segmento è stato il tempo trascorso dal singolo worker nella fase 01 in attesa del completamento della fase 00. Questo perché la fase 01 dipendeva dall'input della fase 00 e non è stato possibile avviarla fino a quando la prima fase ha scritto il suo output in uno shuffle intermedio.
Error Reporting
È possibile che i job di query non vadano a buon fine durante l'esecuzione. Poiché le informazioni sul piano viene aggiornata periodicamente, puoi osservare in che punto del grafico di esecuzione si è verificato un errore. Nella console Google Cloud, riusciti o non riusciti i livelli sono contrassegnati da un segno di spunta o da un punto esclamativo accanto al nome.
Per ulteriori informazioni su come interpretare e correggere gli errori, consulta guida alla risoluzione dei problemi.
Rappresentazione di esempio API
Le informazioni sul piano di query sono incorporate nelle informazioni di risposta al job e
puoi recuperarlo richiamando
jobs.get
Ad esempio:
il seguente estratto di una risposta JSON per un job
la restituzione della query di esempio di Hamlet mostra sia il piano di query sia la sequenza temporale
informazioni.
"statistics": { "creationTime": "1576544129234", "startTime": "1576544129348", "endTime": "1576544129681", "totalBytesProcessed": "2464625", "query": { "queryPlan": [ { "name": "S00: Input", "id": "0", "startMs": "1576544129436", "endMs": "1576544129465", "waitRatioAvg": 0.04, "waitMsAvg": "1", "waitRatioMax": 0.04, "waitMsMax": "1", "readRatioAvg": 0.32, "readMsAvg": "8", "readRatioMax": 0.32, "readMsMax": "8", "computeRatioAvg": 1, "computeMsAvg": "25", "computeRatioMax": 1, "computeMsMax": "25", "writeRatioAvg": 0.08, "writeMsAvg": "2", "writeRatioMax": 0.08, "writeMsMax": "2", "shuffleOutputBytes": "18", "shuffleOutputBytesSpilled": "0", "recordsRead": "164656", "recordsWritten": "1", "parallelInputs": "1", "completedParallelInputs": "1", "status": "COMPLETE", "steps": [ { "kind": "READ", "substeps": [ "$1:corpus", "FROM publicdata.samples.shakespeare" ] }, { "kind": "AGGREGATE", "substeps": [ "$20 := COUNT($30)", "$21 := COUNTIF($31)" ] }, { "kind": "COMPUTE", "substeps": [ "$30 := 1", "$31 := equal($1, 'hamlet')" ] }, { "kind": "WRITE", "substeps": [ "$20, $21", "TO __stage00_output" ] } ] }, { "name": "S01: Output", "id": "1", "startMs": "1576544129465", "endMs": "1576544129480", "inputStages": [ "0" ], "waitRatioAvg": 0.44, "waitMsAvg": "11", "waitRatioMax": 0.44, "waitMsMax": "11", "readRatioAvg": 0, "readMsAvg": "0", "readRatioMax": 0, "readMsMax": "0", "computeRatioAvg": 0.2, "computeMsAvg": "5", "computeRatioMax": 0.2, "computeMsMax": "5", "writeRatioAvg": 0.16, "writeMsAvg": "4", "writeRatioMax": 0.16, "writeMsMax": "4", "shuffleOutputBytes": "17", "shuffleOutputBytesSpilled": "0", "recordsRead": "1", "recordsWritten": "1", "parallelInputs": "1", "completedParallelInputs": "1", "status": "COMPLETE", "steps": [ { "kind": "READ", "substeps": [ "$20, $21", "FROM __stage00_output" ] }, { "kind": "AGGREGATE", "substeps": [ "$10 := SUM_OF_COUNTS($20)", "$11 := SUM_OF_COUNTS($21)" ] }, { "kind": "WRITE", "substeps": [ "$10, $11", "TO __stage01_output" ] } ] } ], "estimatedBytesProcessed": "2464625", "timeline": [ { "elapsedMs": "304", "totalSlotMs": "50", "pendingUnits": "0", "completedUnits": "2" } ], "totalPartitionsProcessed": "0", "totalBytesProcessed": "2464625", "totalBytesBilled": "10485760", "billingTier": 1, "totalSlotMs": "50", "cacheHit": false, "referencedTables": [ { "projectId": "publicdata", "datasetId": "samples", "tableId": "shakespeare" } ], "statementType": "SELECT" }, "totalSlotMs": "50" },
Utilizzo delle informazioni di esecuzione
I piani di query di BigQuery forniscono informazioni su come il servizio esegue delle query, ma la natura gestita dei limiti del servizio se alcuni dettagli sono direttamente attuabili. Vengono effettuate molte ottimizzazioni automaticamente utilizzando il servizio, che può essere diverso da in cui l'ottimizzazione, il provisioning e il monitoraggio possono richiedere servizi personale competente.
Per tecniche specifiche che possono migliorare l'esecuzione e le prestazioni delle query, consulta il documentazione sulle best practice. Le statistiche relative al piano di query e alla cronologia possono aiutarti a capire se alcune fasi per controllare l'utilizzo delle risorse. Ad esempio, una fase di JOIN che genera molto un numero maggiore di righe di output rispetto alle righe di input può indicare un'opportunità di filtrare in anticipo nella query.
Inoltre, le informazioni sulla sequenza temporale possono aiutare a capire se una determinata query che rallenta l'isolamento o a causa degli effetti di altre query che si contendono gli stessi Google Cloud. Se noti che il numero di unità attive rimane limitato durante l'intera durata della query, ma il numero di unità in coda di lavoro rimane elevato, ciò può rappresentare casi in cui la riduzione del numero delle query in parallelo può migliorare significativamente il tempo di esecuzione complessivo per determinate query.