Incorporado dentro de los trabajos de consulta, BigQuery incluye el plan de consulta de diagnóstico y la información del tiempo. Esto es similar a la información que proporcionan declaraciones como EXPLAIN en otras bases de datos y sistemas analíticos. Esta información se puede recuperar a partir de las respuestas de la API de métodos como jobs.get.
BigQuery actualizará de forma periódica estas estadísticas para las consultas de larga duración. Estas actualizaciones ocurren sin importar la velocidad a la que se consulta el estado del trabajo, pero, por lo general, su frecuencia máxima será cada 30 segundos. Además, los trabajos de consulta que no aprovechan los recursos de ejecución, como las solicitudes o los resultados de las ejecuciones de prueba que pueden entregarse a partir de los resultados almacenados en caché, no incluirán la información de diagnóstico adicional, aunque es posible que otras estadísticas estén presentes.
Fondo
Cuando BigQuery ejecuta un trabajo de consulta, convierte la instrucción de SQL en un grafo de ejecución dividido en una serie de etapas de consulta, que se componen de conjuntos de pasos de ejecución más detallados. BigQuery aprovecha una arquitectura en paralelo muy distribuida para ejecutar estas consultas. Las etapas modelan las unidades de trabajo que muchos trabajadores potenciales pueden ejecutar en paralelo. Las etapas se comunican entre sí mediante una arquitectura aleatoria de distribución rápida, sobre la que puedes leer en Ejecución de consultas en memoria en BigQuery.
En el plan de consulta, los términos unidades de trabajo y trabajadores se usan para transmitir información específicamente sobre el paralelismo. En otras partes de BigQuery, puede aparecer el término ranura, que es una representación abstracta de varias facetas de la ejecución de consultas, incluidos los recursos de procesamiento, de memoria y de E/S. Las estadísticas de trabajo principales proporcionan la estimación del costo de consulta individual mediante la estimación totalSlotMs de la consulta que usa esta contabilidad abstracta.
Otra propiedad importante de la arquitectura de ejecución de consultas es que es dinámica, lo que significa que el plan de consulta se puede modificar mientras se ejecuta una consulta. Las etapas que se ingresan mientras se ejecuta una consulta se suelen usar para mejorar la distribución de datos en todos los trabajadores de consulta. En los planes de consulta en los que esto ocurre, estas etapas suelen etiquetarse como etapas de partición.
Además del plan de consulta, los trabajos de consulta exponen un cronograma de ejecución que proporciona un conteo de unidades de trabajo completadas, pendientes y activas dentro de los trabajadores de consulta. Una consulta puede tener varias etapas con trabajadores activos de forma simultánea. En el cronograma se debe mostrar el progreso general de la consulta.
Visualiza información con Cloud Console
En Cloud Console, puedes ver los detalles del plan de consultas de una que se haya completado. Para ello, haz clic en el botón Detalles de la ejecución (que está cerca de Resultados).
Información del plan de consultas
Dentro de la respuesta de la API, los planes de consultas se representan como una lista de etapas de consulta. Cada elemento de la lista muestra estadísticas de descripción general por etapa, información detallada de los pasos y clasificaciones del tiempo de las etapas. No todos los detalles se procesan en Cloud Console, pero todos pueden estar presentes en las respuestas de la API.
Descripción general de la etapa
Los campos de descripción general de cada etapa pueden incluir lo siguiente:
| Campo de API | Descripción |
|---|---|
id |
ID numérico exclusivo para la etapa. |
name |
Nombre de resumen sencillo de la etapa. Los steps dentro de la etapa proporcionan detalles adicionales sobre los pasos de ejecución. |
status |
Estado de ejecución de la etapa. Entre los estados posibles, se incluyen PENDIENTE, EN EJECUCIÓN, COMPLETO, CON ERRORES Y CANCELADO. |
inputStages |
Una lista de los ID que forman el grafo de dependencia de la etapa. Por ejemplo, en una etapa JOIN, se suelen necesitar dos etapas dependientes que preparan los datos en el lado izquierdo y derecho de la relación JOIN. |
startMs |
Marca de tiempo en milisegundos de ciclo de entrenamiento, que representa el momento cuando el primer trabajador dentro de la etapa comenzó la ejecución. |
endMs |
Marca de tiempo en milisegundos de ciclo de entrenamiento, que representa el momento cuando el último trabajador completó la ejecución. |
steps |
Lista más detallada de pasos de ejecución dentro de la etapa. Consulta la siguiente sección para obtener más información. |
recordsRead |
Tamaño de entrada de la etapa como número de registros en todos los trabajadores de la etapa. |
recordsWritten |
Tamaño de salida de la etapa como número de registros en todos los trabajadores de la etapa. |
parallelInputs |
Número de unidades de trabajo que se pueden paralelizar para la etapa. Según la etapa y la consulta, esto puede representar la cantidad de segmentos de columnas de una tabla o la cantidad de particiones de un orden aleatorio intermedio. |
completedParallelInputs |
Número de unidades de trabajo en la etapa que se completaron. Para algunas consultas, no todas las entradas en una etapa deben completarse a fin de que la etapa se complete. |
shuffleOutputBytes |
Representa el total de bytes escritos en todos los trabajadores dentro de una etapa de consulta. |
shuffleOutputBytesSpilled |
Es posible que las consultas que transmiten datos importantes entre etapas deban recurrir a la transmisión basada en disco. La estadística de bytes volcados comunica la cantidad de datos volcados al disco. Depende de un algoritmo de optimización, por lo que no es determinista para ninguna consulta determinada. |
Información de pasos por etapa
Los pasos representan las operaciones más detalladas que cada trabajador dentro de una etapa debe ejecutar, presentado como una lista ordenada de operaciones. Los pasos se categorizan con algunas operaciones que proporcionan información más detallada. Las categorías de operación que se encuentran en el plan de consulta incluyen lo siguiente:
| Paso | Descripción |
|---|---|
| LECTURA | Lectura de una o más columnas desde una tabla de entrada o de orden aleatorio intermedio. |
| ESCRITURA | Escritura de una o más columnas en una tabla de salida o resultado intermedio. Para las salidas con particiones HASH de una etapa, esto también incluye las columnas que se usan como clave de partición. |
| PROCESAMIENTO | Operaciones como la evaluación de expresiones y funciones de SQL. |
| FILTRO | Operador que implementa las cláusulas WHERE, OMIT IF y HAVING. |
| SORT | Las operaciones SORT y ORDER-BY incluyen la dirección de clasificación y las claves de columna. |
| AGGREGATE | Una operación de agregación, como GROUP BY o COUNT. |
| LÍMITE | Operador que implementa la cláusula LIMIT. |
| JOIN | Operación JOIN que incluye el tipo de unión y las columnas que se usan. |
| ANALYTIC_FUNCTION | Invocación de una función analítica. |
| USER_DEFINED_FUNCTION | Llamada a una función definida por el usuario. |
Clasificación de tiempo por etapa
Las etapas de consulta también proporcionan clasificaciones de tiempo por etapa en forma relativa y absoluta. Como cada etapa de ejecución representa el trabajo que realizaron los trabajadores independientes, la información se proporciona en el tiempo promedio y en el peor de los casos. Estos tiempos representan el rendimiento promedio de todos los trabajadores de una etapa, así como el rendimiento del trabajador de cola larga más lento de una clasificación determinada. Además, los tiempos promedio y máximo se desglosan en representaciones absolutas y relativas. Para las estadísticas basadas en la proporción, los datos se proporcionan como una fracción del tiempo más prolongado que cualquier trabajador invirtió en cualquier segmento.
Cloud Console presenta el tiempo por etapas mediante las representaciones de tiempo relativas.
La información del tiempo por etapas se muestra de la siguiente manera:
| Tiempo relativo | Tiempo absoluto | Numerador de proporción |
|---|---|---|
waitRatioAvg |
waitMsAvg |
Tiempo que el trabajador promedio esperó para programarse. |
waitRatioMax |
waitMsMax |
Tiempo que el trabajador más lento esperó para programarse. |
readRatioAvg |
readMsAvg |
Tiempo que el trabajador promedio dedicó a leer datos de entrada. |
readRatioMax |
readMsMax |
Tiempo que el trabajador más lento dedicó a leer datos de entrada. |
computeRatioAvg |
computeMsAvg |
Tiempo que el trabajador promedio pasó vinculado a la CPU. |
computeRatioMax |
computeMsMax |
Tiempo que el trabajador más lento pasó vinculado a la CPU. |
writeRatioAvg |
writeMsAvg |
Tiempo que el trabajador promedio dedicó a escribir datos de salida. |
writeRatioMax |
writeMsMax |
Tiempo que el trabajador más lento dedicó a escribir datos de salida. |
Metadatos de cronograma
En los cronogramas de consultas, se informa el progreso en puntos específicos en el tiempo, lo que proporciona vistas instantáneas del progreso general de la consulta. El cronograma se representa como una serie de muestras en las que se informan los siguientes detalles:
| Campo | Descripción |
|---|---|
elapsedMs |
Milisegundos transcurridos desde el inicio de la ejecución de la consulta. |
totalSlotMs |
Una representación acumulativa de los milisegundos de ranura que usó la consulta. |
pendingUnits |
Total de unidades de trabajo programadas y en espera de ejecución. |
activeUnits |
Total de unidades de trabajo activas que los trabajadores procesan actualmente. |
completedUnits |
Total de unidades de trabajo que se completaron mientras se ejecutaba esta consulta. |
Consulta de ejemplo
En la siguiente consulta, se cuentan la cantidad de filas en el conjunto de datos públicos de Shakespeare. Esta tiene un segundo recuento condicional que restringe los resultados a las filas que hacen referencia a “hamlet”:
#StandardSQL
SELECT
COUNT(1) as rowcount,
COUNTIF(corpus = 'hamlet') as rowcount_hamlet
FROM `publicdata.samples.shakespeare`
En este ejemplo, se usa una tabla de muestra muy pequeña con una consulta simple, por lo que solo hay dos unidades de trabajo en total. Todo el trabajo se completa casi de inmediato.
Haz clic en Detalles de la ejecución para ver el plan de consulta:
Los indicadores de color muestran los tiempos relativos de todos los pasos en todas las etapas. Por ejemplo, el paso COMPUTE de la etapa 00 muestra una barra cuya fracción sombreada es 21/30, ya que 30 ms es el tiempo máximo empleado en un solo paso de cualquier etapa. La información de entrada en paralelo muestra que cada etapa requirió solo un trabajador, por lo que no hay variación entre los tiempos promedio y los más lentos.
Para obtener más información sobre los pasos de las etapas de ejecución, haz clic en el triángulo a fin de expandir los detalles de la etapa:
En este ejemplo, el tiempo más prolongado en cualquier segmento fue el tiempo que el trabajador único en la etapa 01 esperó a que se completara la etapa 00. Esto se debe a que la Etapa 01 dependía de la entrada de la Etapa 00, y no podía comenzar hasta que la primera etapa escribió su salida (1 fila, ~18 bytes) en orden aleatorio intermedio.
En el plan de ejecución del trabajador individual que completó el trabajo de la etapa 00 se muestra que primero se realizaron operaciones READ de los datos de la columna “corpus” de la tabla de Shakespeare referenciada. Luego, se establecieron AGREGACIONES para las proyecciones COUNT y COUNTIF. El análisis de los datos requirió un paso de operación COMPUTE, que proporcionó datos para los conteos normales y condicionales, y el resultado se escribió en la salida de orden aleatorio intermedio, que se etiquetó como __stage00_output en este plan.
Informe de errores
Es posible que los trabajos de consulta fallen a mitad de la ejecución. Debido a que la información del plan se actualiza de forma periódica, podrás observar dónde se produjo la falla en el grafo de ejecución. Dentro de Cloud Console, las etapas correctas o con fallas se etiquetan con una marca de verificación o un signo de exclamación junto al nombre de la etapa.
Para obtener más información sobre cómo interpretar y abordar errores, consulta la Guía de solución de problemas.
Representación de muestra de la API
La información del plan de consulta está incorporada en la información de la respuesta del trabajo y puedes recuperarla mediante una llamada a jobs.get. Por ejemplo, en el siguiente extracto de una respuesta JSON de un trabajo que muestra la consulta de Hamlet de muestra se señala el plan de consulta y la información del cronograma.
"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"
},
Usa información de ejecución
En los planes de consulta de BigQuery se proporciona información sobre cómo el servicio ejecuta consultas, pero la naturaleza administrada del servicio limita la practicidad directa de algunos detalles. Muchas optimizaciones se realizan de manera automática cuando usas el servicio, lo que puede diferir de otros entornos en los que el ajuste, el aprovisionamiento y la supervisión pueden requerir personal dedicado y especializado.
Para ver técnicas específicas que pueden mejorar la ejecución de consultas y el rendimiento, consulta la documentación de prácticas recomendadas. El plan de consulta y las estadísticas de cronograma te ayudan a comprender si algunas etapas dominan el uso de recursos. Por ejemplo, una etapa JOIN que genera muchas más filas de salida que filas de entrada indica una oportunidad para aplicar un filtro con anticipación en la consulta.
Además, la información de cronograma puede ayudar a identificar si una consulta determinada es lenta en sí o si lo es debido a los efectos de otras consultas que compiten por los mismos recursos. Si te das cuenta de que la cantidad de unidades activas es limitada durante toda la vida útil de la consulta, pero que la cantidad de unidades de trabajo en cola es alta, esto podría representar casos en los que reducir el número de consultas simultáneas puede mejorar de manera significativa el tiempo de ejecución general de determinadas consultas.