Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Soluciona problemas de errores de la API de BigQuery Storage

En este documento, se explica cómo solucionar problemas cuando lees o transmites datos en BigQuery con la API de BigQuery Storage Read, la API de BigQuery Storage Write (gRPC) o las inserciones de transmisión con la API de BigQuery Storage Write (REST) (método tabledata.insertAll).

Analiza la telemetría de transmisión con vistas INFORMATION_SCHEMA

Puedes consultar las vistas de INFORMATION_SCHEMA para supervisar el estado de la transferencia de datos de transmisión, identificar los cuellos de botella de la capacidad de procesamiento y, también, inspeccionar los códigos de error en intervalos de un minuto:

API de Storage Write (gRPC): Consulta las vistas de INFORMATION_SCHEMA.WRITE_API_TIMELINE para inspeccionar las solicitudes de transferencia de transmisión de gRPC, los bytes y las filas totales agregados, y los recuentos de errores por error_code.
API de Storage Write (REST): Consulta las vistas de INFORMATION_SCHEMA.STREAMING_TIMELINE para inspeccionar las solicitudes de transmisión de tabledata.insertAll de REST heredadas y los errores de cuota o límite de frecuencia.

En el siguiente ejemplo, se consulta INFORMATION_SCHEMA.WRITE_API_TIMELINE_BY_PROJECT para recuperar los recuentos de errores y los bytes transferidos para la API de Storage Write (gRPC) en las últimas 24 horas:

SELECT
  start_timestamp,
  error_code,
  SUM(total_requests) AS request_count,
  SUM(total_input_bytes) AS input_bytes
FROM
  `region-REGION`.INFORMATION_SCHEMA.WRITE_API_TIMELINE_BY_PROJECT
WHERE
  start_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND error_code IS NOT NULL
GROUP BY
  start_timestamp,
  error_code
ORDER BY
  start_timestamp DESC;

Reemplaza REGION por el nombre de la región del conjunto de datos, como us o europe-west1.

Soluciona problemas de errores de la API de Storage Read

Los siguientes son errores comunes que se encuentran cuando usas la API de Storage Read:

Error: Stream removed: Resolución: Vuelve a intentar la solicitud a la API de Storage Read. Es probable que se trate de un error transitorio que puedes resolver volviendo a intentar la solicitud. Si el problema persiste, comunícate con Atención al cliente de Cloud.
Error: Stream expired: Causa: Este error se produce cuando la sesión de la API de Storage Read alcanza el tiempo de espera de 6 horas.; Resolución:

Aumenta el paralelismo del trabajo.
Si el uso de CPU de los nodos de trabajadores es relativamente constante y no supera el 85%, considera ejecutar el trabajo en un tipo de máquina más grande.
Divide el trabajo en varios trabajos o consultas más pequeñas.

Para obtener más información sobre la administración de sesiones y la lectura de datos, consulta la descripción general de la API de Storage Read.

Soluciona problemas de inserciones de transmisión

En las siguientes secciones, se analiza cómo solucionar errores que ocurren cuando transmites datos a BigQuery con la API de Storage Write (REST). Si deseas obtener más información para resolver errores de cuota de las inserciones de transmisión, consulta Errores de cuota de inserción de transmisión.

Códigos de respuesta HTTP de falla

Si recibes un código de respuesta HTTP de falla, como un error de red, no hay forma de saber si la inserción de transmisión se realizó de forma correcta. Si solo intentas volver a enviar la solicitud, puede que obtengas filas duplicadas en tu tabla. Para proteger tu tabla de la duplicación, establece la propiedad insertId cuando envíes tu solicitud. BigQuery usa la propiedad insertId para la deduplicación.

Si recibes un error de permiso, un error de nombre de tabla no válido o un error de cuota excedida, no se insertarán filas y fallará toda la solicitud.

Códigos de respuesta HTTP de éxito

