Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
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:
Establece una mayor cantidad de trabajadores para distribuir la carga de trabajo de manera más uniforme y reducir el impacto en el rendimiento de los eventos frecuentes de ajuste de escala automático.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[],[],null,["# Pub/Sub to BigQuery best practices\n\nThis page outlines best practices for optimizing a Dataflow\npipeline that [reads from\nPub/Sub](/dataflow/docs/concepts/streaming-with-cloud-pubsub) and\n[writes to BigQuery](/dataflow/docs/guides/write-to-bigquery).\nDepending on your use case, the following suggestions might lead to better\nperformance.\n\nInitial solutions for pipeline backlogs\n---------------------------------------\n\nWhen a Pub/Sub to BigQuery pipeline experiences a\ngrowing backlog and can't keep up with incoming messages, you can take the\nfollowing immediate steps:\n\n- **Increase Pub/Sub acknowledgment deadline:** For the associated Pub/Sub subscription, [increase the acknowledgment\n deadline](/pubsub/docs/lease-management) to a value slightly longer than the maximum expected message processing time. This prevents messages from being redelivered prematurely while they are still being processed.\n- **Scale out workers:** If the unacknowledged message count and subscription backlog are growing rapidly, the pipeline's processing capacity is likely insufficient. Increase the [number of Dataflow\n workers](/dataflow/docs/reference/pipeline-options) to handle the message volume.\n- **Enable exponential backoff:** Enable [exponential backoff](/pubsub/docs/handling-failures#exponential_backoff) to improve how the pipeline handles retries for transient issues, making it more resilient.\n\nLong-term code and pipeline optimizations\n-----------------------------------------\n\nFor sustained performance and stability, the following architectural and code\nchanges are recommended:\n\n- **Reduce `getTable` calls to BigQuery:** Excessive `getTable` method calls can lead to rate-limiting and performance bottlenecks. To mitigate this:\n - Cache table existence information in worker memory to avoid repeated calls for the same table.\n - Batch `getTable` calls on a per-bundle basis instead of for each individual element.\n - Refactor the pipeline code to eliminate the need to check for table existence for every message.\n- **Use the BigQuery Storage Write API:** For streaming pipelines writing to BigQuery, migrate from standard streaming inserts to the [Storage Write API](/bigquery/docs/write-api). The Storage Write API offers better performance and significantly higher quotas.\n- **Use the legacy Dataflow runner for high-cardinality jobs:** For jobs that process a very large number of unique keys (*high-cardinality*), the legacy Dataflow runner might offer better performance than Runner v2, unless cross-language transforms are required.\n- **Optimize the key space:** Performance can degrade when pipelines operate on millions of active keys. Adjust the pipeline's logic to perform work on a smaller, more manageable key space.\n\nResource, quota, and configuration management\n---------------------------------------------\n\nProper resource allocation and configuration are critical for pipeline health:\n\n- **Proactively manage quotas:** Monitor quotas and request increases for any quotas that might be reached during scaling events. For example, consider the following scaling events:\n - A high rate of calls to the `TableService.getTable` or `tabledata.insertAll` methods might exceed the maximum queries per second (QPS). For more information on limits and how to request more quota, see [BigQuery quotas and\n limits](/bigquery/quotas).\n - Compute Engine quotas for in-use IP addresses and CPUs might exceed maximum limits. For more information on limits and how to request more quota, see the [Compute Engine quota and limits\n overview](/compute/quotas-limits).\n- **Optimize worker configuration:** To prevent out-of-memory (OOM) errors and improve stability:\n - Use worker [machine\n types](/dataflow/docs/guides/configure-worker-vm#machine-type) with more memory.\n - Reduce the [number of\n threads](/dataflow/docs/reference/pipeline-options#resource_utilization) per worker.\n - Set a higher [number of\n workers](/dataflow/docs/reference/pipeline-options#resource_utilization) to distribute the workload more evenly and reduce the performance impact of frequent autoscaling events.\n\nWhat's next\n-----------\n\n- [Develop and test Dataflow pipelines](/dataflow/docs/guides/develop-and-test-pipelines)\n- [Dataflow pipeline best practices](/dataflow/docs/guides/pipeline-best-practices)\n- [Dataflow job metrics](/dataflow/docs/guides/using-monitoring-intf)"]]
