Prácticas recomendadas para Pub/Sub a BigQuery

En esta página, se describen las prácticas recomendadas para optimizar una canalización de Dataflow que lee desde Pub/Sub y escribe en BigQuery. Según tu caso de uso, las siguientes sugerencias podrían mejorar el rendimiento.

Soluciones iniciales para los retrasos en las canalizaciones

Cuando una canalización de Pub/Sub a BigQuery experimenta una acumulación creciente y no puede seguir el ritmo de los mensajes entrantes, puedes seguir estos pasos inmediatos:

  • Aumenta el plazo de confirmación de Pub/Sub: Para la suscripción asociada a Pub/Sub, aumenta el plazo de confirmación a un valor ligeramente superior al tiempo máximo esperado de procesamiento de mensajes. Esto evita que los mensajes se vuelvan a entregar de forma prematura mientras aún se están procesando.
  • Aumenta la cantidad de trabajadores: Si el recuento de mensajes no confirmados y el backlog de suscripciones aumentan rápidamente, es probable que la capacidad de procesamiento de la canalización sea insuficiente. Aumenta la cantidad de trabajadores de Dataflow para controlar el volumen de mensajes.
  • Habilita la retirada exponencial: Habilita la retirada exponencial para mejorar la forma en que la canalización controla los reintentos de problemas transitorios, lo que la hace más resiliente.

Optimizaciones de código y canalizaciones a largo plazo

Para mantener el rendimiento y la estabilidad, se recomiendan los siguientes cambios en la arquitectura y el código:

  • Reduce las llamadas a getTable en BigQuery: Las llamadas excesivas al método getTable pueden provocar limitaciones de frecuencia y cuellos de botella en el rendimiento. Para mitigar este problema, haz lo siguiente:
    • Almacena en caché la información de existencia de la tabla en la memoria del trabajador para evitar llamadas repetidas a la misma tabla.
    • Llama a getTable por lotes para cada paquete en lugar de para cada elemento individual.
    • Refactoriza el código de la canalización para eliminar la necesidad de verificar la existencia de la tabla para cada mensaje.
  • Usa la API de BigQuery Storage Write: Para las canalizaciones de transmisión que escriben en BigQuery, migra de las inserciones de transmisión estándar a la API de Storage Write. La API de Storage Write ofrece un mejor rendimiento y cuotas significativamente más altas.
  • Usa el Runner de Dataflow heredado para trabajos de alta cardinalidad: Para los trabajos que procesan una gran cantidad de claves únicas (alta cardinalidad), el Runner de Dataflow heredado puede ofrecer un mejor rendimiento que Runner v2, a menos que se requieran transformaciones entre lenguajes.
  • Optimiza el espacio de claves: El rendimiento puede disminuir cuando las canalizaciones operan con millones de claves activas. Ajusta la lógica de la canalización para que funcione en un espacio de claves más pequeño y fácil de administrar.

Administración de recursos, cuotas y configuración

La asignación y configuración adecuadas de los recursos son fundamentales para el estado de la canalización:

  • Administra las cuotas de forma proactiva: Supervisa las cuotas y solicita aumentos para las que se puedan alcanzar durante los eventos de ajuste de escala. Por ejemplo, considera los siguientes eventos de escalamiento:
    • Una alta tasa de llamadas a los métodos TableService.getTable o tabledata.insertAll podría exceder la cantidad máxima de consultas por segundo (QPS). Para obtener más información sobre los límites y cómo solicitar más cuota, consulta Cuotas y límites de BigQuery.
    • Es posible que las cuotas de Compute Engine para las direcciones IP y las CPU en uso superen los límites máximos. Para obtener más información sobre los límites y cómo solicitar más cuota, consulta la descripción general de los límites y la cuota de Compute Engine.
  • Optimiza la configuración del trabajador: Para evitar errores de memoria insuficiente (OOM) y mejorar la estabilidad, haz lo siguiente:

¿Qué sigue?