Incluso si recibes un código de respuesta HTTP correcto, debes verificar la propiedad insertErrors de la respuesta para determinar si las inserciones de fila se completaron, ya que es posible que BigQuery solo haya insertado de forma correcta algunas de las filas. Es posible que encuentres una de las siguientes situaciones:

Todas las filas se insertaron correctamente: Si la propiedad insertErrors es una lista vacía, todas las filas se insertaron correctamente.
Algunas filas se insertaron correctamente: Excepto en los casos en los que no coincide el esquema en alguna de las filas, las filas indicadas en la propiedad insertErrors no se insertan, y todas las demás se insertan correctamente. La propiedad errors contiene información detallada sobre por qué falló cada fila no exitosa. La propiedad index indica el índice de filas basado en 0 de la solicitud a la que se aplica el error.
No se insertaron filas correctamente: Si BigQuery detecta una discrepancia de esquema en filas individuales de la solicitud, no se inserta ninguna de las filas y se devuelve una entrada insertErrors para cada fila, incluso para las filas que no tuvieron una discrepancia de esquema. Las filas cuyos esquemas coincidieron tendrán un error con la propiedad reason establecida en stopped y se pueden volver a enviar como están. Las filas que tuvieron un error incluyen información detallada sobre la falta de coincidencia del esquema. Para obtener información sobre los tipos de búferes de protocolo admitidos para cada tipo de datos de BigQuery, consulta Tipos de datos de búferes de protocolo y Arrow admitidos.

Errores de metadatos para inserción de transmisión

Dado que la API de transmisión de BigQuery está diseñada para altas tasas de inserción, las modificaciones en los metadatos de la tabla subyacente son coherentes de forma eventual cuando se interactúa con el sistema de transmisión. La mayoría de las veces, los cambios en los metadatos se propagan en cuestión de minutos, pero, durante este período, las respuestas de la API pueden reflejar el estado incoherente de la tabla.

Algunas situaciones incluyen las siguientes:

Cambios de esquema: Modificar el esquema de una tabla que recibió inserciones de transmisión recientemente puede causar respuestas con errores de no coincidencia del esquema, ya que es posible que el sistema de transmisión no detecte el cambio de esquema de inmediato.
Creación o eliminación de tablas: La transmisión a una tabla inexistente devuelve una variación de una respuesta notFound. Es posible que una tabla creada en respuesta no se reconozca de inmediato en las inserciones de transmisión posteriores. Del mismo modo, borrar o volver a crear una tabla puede generar un período en el que las inserciones de transmisión se envían a la tabla anterior. Es posible que las inserciones de transmisión no estén presentes en la tabla nueva.
Truncamiento de tablas: De manera similar, truncar los datos de una tabla (mediante un trabajo de consulta que usa un valor de writeDisposition de WRITE_TRUNCATE) puede provocar que se descarten las inserciones posteriores durante el período de coherencia.

Faltan datos o no están disponibles

Las inserciones de transmisión residen de manera temporal en el almacenamiento optimizado para escritura, que tiene características de disponibilidad diferentes de las del almacenamiento administrado. Ciertas operaciones en BigQuery no interactúan con el almacenamiento optimizado para escritura, como los trabajos de copia de tablas y los métodos de API como tabledata.list. Los datos de transmisión recientes no están presentes en la tabla de destino ni en el resultado.

Errores de cuota relacionados con la inserción de transmisión

En esta sección, se proporcionan sugerencias para solucionar errores de cuota relacionados con la transmisión de datos a BigQuery.

En ciertas regiones, las inserciones de transmisión tienen una cuota más alta si no propagas el campo insertId de cada fila. Si deseas obtener más información sobre las cuotas de las inserciones de transmisión, consulta Inserciones de transmisión. Los errores relacionados con la cuota de transmisión de BigQuery dependen de la presencia o ausencia de insertId.

Mensaje de error

Si el campo insertId está vacío, es posible que surja el siguiente error de cuota:

Límite de cuota	Mensaje de error
Bytes por segundo por proyecto	La entidad con gaia_id `GAIA_ID`, del proyecto `PROJECT_ID` en la región `REGION` superó la cuota de inserción de bytes por segundo.

