Soluciona problemas de administración de cargas de trabajo de BigQuery

En este documento, se muestra cómo solucionar problemas habituales con la administración de cargas de trabajo de BigQuery, incluidas la asignación y las asignaciones de reservas, los errores de configuración de reservas, los compromisos de capacidad, la contención de ranuras, la supervisión de reservas y el registro de conversaciones de estadísticas de conversaciones.

Para ver y administrar reservas, compromisos y gráficos de recursos administrativos, asegúrate de tener los roles de Identity and Access Management (IAM) necesarios, como el rol de visualizador de recursos de BigQuery (roles/bigquery.resourceViewer) o el de administrador de recursos de BigQuery (roles/bigquery.resourceAdmin) en el proyecto de administración. Para obtener más información, consulta Control de acceso con IAM.

Soluciona problemas con las reservas

Usa la siguiente información para solucionar problemas habituales con las reservas, como errores cuando se agregan ranuras, por qué no se usa una reserva para un trabajo de BigQuery o reservas no reconocidas.

No se pueden agregar más ranuras al tamaño de la reserva

Si encuentras errores como Failed to allocate slots for reservation in the current system state o Failed to update reservation: Failed to allocate slots for reservation cuando intentas agregar más ranuras a tu reserva, por lo general, se trata de un problema transitorio. Para mitigar el problema, haz lo siguiente:

  • Vuelve a intentarlo con una cantidad menor de ranuras.
  • Si el intento con una cantidad menor de ranuras falla, espera 15 minutos y vuelve a intentar la operación.

Si después de volver a intentarlo varias veces y esperar 30 minutos, sigues recibiendo el mismo error, comunícate con Atención al cliente de Cloud.

No hay suficiente cuota para completar esta solicitud

Si el mensaje de error indica There is insufficient quota to complete this request, la solicitud supera el límite de cuota establecido para el proyecto.

Para resolver este error, haz lo siguiente:

  • Agrega una cantidad menor de ranuras a la reserva para que la solicitud no supere el límite de cuota.
  • Solicita un aumento de cuota en la región correspondiente. Para obtener más información, consulta Solicita un aumento de la cuota.

BigQuery no usa la reserva para ejecutar un trabajo

Existen varias situaciones en las que un trabajo puede ejecutarse con los precios a pedido o un grupo de ranuras compartido gratuito en lugar de usar la reserva que creaste.

La consulta y la reserva se encuentran en regiones diferentes

Las reservas son recursos regionales. Una consulta se ejecuta en la misma ubicación que cualquier tabla a la que se haga referencia en la consulta.

Si la ubicación de una tabla no coincide con la ubicación de la reserva, la consulta no usa la reserva y, en su lugar, se ejecuta con precios según demanda (o el grupo de ranuras compartido gratuito para los trabajos de carga y exportación por lotes aptos).

Consulta tablas de BigQuery Omni

Cuando consultes una tabla de BigQuery Omni, asegúrate de crear la reserva en la misma región que la tabla, no en una región de ubicación conjunta. Si creas la reserva en la región de BigQuery ubicada en el mismo lugar, la consulta se ejecuta con los precios a pedido.

Se creó la reserva, pero no se le asignó el proyecto

Para usar las ranuras de una reserva, debes crear una asignación que asigne el proyecto, la carpeta o la organización a la reserva específica. Asegúrate de que el proyecto tenga una asignación para la reserva correspondiente.

No coincide el tipo de trabajo

Asegúrate de seleccionar el tipo de trabajo correcto cuando crees una asignación; de lo contrario, los trabajos no usarán la reserva.

Por ejemplo, si seleccionas PIPELINE como el tipo de trabajo, todos los trabajos de consulta se ejecutan con precios a pedido. Cambia el tipo de asignación a QUERY para que los trabajos de consulta se ejecuten con la reserva.

Consultas de varias declaraciones

Si ejecutas consultas de varias instrucciones, el objeto de trabajo superior no tiene una reserva asociada, incluso si los trabajos secundarios se ejecutan con una reserva.

Para confirmar si el trabajo realmente usó una reserva, verifica los metadatos del trabajo secundario.

Recupera resultados almacenados en caché

