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 trabajos pendientes de la canalización

Cuando una canalización de Pub/Sub a BigQuery experimenta un trabajo pendiente cada vez mayor y no puede mantenerse al día con los mensajes entrantes, puedes seguir estos pasos inmediatos:

  • Aumenta el plazo de confirmación de Pub/Sub: Para la suscripción de Pub/Sub asociada, aumenta el plazo de confirmación a un valor un poco más largo que el tiempo máximo esperado de procesamiento de mensajes. Esto evita que los mensajes se vuelvan a entregar de forma prematura mientras aún se procesan.
  • Aumenta la cantidad de trabajadores: Si la cantidad de mensajes no confirmados y el trabajo pendiente de la suscripción 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 resistente.

Optimizaciones de código y canalización a largo plazo

Para un rendimiento y una estabilidad sostenidos, se recomiendan los siguientes cambios arquitectónicos y de código:

  • Reduce getTable calls to BigQuery: Las llamadas excesivas al getTable método pueden provocar la limitación de frecuencia y cuellos de botella en el rendimiento. Para mitigar esto, 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.
    • Procesa por lotes las llamadas a getTable por paquete en lugar de hacerlo 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 ejecutor de Java de transmisión estándar (antes llamado ejecutor v1) para trabajos de alta cardinalidad: Para los trabajos que procesan una gran cantidad de claves únicas (alta cardinalidad), el ejecutor de Java de transmisión podría ofrecer un mejor rendimiento que el ejecutor portátil, a menos que se requieran transformaciones entre lenguajes.
  • Optimiza el espacio de claves: El rendimiento puede degradarse cuando las canalizaciones operan en millones de claves activas. Ajusta la lógica de la canalización para realizar el trabajo en un espacio de claves más pequeño y manejable.

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 cuotas que se puedan alcanzar durante los eventos de ajuste de escala. Por ejemplo, considera los siguientes eventos de ajuste de escala:
    • Una alta tasa de llamadas a los métodos TableService.getTable o tabledata.insertAll podría exceder las consultas máximas 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.
    • Las cuotas de Compute Engine para las direcciones IP y las CPU en uso podrían exceder 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 cuota de Compute Engine.
  • Optimiza la configuración del trabajador: Para evitar errores de falta de memoria (OOM) y mejorar la estabilidad, haz lo siguiente:

¿Qué sigue?