Plan de consulta y cronograma

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. Se puede recuperar esta información desde 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 independientemente de la velocidad a la que se encueste el estado del trabajo, pero normalmente 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 resultados 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.

Contexto

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, y las etapas realizan modelos de las unidades de trabajo que varios trabajadores potenciales pueden ejecutar en paralelo. Las etapas se comunican entre sí a través de una arquitectura aleatoria de distribución rápida, que se analizó con más detalle en otro lugar.

Dentro del plan de consulta, se usan los términos de las unidades de trabajo y de trabajadores, ya que el plan transmite información sobre el paralelismo en específico. En otros lugares dentro de BigQuery podrás encontrar el término "ranura", que es una representación abstracta de varias facetas de la ejecución de consultas, incluidos los recursos de procesamiento, memoria y E/S. Las estadísticas de trabajo principales proporcionan la estimación del costo de consulta individual con la estimación totalSlotMs de la consulta que usa esta contabilidad abstracta.

Otra propiedad importante de la arquitectura de ejecución de consultas es su dinamismo, lo que significa que el plan de consulta puede modificarse mientras una consulta está en tránsito. Las etapas que se ingresan mientras se ejecuta una consulta suelen usarse para mejorar la distribución de datos en los trabajadores de consultas. En los planes de consulta en los que esto ocurre, estas normalmente se etiquetan como etapas de distribució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 manera simultánea, por lo que el cronograma está previsto para mostrar el progreso general de la consulta.

Cómo ver información con la IU web clásica de BigQuery

Si usas la IU web clásica de BigQuery, puedes ver los detalles del plan de consulta de una consulta completada si haces clic en el botón Detalles (Details) (a la derecha del botón Resultados [Results]).

Para las consultas de larga duración, puedes ver el plan de consulta a medida que avanza si haces clic en el vínculo dentro de la línea de estado de la consulta, debajo del panel del compositor de consultas.

Información del plan de consulta

Dentro de la respuesta de la API, los planes de consulta se representan como una lista de etapas de consulta, en las que se exponen estadísticas de descripción general por etapa, información detallada de pasos y clasificaciones de tiempo de etapa. No todos los detalles se procesan dentro de la IU web, pero pueden estar presentes en las respuestas de la API.

Descripción general de la etapa

Los campos de vista 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 para la etapa. Los steps en 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 el número de segmentos de columnas dentro de una tabla o el número de particiones dentro 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.

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.
ORDEN	Operación Ordenar o también Ordenar por, que incluye las claves y la dirección de la columna.
AGREGACIÓN	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. Ya que cada etapa de ejecución representa el trabajo que realiza uno o más trabajadores independientes, la información se proporciona en los tiempos promedio y en el peor de los casos, lo que representa el rendimiento promedio de todos los trabajadores en una etapa, así como el rendimiento más lento de los trabajadores de una clasificación dada. 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 invierte en cualquier segmento.

La IU web clásica de BigQuery presenta el tiempo por etapas mediante las representaciones de tiempo relativas.

La información del tiempo por etapas se transmite de la siguiente manera:

Tiempo relativo	Tiempo absoluto	IU web clásica de BigQuery*	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ó ligado a la CPU.
computeRatioMax	computeMsMax		Tiempo que el trabajador más lento pasó ligado 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.

* Las etiquetas "AVG" y "MAX" son para fines de ilustración solamente y no aparecen en la IU web clásica de BigQuery.

Metadatos de cronograma

El cronograma de consultas 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, que 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.

Una consulta de ejemplo