Cuando un trabajo de consulta recupera resultados almacenados en caché, el campo de reserva está vacío, ya que BigQuery no realiza ningún cálculo y recupera los resultados directamente de la tabla temporal.

Operaciones de modificación de filas de captura de datos modificados

Si tienes tablas de captura de datos modificados (CDC), BigQuery aplica las modificaciones de filas pendientes dentro del intervalo max_staleness como trabajos en segundo plano que usan el tipo de asignación BACKGROUND. Si no hay asignaciones de BACKGROUND, estos trabajos usan precios on-demand. Considera crear una asignación de BACKGROUND para el proyecto para evitar costos inesperados a pedido. Puedes identificar estos trabajos por la subcadena queueworker_cdc_background_merge_coalesce en el identificador del trabajo.

Tipos de modelos de BigQuery ML que usan servicios externos

Si no se encuentra ninguna asignación de reserva con un tipo de trabajo ML_EXTERNAL en el proyecto, los trabajos de creación de modelos externos se ejecutan con precios a pedido. La asignación del tipo de trabajo QUERY se aplica a los modelos estándar de BigQuery ML y a los modelos de factorización de matrices (que requieren una reserva de edición Enterprise o Enterprise Plus), mientras que los modelos externos requieren una asignación ML_EXTERNAL. Para obtener más información, consulta Asigna ranuras a las cargas de trabajo de BigQuery.

Se identificaron reservas no reconocidas en el proyecto

BigQuery posee reservas que representan un grupo de ranuras compartidas gratuitas para ciertas operaciones en BigQuery.

default-pipeline

De forma predeterminada, la carga o exportación por lotes de datos en BigQuery usa un grupo de ranuras compartido gratuito. Cuando inspeccionas estos trabajos de carga o extracción, el campo de reserva muestra default-pipeline.

No se aplican cargos por usar el grupo de ranuras compartidas. Si deseas un rendimiento coherente y predecible, considera comprar una reserva de PIPELINE.

Soluciona problemas de tareas de administración de reservas

Es posible que se produzcan los siguientes errores cuando crees o actualices una reserva.

El tamaño de la reserva o las ranuras del modelo de referencia deben ser un múltiplo de 50

Mensaje de error

  • Max reservation size can only be configured in multiples of 50, except when covered by excess commitments.
  • Baseline slots can only be configured in multiples of 50, except when covered by excess commitments.

Causa

Las ranuras siempre se ajustan automáticamente a un múltiplo de 50. BigQuery escala verticalmente las ranuras según el uso real y redondea al incremento de 50 ranuras más cercano. Cuando no hay un compromiso o si el compromiso no puede cubrir los aumentos, solo puedes aumentar las ranuras de ajuste de escala automático y del modelo de referencia en múltiplos de 50.

Si baseline slots o max reservation size - baseline slots no es un múltiplo de 50 (y no está cubierto por compromisos de capacidad excedente), la reserva no puede escalar hasta el tamaño máximo de reserva, lo que genera este error.

Solución

Realiza una de las siguientes acciones:

  • Compra más compromisos de capacidad para cubrir los aumentos de ranuras.
  • Elige ranuras de referencia y máximas que sean incrementos de 50.

No se puede usar la cantidad máxima de ranuras sin habilitar la equidad basada en reservas

Mensaje de error

  • Cannot use max slots without enabling reservation-based fairness.

Causa

Estás intentando configurar una capacidad máxima de reserva, por ejemplo, max_slots o reservas predecibles, lo que requiere que se habilite la equidad basada en reservas en el proyecto que posee la reserva.

Solución

Debes habilitar la equidad basada en reservas en el proyecto.

Soluciona problemas de compromisos de capacidad

En esta sección, se describen los pasos para solucionar problemas que pueden resultarte útiles si tienes problemas con los compromisos de capacidad de BigQuery.

Las ranuras compradas están pendientes

