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. 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 usan recursos de ejecución, como las solicitudes de ejecución de prueba o los resultados 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 existan otras estadísticas.

Fondo

Cuando BigQuery ejecuta una consulta, convierte el SQL en un grafo de ejecución que consta de etapas. Las etapas se componen de pasos, las operaciones elementales que realizan la lógica de la consulta. BigQuery aprovecha una arquitectura en paralelo muy distribuida que ejecuta etapas en paralelo para reducir la latencia. Las etapas se comunican entre sí con Shuffle, una arquitectura de memoria distribuida rápida.

En el plan de consulta, se usan los términos unidades de trabajo y trabajadores para describir el paralelismo de las etapas. 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 ranuras ejecutan las unidades de trabajo individuales de una etapa en paralelo. Las estadísticas de trabajo de nivel superior proporcionan el costo de consulta individual con totalSlotMs según esta contabilización abstracta.

Otra propiedad importante de la ejecución de consultas es que BigQuery puede modificar el plan de consultas mientras se ejecuta una consulta. Por ejemplo, BigQuery introduce etapas de repartición para mejorar la distribución de datos entre los trabajadores de consultas, lo que mejora el paralelismo y reduce la latencia de las consultas.

Además del plan de consultas, los trabajos de consulta exponen un cronograma de ejecución que proporciona una contabilización de unidades de trabajo completadas, pendientes y activas. 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 el gráfico de ejecución con la consola de Google Cloud

En la consola deGoogle Cloud , puedes ver los detalles del plan de consultas para una consulta que se haya completado. Para ello, haz clic en el botón Detalles de la ejecución.

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 la consola de Google Cloud , pero todos pueden estar presentes en las respuestas de la API.

Comprende el grafo de ejecución

En la consola de Google Cloud , puedes ver los detalles del plan de consulta haciendo clic en la pestaña Gráfico de ejecución.

El panel Gráfico de ejecución se organiza de la siguiente manera:

• En el centro, se encuentra el gráfico de ejecución. Muestra las etapas como nodos y la memoria de shuffle intercambiada entre etapas como bordes.
• El panel izquierdo tiene el mapa de calor del texto de la consulta. Muestra el texto de la consulta principal que ejecutó la consulta junto con las vistas a las que se hace referencia.
• El panel derecho tiene los detalles de la consulta o la etapa.

Navega por el grafo de ejecución

El gráfico de ejecución aplica un esquema de colores a los nodos del gráfico según el tiempo de ranura, en el que los nodos con un rojo más oscuro tardan más tiempo de ranura en relación con el resto de las etapas del gráfico.

Para navegar por el grafo de ejecución, puedes hacer lo siguiente:

• Mantén presionado el fondo del gráfico para desplazarte a diferentes áreas.
• Usa la rueda del mouse para acercar y alejar el gráfico.
• Mantén presionado el minimapa en la parte superior derecha para desplazarte a diferentes áreas del gráfico.

Si haces clic en una etapa del gráfico, se mostrarán los detalles de la etapa seleccionada. Los detalles de la etapa tienen lo siguiente:

• Estadísticas. Consulta Descripción general de la etapa para obtener detalles sobre las estadísticas.
• Detalles del paso. Los pasos describen las operaciones individuales que ejecutan la lógica de la consulta.

Detalles del paso

Las etapas se componen de pasos, que son las operaciones individuales que ejecutan la lógica de la consulta. Los pasos tienen subpasos que describen lo que hizo el paso en pseudocódigo. Los pasos secundarios usan variables para describir las relaciones entre los pasos. Las variables comienzan con un signo de dólar seguido de un número único. Los números de variables no se comparten entre las etapas.

En la siguiente imagen, se muestran los pasos de una etapa:

A continuación, se muestra un ejemplo de los pasos de una etapa:

  READ
  $30:l_orderkey, $31:l_quantity
  FROM lineitem

  AGGREGATE
  GROUP BY $100 := $30
  $70 := SUM($31)

  WRITE
  $100, $70
  TO __stage00_output
  BY HASH($100)