Si se propaga el campo insertId, es posible que surjan los siguientes errores de cuota:

Límite de cuota	Mensaje de error
Filas por segundo por proyecto	El proyecto `PROJECT_ID` en la región `REGION` superó la cuota de inserción de transmisión de filas por segundo.
Filas por segundo por tabla	La tabla `TABLE_ID` superó la cuota de inserción de transmisión de filas por segundo.
Bytes por segundo por tabla	La tabla `TABLE_ID` superó la cuota de inserción de transmisión de bytes por segundo.

El propósito del campo insertId es anular la duplicación de las filas insertadas. Si varias inserciones con el mismo insertId llegan dentro de un período de pocos minutos, BigQuery escribe una sola versión del registro. Sin embargo, esta anulación automática de duplicación no está garantizada. Para obtener la máxima capacidad de procesamiento de transmisión, recomendamos que no incluyas insertId y, en su lugar, uses la anulación manual de duplicación. Para obtener más información, consulta Garantiza la coherencia de los datos.

Cuando encuentres este error, diagnostica el problema y, luego, sigue los pasos recomendados para resolverlo.

Diagnóstico

Usa las vistas STREAMING_TIMELINE_BY_* para analizar el tráfico de transmisión. Estas vistas agregan estadísticas de transmisión en intervalos de un minuto, agrupadas por error_code. Los errores de cuota aparecen en los resultados con error_code igual a RATE_LIMIT_EXCEEDED o QUOTA_EXCEEDED.

Según el límite de cuota específico que se haya alcanzado, observa total_rows o total_input_bytes. Si el error se produjo en una cuota a nivel de tabla, filtra por table_id.

Por ejemplo, en la siguiente consulta, se muestra el total de bytes transferidos por minuto y la cantidad total de errores de cuota:

SELECT
 start_timestamp,
 error_code,
 SUM(total_input_bytes) as sum_input_bytes,
 SUM(IF(error_code IN ('QUOTA_EXCEEDED', 'RATE_LIMIT_EXCEEDED'),
     total_requests, 0)) AS quota_error
FROM
 `region-REGION_NAME`.INFORMATION_SCHEMA.STREAMING_TIMELINE_BY_PROJECT
WHERE
  start_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
GROUP BY
 start_timestamp,
 error_code
ORDER BY 1 DESC

Solución

Para resolver este error, haz lo siguiente:

Si usas el campo insertId para la anulación de duplicación, y tu proyecto está en una región que admite la cuota de transmisión más alta, te recomendamos que quites el campo insertId. Esta solución puede requerir algunos pasos adicionales para anular manualmente los duplicados de los datos. Para obtener más información, consulta Quita los duplicados manualmente.
Si no usas insertId o si no es viable quitarlo, supervisa el tráfico de transmisión durante un período de 24 horas y analiza los errores de cuota:
- Si ves sobre todo errores RATE_LIMIT_EXCEEDED, en lugar de errores QUOTA_EXCEEDED, y el tráfico total es inferior al 80% de la cuota, es probable que los errores indiquen aumentos de tráfico temporales. Puedes abordar estos errores si reintentas la operación mediante una retirada exponencial entre los reintentos.
- Si usas un trabajo de Dataflow para insertar datos, considera usar trabajos de carga en lugar de inserciones de transmisión. Para obtener más información, consulta Configura el método de inserción. Si usas Dataflow con un conector de E/S personalizado, considera usar un conector de E/S integrado en su lugar. Para obtener más información, consulta Patrones de E/S personalizados.
- Si ves errores QUOTA_EXCEEDED o si el tráfico total supera el 80% de la cuota de forma constante, envía una solicitud de aumento de cuota. Para obtener más información, consulta Solicita un ajuste de cuota.
- También puedes considerar reemplazar las inserciones de transmisión con la API de Storage Write más reciente, que tiene una capacidad de procesamiento mayor, un precio más bajo y muchas funciones útiles.