Las ranuras están sujetas a la capacidad disponible. Cuando compras compromisos de ranuras y BigQuery los asigna, la columna Estado muestra una marca de verificación. Si BigQuery no puede asignar las ranuras solicitadas de inmediato, la columna Estado permanece pendiente. Es posible que tengas que esperar varias horas para que haya ranuras disponibles. Si necesitas acceder a las ranuras con anterioridad, prueba los siguientes pasos:

  1. Borra el compromiso pendiente.
  2. Compra un compromiso nuevo con una cantidad menor de ranuras. Según la capacidad, el compromiso más pequeño podría activarse de inmediato.
  3. Compra las ranuras restantes como un compromiso independiente. Estas ranuras podrían mostrarse como pendientes en la columna Estado, pero suelen activarse en pocas horas.
  4. Opcional: Cuando ambos compromisos se activen, combínalos en un solo compromiso, siempre que ambos estén en la misma región y edición, y tengan el mismo plan de compromiso.

Si un compromiso de ranuras falla o tarda mucho tiempo en completarse, considera usar los precios a pedido de forma temporal. Con esta solución, puedes ejecutar consultas críticas en un proyecto diferente que no esté asignado a ninguna reserva, asignar el proyecto a None o quitar la asignación del proyecto por completo.

Soluciona problemas de contención de ranuras

La contención de ranuras puede ocurrir cuando no hay suficientes ranuras para ejecutar todos tus trabajos, lo que causa problemas de rendimiento. Para analizar si la degradación del rendimiento proviene de aumentos de la carga de trabajo o cambios en la configuración del entorno, puedes comparar dos intervalos del sistema en las reservas y los proyectos.

Para solucionar problemas de contención de ranuras, sigue estos pasos y prácticas recomendadas.

Si probaste estas prácticas recomendadas, pero aún tienes problemas de rendimiento en los trabajos, puedes solicitar asistencia.

Picos de simultaneidad de trabajos

Usa la vista detallada en los gráficos de recursos administrativos para verificar si hay un aumento repentino en las ejecuciones de trabajos con picos de uso de ranuras simultáneos. Estos picos pueden indicar que demasiados trabajos compiten por las ranuras disponibles en tu reserva.

Práctica recomendada: Considera optimizar las consultas que consumen muchos recursos o aumentar la capacidad de ranuras de tu reserva. Para obtener más información sobre cómo optimizar el rendimiento de las consultas, consulta Optimiza el procesamiento de las consultas.

Uso elevado de ranuras

Usa la vista detallada para verificar si aumentaron las duraciones de los trabajos, en especial si hay trabajos que superan la capacidad máxima de tu reserva. El uso de ranuras constantemente alto puede indicar una contención de ranuras en curso.

Práctica recomendada: Verifica las consultas con el filtro de contención de ranuras del explorador de trabajos para identificar las consultas que consumen más ranuras y optimizarlas.

Duraciones de trabajos prolongadas

Si los trabajos tardan mucho más en completarse, consulta la vista detallada. La alta simultaneidad de trabajos y los picos de uso de ranuras pueden indicar una contención de ranuras.

Práctica recomendada: Aísla los trabajos críticos pausando temporalmente los trabajos menos importantes o reduciendo la tasa general de envío de trabajos.

Mensajes de contención de ranuras

La tabla de estadísticas puede mostrar mensajes como There were NUMBER jobs detected with slot_contention in the reservation. que indican problemas de contención de ranuras. Consulta el explorador de trabajos para revisar los detalles sobre los trabajos específicos marcados en estos mensajes.

Práctica recomendada: Optimiza las consultas identificadas o ajusta la asignación de ranuras de tu reserva.

Soluciona problemas de supervisión de reservas

En las siguientes secciones, se describe cómo resolver problemas habituales cuando se supervisan las reservas de BigQuery y el uso de ranuras.

Las métricas de uso de ranuras no coinciden con INFORMATION_SCHEMA

Si encuentras discrepancias entre las métricas de uso de ranuras en los gráficos de recursos y los datos de INFORMATION_SCHEMA, intenta lo siguiente:

  • Reduce la granularidad. Cambia el nivel de detalle del gráfico a intervalos de 1 segundo en lugar de intervalos de 1 hora.
  • Alinea la agregación. Asegúrate de usar métodos de agregación que se alineen entre los gráficos de recursos y los datos de INFORMATION_SCHEMA. Por ejemplo, para reflejar mejor el uso máximo en los gráficos de recursos, cambia la agregación de métricas a p99 o p90 de forma coherente.

Las ranuras prestadas aparecen cuando se inhabilitan las ranuras inactivas