En los pasos del ejemplo, se describe lo siguiente:

• La etapa leyó las columnas l_orderkey y l_quantity de la tabla lineitem y almacenó los valores en las variables $30 y $31, respectivamente.
• La etapa agregó las variables $30 y $31, y almacenó las agregaciones en las variables $100 y $70, respectivamente.
• La etapa escribió los resultados de las variables $100 y $70 para mezclarlos. La etapa ordenó los resultados en la memoria de Shuffle según $100.

Consulta Interpreta y optimiza los pasos para obtener todos los detalles sobre el tipo de pasos y cómo optimizarlos.

BigQuery puede truncar los pasos secundarios cuando el grafo de ejecución de la consulta es lo suficientemente complejo como para que proporcionar pasos secundarios completos cause problemas de tamaño de la carga útil cuando se recupera la información de la consulta.

Mapa de calor del texto de la consulta

BigQuery puede asignar algunos pasos de la etapa a partes del texto de la consulta. En el mapa de calor del texto de la consulta, se muestra todo el texto de la consulta correspondiente con los pasos de la etapa. Destaca el texto de la consulta según el tiempo de ranura total de las etapas cuyos pasos tienen texto de consulta asignado.

En la siguiente imagen, se muestra el texto de la consulta destacado:

Si mantienes el puntero sobre una parte asignada del texto de la consulta, se muestra una información sobre la herramienta que enumera todos los pasos de la etapa que se asignan al texto de la consulta junto con el tiempo de ranura de la etapa. Si haces clic en un texto de consulta asignado, se selecciona la etapa en el gráfico de ejecución y se abren los detalles de la etapa en el panel derecho.

Una sola parte del texto de la consulta se puede asignar a varias etapas. En la información sobre la herramienta, se enumeran cada etapa asignada y su tiempo de ranura. Si haces clic en el texto de la consulta, se destacan las etapas correspondientes y se atenúa el resto del gráfico. Luego, si haces clic en una etapa específica, se muestran sus detalles.

En la siguiente imagen, se muestra cómo se relaciona el texto de la consulta con los detalles del paso:

En la sección Detalles del paso de una etapa, si un paso se asigna al texto de la consulta, el paso tiene un ícono de código. Si haces clic en el ícono de código, se destacará la parte asignada del texto de la consulta a la izquierda.

Es importante tener en cuenta que el color del mapa de calor se basa en el tiempo de ranura de toda la etapa. Debido a que BigQuery no mide el tiempo de ranura de los pasos, el mapa de calor no representa el tiempo de ranura real para esa parte específica del texto de la consulta asignada. En la mayoría de los casos, una etapa realiza solo un paso complejo, como una unión o una agregación. Por lo tanto, el color del mapa de calor es adecuado. Sin embargo, cuando una etapa se compone de pasos que realizan varias operaciones complejas, el color del mapa de calor puede sobrerrepresentar el tiempo de ranura real en el mapa de calor. En esos casos, es importante comprender los otros pasos que componen la etapa para obtener una comprensión más completa del rendimiento de la consulta.

Si una consulta usa vistas y los pasos de la etapa tienen asignaciones al texto de la consulta de una vista, el mapa de calor del texto de la consulta muestra el nombre de la vista y el texto de la consulta de la vista con sus asignaciones. Sin embargo, si se borra la vista o si pierdes el permiso de IAM bigquery.tables.get en la vista, el mapa de calor del texto de la consulta no mostrará las asignaciones de los pasos de la etapa para la vista.

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 determinístico para ninguna consulta determinada.

Clasificación de tiempo por etapa

Las etapas de consulta 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.

En la consola de Google Cloud , se presenta el tiempo por etapas con 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.

Descripción general del paso

Los pasos contienen las operaciones que ejecuta cada trabajador dentro de una etapa, presentadas como una lista ordenada de operaciones. Cada operación de paso tiene una categoría, y algunas operaciones proporcionan información más detallada. Las categorías de operación que se encuentran en el plan de consulta incluyen lo siguiente:

Categoría de paso	Descripción
READ	Lectura de una o más columnas desde una tabla de entrada o de orden aleatorio intermedio. Solo se muestran las primeras dieciséis columnas que se leen en los detalles del paso.
WRITE	Escritura de una o más columnas en una tabla de salida o en Shuffle intermedio. Para las salidas con particiones HASH de una etapa, esto también incluye las columnas que se usan como clave de partición.
COMPUTE	Evaluación de expresiones y funciones de SQL.
FILTER	Se usa en las cláusulas WHERE, OMIT IF y HAVING.
SORT	Operación ORDER BY que incluye las claves de columna y el orden de clasificación.
AGGREGATE	Implementa agregaciones para cláusulas como GROUP BY o COUNT, entre otras.
LIMIT	Implementa la cláusula LIMIT.
JOIN	Implementa uniones para cláusulas como JOIN, entre otras; incluye el tipo de unión y, posiblemente, las condiciones de unión.
ANALYTIC_FUNCTION	Invocación de una función analítica.
USER_DEFINED_FUNCTION	Invocación a una función definida por el usuario.
UPDATE	Modifica las filas existentes en una tabla de destino para una sentencia UPDATE; incluye las columnas modificadas y la tabla de destino.
DELETE	Quita filas de una tabla de destino para una sentencia DELETE; incluye las columnas a las que se hace referencia y la tabla de destino.
MERGE	Modifica las filas de una tabla de destino para una sentencia MERGE; incluye las columnas modificadas y la tabla de destino.
EXPORT	Escribe columnas de salida en una tabla de destino para sentencias de lenguaje de manipulación de datos (DML) o exportaciones de resultados de consultas.

Pasos para interpretar y optimizar

En las siguientes secciones, se explica cómo interpretar los pasos de un plan de consulta y se proporcionan formas de optimizar tus consultas.

Paso READ

El paso READ significa que una etapa accede a los datos para su procesamiento. Los datos se pueden leer directamente desde las tablas a las que se hace referencia en una consulta o desde la memoria de redistribución. Cuando se leen datos de una etapa anterior, BigQuery lee datos de la memoria de Shuffle. La cantidad de datos analizados afecta el costo cuando se usan ranuras on demand y el rendimiento cuando se usan reservas.

Posibles problemas de rendimiento

• Análisis grande de una tabla sin particiones: Si la consulta solo necesita una pequeña parte de los datos, esto podría indicar que un análisis de tabla es ineficiente. La partición podría ser una buena estrategia de optimización.
• Análisis de una tabla grande con una proporción de filtro pequeña: Esto sugiere que el filtro no reduce de manera eficaz los datos analizados. Considera revisar las condiciones del filtro.
• Bytes de Shuffle volcados al disco: Esto sugiere que los datos no se almacenan de manera eficaz con técnicas de optimización, como el agrupamiento en clústeres, que podrían mantener datos similares en clústeres.

Optimizar

• Filtrado segmentado: Usa cláusulas WHERE de forma estratégica para filtrar los datos irrelevantes lo antes posible en la consulta. Esto reduce la cantidad de datos que debe procesar la consulta.
• Partición y agrupamiento en clústeres: BigQuery usa la partición y el agrupamiento en clústeres de tablas para ubicar de manera eficiente segmentos de datos específicos. Asegúrate de que tus tablas estén particionadas y agrupadas en clústeres según tus patrones de consulta habituales para minimizar los datos analizados durante los pasos de READ.
• Selecciona las columnas pertinentes: Evita usar declaraciones SELECT *. En su lugar, selecciona columnas específicas o usa SELECT * EXCEPT para evitar leer datos innecesarios.
• Vistas materializadas: Las vistas materializadas pueden calcular previamente y almacenar las agregaciones que se usan con frecuencia, lo que podría reducir la necesidad de leer las tablas base durante los pasos de READ para las consultas que usan esas vistas.

Paso COMPUTE

En el paso COMPUTE, BigQuery realiza las siguientes acciones en tus datos:

• Evalúa expresiones en las cláusulas SELECT, WHERE, HAVING y otras de la consulta, incluidos los cálculos, las comparaciones y las operaciones lógicas.
• Ejecuta funciones de SQL integradas y funciones definidas por el usuario.
• Filtra filas de datos según las condiciones de la consulta.

Optimizar

El plan de consulta puede revelar cuellos de botella en el paso COMPUTE. Busca etapas con cálculos extensos o una gran cantidad de filas procesadas.

• Correlaciona el paso COMPUTE con el volumen de datos: Si una etapa muestra un procesamiento significativo y procesa un gran volumen de datos, podría ser una buena candidata para la optimización.
• Datos sesgados: En las etapas en las que el máximo de procesamiento es significativamente mayor que el promedio de procesamiento, esto indica que la etapa dedicó una cantidad de tiempo desproporcionada a procesar algunas porciones de datos. Considera analizar la distribución de los datos para ver si hay sesgo de datos.
• Considera los tipos de datos: Usa tipos de datos adecuados para tus columnas. Por ejemplo, usar números enteros, fechas y horas, y marcas de tiempo en lugar de cadenas puede mejorar el rendimiento.

Paso WRITE

Los pasos de WRITE se realizan para los datos intermedios y el resultado final.

• Escribir en la memoria de redistribución: En una consulta de varias etapas, el paso WRITE suele implicar el envío de los datos procesados a otra etapa para su procesamiento posterior. Esto es típico de la memoria de shuffle, que combina o agrega datos de varias fuentes. Los datos escritos durante esta etapa suelen ser un resultado intermedio, no el resultado final.
• Resultado final: El resultado de la consulta se escribe en la tabla de destino o en una tabla temporal.

Partición de hash

Cuando una etapa del plan de consulta escribe datos en un resultado particionado por hash, BigQuery escribe las columnas incluidas en el resultado y la columna elegida como clave de partición.

Optimizar

Si bien es posible que el paso WRITE no se optimice directamente, comprender su función puede ayudarte a identificar posibles cuellos de botella en etapas anteriores:

• Minimiza los datos escritos: Enfócate en optimizar las etapas anteriores con filtrado y agregación para reducir la cantidad de datos escritos durante este paso.

• Partición: La escritura se beneficia en gran medida de la partición de tablas. Si los datos que escribes se limitan a particiones específicas, BigQuery puede realizar escrituras más rápidas.

  Si la declaración DML tiene una cláusula WHERE con una condición estática en una columna de partición de tabla, BigQuery solo modifica las particiones de tabla relevantes.

• Compensaciones de la desnormalización: En ocasiones, la desnormalización puede generar conjuntos de resultados más pequeños en el paso WRITE intermedio. Sin embargo, existen desventajas, como un mayor uso del almacenamiento y desafíos de coherencia de los datos.

Paso JOIN

En el paso JOIN, BigQuery combina datos de dos fuentes de datos. Las uniones pueden incluir condiciones de unión. Las uniones consumen muchos recursos. Cuando se unen datos grandes en BigQuery, las claves de unión se redistribuyen de forma independiente para alinearse en la misma ranura, de modo que la unión se realice de forma local en cada ranura.

El plan de consulta para el paso JOIN suele revelar los siguientes detalles:

• Patrón de unión: Indica el tipo de unión que se usó. Cada tipo define cuántas filas de las tablas unidas se incluyen en el conjunto de resultados.
• Columnas de unión: Son las columnas que se usan para hacer coincidir las filas entre las fuentes de datos. La elección de las columnas es fundamental para el rendimiento de la unión.

Patrones de unión