Observa lo siguiente si ejecutas una consulta sencilla que cuente el número de filas en el conjunto de datos públicos de Shakespeare y un otro conteo condicional que restrinja 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`

Puedes hacer clic en Detalles para ver la siguiente información sobre el plan de consulta. Primero, examinemos la primera sección, que contiene el cronograma de la consulta:

En este ejemplo, tratamos con una tabla de muestra muy pequeña y una consulta sencilla, por lo que solo hay dos unidades de trabajo en total. Con este ejemplo, todo el trabajo se completa casi de inmediato.

Entonces, analicemos más abajo para ver el plan de consulta:

En este ejemplo, los indicadores de color muestran los tiempos relativos de todas las etapas. A partir de la información de entrada en paralelo, vemos que cada etapa solo requería un trabajador, por lo que no hay variación entre el tiempo promedio y el más lento.

También podemos ver que, para esta consulta trivial, el tiempo más prolongado en cualquiera de los segmentos fue el tiempo que un trabajador 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.

Ahora, examinemos los pasos de nuestras etapas de ejecución con más detalle. A la izquierda de la etiqueta de la etapa, haz clic en el triángulo para expandir los detalles de la etapa:

En este caso, podemos ver el plan de ejecución del único trabajador que completó el trabajo de la Etapa 00. Primero, se LEYERON los datos de la columna "corpus" de la tabla de shakespeare a la que se hace referencia. Luego, se establecieron AGREGACIONES para las proyecciones COUNT y COUNTIF. El análisis de los datos requirió un paso de PROCESAMIENTO, 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.

Informes 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 dentro del grafo de ejecución. Dentro de la IU, las etapas correctas y con fallos se etiquetan mediante una marca de verificación y un signo de exclamación junto al nombre de la etapa.

Para obtener más información sobre cómo interpretar y direccionar errores, consulta la guía de solución de problemas.

Representación de muestra de la API

La información del plan de consulta se integra automáticamente en la información de respuesta del trabajo sin la necesidad de llamar a métodos adicionales y se puede recuperar con una llamada a jobs.get para recuperar los detalles del trabajo. Por ejemplo, el siguiente es un extracto de una respuesta JSON para un trabajo que muestra la consulta hamlet de ejemplo en el que se muestran el plan de consulta y la información de cronograma.

"statistics": {
  "query": {
    "cacheHit": false,
    "queryPlan": [
      {
        "completedParallelInputs": "1",
        "computeMsAvg": "25",
        "computeMsMax": "25",
        "computeRatioAvg": 0.17857142857142858,
        "computeRatioMax": 0.17857142857142858,
        "endMs": "1522787349945",
        "id": "0",
        "name": "S00: Input",
        "parallelInputs": "1",
        "readMsAvg": "28",
        "readMsMax": "28",
        "readRatioAvg": 0.2,
        "readRatioMax": 0.2,
        "recordsRead": "164656",
        "recordsWritten": "1",
        "shuffleOutputBytes": "18",
        "shuffleOutputBytesSpilled": "0",
        "startMs": "1522787349898",
        "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"
            ]
          }
        ],
        "waitMsAvg": "0",
        "waitMsMax": "0",
        "waitRatioAvg": 0.0,
        "waitRatioMax": 0.0,
        "writeMsAvg": "5",
        "writeMsMax": "5",
        "writeRatioAvg": 0.03571428571428571,
        "writeRatioMax": 0.03571428571428571
      },
      {
        "completedParallelInputs": "1",
        "computeMsAvg": "14",
        "computeMsMax": "14",
        "computeRatioAvg": 0.1,
        "computeRatioMax": 0.1,
        "endMs": "1522787350180",
        "id": "1",
        "inputStages": [
          "0"
        ],
        "name": "S01: Output",
        "parallelInputs": "1",
        "readMsAvg": "0",
        "readMsMax": "0",
        "readRatioAvg": 0.0,
        "readRatioMax": 0.0,
        "recordsRead": "1",
        "recordsWritten": "1",
        "shuffleOutputBytes": "16",
        "shuffleOutputBytesSpilled": "0",
        "startMs": "1522787350038",
        "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"
            ]
          }
        ],
        "waitMsAvg": "140",
        "waitMsMax": "140",
        "waitRatioAvg": 1.0,
        "waitRatioMax": 1.0,
        "writeMsAvg": "129",
        "writeMsMax": "129",
        "writeRatioAvg": 0.9214285714285714,
        "writeRatioMax": 0.9214285714285714
      }
    ],
    "referencedTables": [
      {
        "datasetId": "samples",
        "projectId": "publicdata",
        "tableId": "shakespeare"
      }
    ],
    "statementType": "SELECT",
    "timeline": [
      {
        "activeUnits": "0",
        "completedUnits": "2",
        "elapsedMs": "999",
        "pendingUnits": "0",
        "totalSlotMs": "185"
      },
      {
        "activeUnits": "0",
        "completedUnits": "2",
        "elapsedMs": "1197",
        "pendingUnits": "0",
        "totalSlotMs": "185"
      }
    ],
    "totalBytesBilled": "10485760",
    "totalBytesProcessed": "2464625",
    "totalPartitionsProcessed": "0",
    "totalSlotMs": "127"
  },
  "totalBytesProcessed": "2464625"
},

Usa información de ejecución

Los planes de consulta de BigQuery proporcionan información sobre la manera en la que el servicio ejecuta las consultas, pero la naturaleza administrada del servicio limita la practicidad directa de algunos detalles. Varias optimizaciones se realizan automáticamente si usas el servicio, que puede diferir de otros entornos en los que el ajuste, el aprovisionamiento y la supervisión pueden requerir personal especializado y dedicado.

Para ver técnicas específicas que pueden mejorar la ejecución de consultas y el rendimiento, consulta la documentación de recomendaciones. El plan de consulta y las estadísticas de cronograma te ayudan a comprender si algunas etapas dominan el uso de recursos. Por ejemplo, es posible que una etapa JOIN que genera muchas más filas de salida que filas de entrada indique una oportunidad para filtrar con anticipación en la consulta.

Además, la información de cronograma puede ayudar a identificar si una consulta dada es lenta en aislamiento o si lo es debido a los efectos de otras consultas que compiten por los mismos recursos. Si observas que el número de unidades activas permanece limitado durante el ciclo de vida de la consulta, pero la cantidad de unidades de trabajo en cola permanece alta, es posible que esto represente casos en los que reducir el número de consultas simultáneas mejorará mucho el tiempo de ejecución general de algunas consultas.