Es posible que tus gráficos de supervisión muestren un valor distinto de cero para borrowed_slots, incluso si se establece ignore_idle_slots=true para una o más reservas. Este parámetro de configuración impide que una reserva tome prestadas ranuras inactivas, pero no impide que preste sus ranuras sin usar a otras reservas.

Estas ranuras prestadas aparecen en los siguientes casos:

  • Préstamo a otras reservas. Una reserva con ignore_idle_slots=true puede prestar sus ranuras de modelo de referencia sin usar a otras reservas en el mismo proyecto de administración, región y edición que sí permiten el préstamo de ranuras inactivas (ignore_idle_slots=false). Si todas las reservas en un proyecto de administración, región y edición tienen ignore_idle_slots=true, las ranuras inactivas no se comparten entre ellas.

    Por ejemplo, supongamos que la reserva A tiene 100 ranuras, 0 uso y está configurada con ignore_idle_slots=true. La reserva B se encuentra en el mismo proyecto de administración, región y edición, tiene 100 ranuras, necesita 150 ranuras para su carga de trabajo y está configurada con ignore_idle_slots=false. La reserva B puede tomar prestadas 50 ranuras inactivas de la reserva A para satisfacer sus necesidades. Cuando esto ocurre, los gráficos de supervisión informan 50 lent_slots para la reserva A y 50 borrowed_slots para la reserva B.

  • El uso supera la capacidad. Si el uso de ranuras de una reserva supera temporalmente su capacidad (ranuras de referencia y con ajuste de escala automático), los gráficos de supervisión muestran esta diferencia como borrowed_slots. Este comportamiento puede ocurrir incluso en las reservas con ignore_idle_slots=true.

En ocasiones, el uso de ranuras puede exceder la suma del modelo de referencia y las ranuras a gran escala. No se te cobrará por el uso de ranuras que sea mayor que tu modelo de referencia, más las ranuras escaladas.

Las ranuras prestadas aparecen antes de que se use por completo una reserva

Los paneles de Monitoring usan datos de muestra, que podrían no reflejar con exactitud el momento preciso del uso de ranuras dentro de un intervalo de muestreo.

Para obtener un análisis más preciso del uso de ranuras, consulta las columnas relacionadas con las ranuras inactivas, como las columnas borrowed_slots y lent_slots en la vista INFORMATION_SCHEMA.RESERVATIONS_TIMELINE.

Soluciona problemas del registro de conversaciones

Usa la siguiente información para solucionar problemas habituales con el registro de conversaciones de las estadísticas de conversaciones en BigQuery. Debido a que los errores de registro nunca fallan en un turno de conversación y no se informan en el chat ni en Cloud Logging, una tabla de destino vacía o faltante es el indicador principal de un problema de configuración o de permisos.

Falta la tabla de registros o está vacía

Si la tabla de destino no se crea o permanece vacía después de un turno de conversación, verifica las siguientes causas posibles:

  • El registro de conversaciones no se guarda ni se publica. En BigQuery Studio, actualiza la página, vuelve a abrir la configuración del agente y confirma que la opción Habilitar el registro de conversaciones esté activada, que el conjunto de datos y la tabla de destino estén configurados y que se hayan publicado los cambios.

  • Falta el conjunto de datos de destino o se encuentra en un proyecto diferente. Confirma que el conjunto de datos de destino ya exista en el mismo proyecto que el agente de datos. Para verificar que el conjunto de datos exista, ejecuta bq show PROJECT_ID:LOG_DATASET. Reemplaza PROJECT_ID por el ID del proyecto que contiene el agente de datos y LOG_DATASET por el ID del conjunto de datos de destino. El agente de servicio crea la tabla de registro en el primer turno registrado, pero no crea el conjunto de datos.

  • Faltan permisos del agente de servicio o de CMEK. Confirma que el agente de servicio de la API de Conversational Analytics (service-PROJECT_NUMBER@gcp-sa-geminidataanalytics.iam.gserviceaccount.com, con el número del proyecto del agente en lugar del ID del proyecto) tenga el rol de editor de datos de BigQuery (roles/bigquery.dataEditor) en el conjunto de datos de registro. Si el conjunto de datos usa claves de Cloud KMS administradas por el cliente (CMEK), confirma que la cuenta de servicio de encriptación de BigQuery (bq-PROJECT_NUMBER@bigquery-encryption.iam.gserviceaccount.com) tenga el rol roles/cloudkms.cryptoKeyEncrypterDecrypter en la clave.

  • La plataforma de conversación o la configuración del agente no son compatibles. Las conversaciones en el panel de vista previa de BigQuery Studio no se registran. Realiza pruebas desde la pantalla de chat principal del agente publicado. No se registran los agentes que usan un permiso de búsqueda en lugar de tablas de BigQuery específicas, que configuran grafos de propiedades como fuentes de conocimiento o que no declaran ninguna tabla de BigQuery. Para obtener más información, consulta Limitaciones.

  • Las tablas de fuentes de conocimiento usan políticas de acceso. Si alguna tabla de fuente de conocimiento usa políticas de acceso a nivel de fila, seguridad a nivel de columna (etiquetas de política) o enmascaramiento de datos dinámico, no se registran los turnos.

  • Conflicto de esquema en una tabla de destino existente. Si configuraste una tabla existente como destino y una columna comparte un nombre con una columna de esquema de registro de conversaciones, pero tiene un tipo o modo diferente, BigQuery no escribe filas en esa tabla.