• Unión de transmisión: Cuando una tabla, por lo general, la más pequeña, puede caber en la memoria de un solo nodo trabajador o ranura, BigQuery puede transmitirla a todos los demás nodos para realizar la unión de manera eficiente. Busca JOIN EACH WITH ALL en los detalles del paso.
• Unión hash: Cuando las tablas son grandes o no es adecuada una unión de transmisión, se puede usar una unión hash. BigQuery usa operaciones de hash y shuffle para mezclar las tablas izquierda y derecha, de modo que las claves coincidentes terminen en la misma ranura para realizar una unión local. Las uniones de hash son una operación costosa, ya que los datos deben moverse, pero permiten una coincidencia eficiente de las filas en los hashes. Busca JOIN EACH WITH EACH en los detalles del paso.
• Unión de tabla con sí misma: Es un antipatrón de SQL en el que una tabla se une a sí misma.
• Unión cruzada: Es un antipatrón de SQL que puede causar problemas de rendimiento significativos, ya que genera datos de salida más grandes que las entradas.
• Unión sesgada: La distribución de datos en la clave de unión de una tabla está muy sesgada y puede generar problemas de rendimiento. Busca casos en los que el tiempo máximo de procesamiento sea mucho mayor que el tiempo de procesamiento promedio en el plan de consulta. Para obtener más información, consulta Unión de cardinalidad alta y Sesgo de partición.

Depuración

• Gran volumen de datos: Si el plan de consulta muestra una cantidad significativa de datos procesados durante el paso JOIN, investiga la condición de unión y las claves de unión. Considera filtrar o usar claves de unión más selectivas.
• Distribución de datos sesgada: Analiza la distribución de datos de las claves de unión. Si una tabla está muy sesgada, explora estrategias como dividir la consulta o realizar un filtrado previo.
• Uniones de alta cardinalidad: Las uniones que producen muchas más filas que la cantidad de filas de entrada izquierda y derecha pueden reducir drásticamente el rendimiento de las consultas. Evita las uniones que producen una gran cantidad de filas.
• Orden incorrecto de la tabla: Asegúrate de haber elegido el tipo de unión adecuado, como INNER o LEFT, y de haber ordenado las tablas de mayor a menor según los requisitos de tu consulta.

Optimizar

• Claves de unión selectivas: Para las claves de unión, usa INT64 en lugar de STRING cuando sea posible. Las comparaciones STRING son más lentas que las comparaciones INT64 porque comparan cada carácter de una cadena. Los números enteros solo requieren una comparación.
• Filtra antes de unir: Aplica filtros de cláusula WHERE en tablas individuales antes de la unión. Esto reduce la cantidad de datos involucrados en la operación de unión.
• Evita las funciones en las columnas de unión: Evita llamar a funciones en las columnas de unión. En su lugar, estandariza los datos de la tabla durante el proceso de transferencia o posterior a la transferencia con canalizaciones de SQL de ELT. Este enfoque elimina la necesidad de modificar las columnas de unión de forma dinámica, lo que permite uniones más eficientes sin comprometer la integridad de los datos.
• Evita las uniones de tabla con sí misma: Las uniones de tabla con sí misma se usan de uso frecuente para calcular relaciones que dependen de las filas. Sin embargo, las uniones de tabla con sí misma pueden cuadruplicar la cantidad de filas de salida, lo que genera problemas de rendimiento. En lugar de depender de uniones de tabla con sí misma, considera usar funciones analíticas.
• Tablas grandes primero: Aunque el optimizador de consulta en SQL puede determinar qué tabla debe estar en qué lado de la unión, ordena las tablas unidas de forma adecuada. La práctica recomendada es colocar primero la tabla más grande, seguida de la más pequeña y, luego, por tamaño decreciente.
• Desnormalización: En algunos casos, desnormalizar tablas de forma estratégica (agregar datos redundantes) puede eliminar las uniones por completo. Sin embargo, este enfoque tiene desventajas en cuanto al almacenamiento y la coherencia de los datos.
• Partición y agrupamiento en clústeres: Particionar tablas según las claves de unión y agrupar en clústeres los datos coubicados puede acelerar de forma significativa las uniones, ya que permite que BigQuery se oriente a las particiones de datos pertinentes.
• Optimización de uniones sesgadas: Para evitar problemas de rendimiento asociados con las uniones sesgadas, prefiltra los datos de la tabla lo antes posible o divide la consulta en dos o más consultas.

Paso AGGREGATE

En el paso AGGREGATE, BigQuery agrega y agrupa los datos.

Depuración

• Detalles de la etapa: Verifica la cantidad de filas de entrada y de salida de la agregación, y el tamaño de la redistribución para determinar cuánta reducción de datos logró el paso de agregación y si se involucró la redistribución de datos.
• Tamaño de la redistribución: Un tamaño de redistribución grande puede indicar que se movió una cantidad significativa de datos entre los nodos trabajadores durante la agregación.
• Verifica la distribución de los datos: Asegúrate de que los datos estén distribuidos de manera uniforme entre las particiones. La distribución de datos sesgada puede generar cargas de trabajo desequilibradas en el paso de agregación.
• Revisa las agregaciones: Analiza las cláusulas de agregación para confirmar que sean necesarias y eficientes.

Optimizar

• Agrupamiento en clústeres: Agrupa tus tablas en clústeres en columnas que se usen con frecuencia en GROUP BY, COUNT o en otras cláusulas de agregación.
• Partición: Elige una estrategia de partición que se alinee con tus patrones de consulta. Considera usar tablas particionadas por tiempo de transferencia para reducir la cantidad de datos analizados durante la agregación.
• Agrega antes: Si es posible, realiza agregaciones antes en la canalización de consultas. Esto puede reducir la cantidad de datos que se deben procesar durante la agregación.
• Optimización de la redistribución: Si la redistribución es un cuello de botella, explora formas de minimizarla. Por ejemplo, desnormaliza las tablas o usa el agrupamiento en clústeres para colocar los datos relevantes.

Casos extremos

• Agregaciones DISTINCT: Las consultas con agregaciones DISTINCT pueden ser costosas desde el punto de vista computacional, en especial en conjuntos de datos grandes. Considera alternativas como APPROX_COUNT_DISTINCT para obtener resultados aproximados.
• Gran cantidad de grupos: Si la consulta produce una gran cantidad de grupos, puede consumir una cantidad considerable de memoria. En esos casos, considera limitar la cantidad de grupos o usar una estrategia de agregación diferente.

Paso REPARTITION

Tanto REPARTITION como COALESCE son técnicas de optimización que BigQuery aplica directamente a los datos reorganizados en la consulta.

• REPARTITION: El objetivo de esta operación es reequilibrar la distribución de datos entre los nodos trabajadores. Supongamos que, después de la redistribución, un nodo trabajador termina con una cantidad de datos desproporcionadamente grande. El paso REPARTITION redistribuye los datos de manera más uniforme, lo que evita que un solo trabajador se convierta en un cuello de botella. Esto es muy importante para las operaciones de uso intensivo de procesamiento, como las uniones.
• COALESCE: Este paso se produce cuando tienes muchos buckets de datos pequeños después de la redistribución. El paso COALESCE combina estos buckets en otros más grandes, lo que reduce la sobrecarga asociada con la administración de numerosos fragmentos de datos pequeños. Esto puede ser especialmente beneficioso cuando se trabaja con conjuntos de resultados intermedios muy pequeños.

Si ves pasos de REPARTITION o COALESCE en tu plan de consulta, no significa necesariamente que haya un problema con tu consulta. Suele ser un indicio de que BigQuery está optimizando de forma proactiva la distribución de datos para mejorar el rendimiento. Sin embargo, si ves estas operaciones de forma repetida, puede indicar que tus datos están sesgados de forma inherente o que tu consulta está causando una reorganización excesiva de los datos.

Optimizar

Para reducir la cantidad de pasos de REPARTITION, intenta lo siguiente:

• Distribución de datos: Asegúrate de que tus tablas estén particionadas y agrupadas en clústeres de manera eficaz. Los datos bien distribuidos reducen la probabilidad de que se produzcan desequilibrios significativos después de la mezcla.
• Estructura de la consulta: Analiza la consulta para detectar posibles fuentes de sesgo de datos. Por ejemplo, ¿hay filtros o uniones muy selectivos que generen un subconjunto pequeño de datos que se procesan en un solo trabajador?
• Estrategias de unión: Experimenta con diferentes estrategias de unión para ver si generan una distribución de datos más equilibrada.