Por lo general, las filas aparecen unos segundos después de que se completa un turno. Si las filas aún no aparecen después de esperar unos minutos, actualiza el conjunto de datos.

No se registran las conversaciones de algunos usuarios

Causa

Antes de cada turno, la verificación de privacidad usa las credenciales del usuario que chatea para verificar que las tablas de fuentes de conocimiento del agente no tengan políticas de seguridad a nivel de fila, seguridad a nivel de columna ni enmascaramiento de datos. Si un usuario no tiene permiso para ejecutar esta verificación, sus turnos no se registran.

Solución

Otorga a todos los usuarios que chatean el rol de Visualizador de datos de BigQuery (roles/bigquery.dataViewer) en las tablas de fuentes de conocimiento y el rol de Usuario de trabajos de BigQuery (roles/bigquery.jobUser) en el proyecto que ejecuta sus consultas, o bien otorga un rol personalizado con los permisos bigquery.tables.get y bigquery.rowAccessPolicies.list en las tablas de fuentes de conocimiento.

No se puede guardar el agente y se produce un error INVALID_ARGUMENT

Mensaje de error

  • The BigQuery Agent Analytics table must be in the same project as the agent (agent project: ..., table project: ...).

  • BigQuery Agent Analytics can only be enabled on agents whose datasource is BigQuery. Remove bigquery_agent_analytics_enabled and bigquery_agent_analytics_table, or point the agent at a BigQuery datasource.

Causa

El conjunto de datos de destino se encuentra en un proyecto diferente al del agente de datos, o la fuente de datos del agente no es BigQuery.

Solución

Selecciona un conjunto de datos de destino existente en el mismo proyecto que el agente de datos o configura el agente de datos con una fuente de datos de BigQuery.

No se puede otorgar acceso al conjunto de datos porque el agente de servicio no existe

Mensaje de error

  • Service account service-PROJECT_NUMBER@gcp-sa-geminidataanalytics... does not exist

Causa

Aún no se aprovisionó el agente de servicio de la API de Conversational Analytics en el proyecto.

Solución

Realiza una de las siguientes acciones:

  • Primero, configura el destino de los registros en el agente y, luego, vuelve a otorgar el rol.

  • Aprovisiona la identidad del servicio ejecutando el siguiente comando:

    gcloud beta services identity create \
    --service=geminidataanalytics.googleapis.com \
    --project=PROJECT_ID

    Reemplaza PROJECT_ID por el ID del proyecto que contiene el agente de datos.

La configuración del registro de conversaciones no está disponible en BigQuery Studio

Causa

Estás viendo la versión Publicada del agente de datos, en la que los parámetros de configuración son de solo lectura, o el agente de datos no tiene tablas de BigQuery específicas seleccionadas como fuentes de conocimiento.

Solución

Cambia el selector de vista a Borrador, asegúrate de que se seleccionen tablas específicas de BigQuery como fuentes de conocimiento, actualiza la configuración de registro de conversaciones y, luego, publica el agente.

¿Qué sigue?