Para reducir la cantidad de pasos de COALESCE, intenta lo siguiente:

• Estrategias de agregación: Considera realizar agregaciones antes en la canalización de consultas. Esto puede ayudar a reducir la cantidad de conjuntos de resultados intermedios pequeños que podrían causar pasos de COALESCE.
• Volumen de datos: Si trabajas con conjuntos de datos muy pequeños, es posible que COALESCE no sea una preocupación significativa.

No optimices en exceso. La optimización prematura puede hacer que tus consultas sean más complejas sin generar beneficios significativos.

UPDATE, DELETE y MERGE pasos

Los pasos UPDATE, DELETE y MERGE aparecen en las etapas que ejecutan sentencias de lenguaje de manipulación de datos (DML) en una tabla de destino.

Los detalles del paso suelen incluir los siguientes pasos secundarios:

• Columnas: Son las columnas que se leen o escriben en la tabla de destino.
• Tabla de destino (FROM o INTO): Es la tabla de destino que modifica la declaración, con FROM para los pasos UPDATE y DELETE, y INTO para los pasos MERGE.

Paso EXPORT

El paso EXPORT escribe los datos de salida en una tabla de destino. Este paso suele aparecer en las etapas finales de las sentencias DML, como las sentencias INSERT, UPDATE, DELETE y MERGE, y en las consultas que materializan los resultados en una tabla de destino.

Los detalles del paso suelen incluir los siguientes pasos secundarios:

• Columnas de salida: Es la lista de variables escritas en la tabla de destino.
• Tabla de destino (TO): Es la tabla de destino que recibe las filas exportadas.

Explicación de las consultas federadas

Las consultas federadas te permiten enviar una declaración de consulta a una fuente de datos externa con la función EXTERNAL_QUERY. Las consultas federadas están sujetas a la técnica de optimización conocida como envíos de SQL y el plan de consultas muestra las operaciones enviadas a la fuente de datos externa, si la hubiera. Por ejemplo, ejecuta la siguiente consulta:

SELECT id, name
FROM EXTERNAL_QUERY("<connection>", "SELECT * FROM company")
WHERE country_code IN ('ee', 'hu') AND name like '%TV%'

El plan de consulta mostrará los siguientes pasos de etapa:

$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

En este plan, table_for_external_query_$_0(...) representa la función EXTERNAL_QUERY. Entre paréntesis puedes ver la consulta que ejecuta la fuente de datos externa. En función de eso, puedes notar lo siguiente:

• Una fuente de datos externa muestra solo 3 columnas seleccionadas.
• Una fuente de datos externa solo muestra filas en las que country_code es 'ee' o 'hu'.
• El operador LIKE no se envía hacia abajo y BigQuery lo evalúa.

A modo de comparación, si no hay pushdown, el plan de consulta mostrará los siguientes pasos de etapa:

$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

Esta vez, una fuente de datos externa muestra todas las columnas y todas las filas de la tabla company, y BigQuery realiza el filtrado.

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.
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”:

SELECT
  COUNT(1) as rowcount,
  COUNTIF(corpus = 'hamlet') as rowcount_hamlet
FROM `publicdata.samples.shakespeare`

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.

Para obtener más información sobre los pasos de las etapas de ejecución, haz clic en 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 empezar hasta que la primera etapa escribió su salida en un orden aleatorio intermedio.

Error Reporting

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 la consola de Google Cloud , 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 con 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 ejemplo, 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.

Nota: Algunos procesamientos de consultas se realizan fuera del contexto de cualquier etapa. En algunos casos, se puede acumular una latencia significativa o un uso de ranuras antes de que se envíe la primera etapa o después de que se complete la última etapa. En los ejemplos, se incluyen algunas formas de reducción de particiones y varias operaciones de metadatos.