Organízate con las colecciones
Guarda y clasifica 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 de Pub/Sub y escribe en BigQuery.
En función de tu caso de uso, las siguientes sugerencias pueden mejorar el rendimiento.
Soluciones iniciales para las acumulaciones de la canalización
Cuando un flujo de procesamiento de Pub/Sub a BigQuery experimenta un creciente retraso y no puede seguir el ritmo de los mensajes entrantes, puedes tomar las siguientes medidas inmediatas:
Aumenta el plazo de confirmación de Pub/Sub: en la suscripción de Pub/Sub asociada, aumenta el plazo de confirmación a un valor ligeramente superior al tiempo máximo de procesamiento de mensajes previsto. De esta forma, se evita que los mensajes se vuelvan a enviar prematuramente mientras se siguen procesando.
Ampliar los trabajadores: si el recuento de mensajes no reconocidos y el backlog de suscripciones aumentan rápidamente, es probable que la capacidad de procesamiento de la canalización sea insuficiente. Aumenta el número de trabajadores de Dataflow para gestionar el volumen de mensajes.
Habilita el tiempo de espera exponencial: habilita el tiempo de espera exponencial
para mejorar la forma en que la canalización gestiona los reintentos de problemas transitorios, lo que la hace
más resistente.
Optimizaciones de código y de la canalización a largo plazo
Para mantener el rendimiento y la estabilidad, se recomienda hacer los siguientes cambios en la arquitectura y el código:
Reduce las llamadas getTable a BigQuery: un número excesivo de llamadas al método getTable
puede provocar limitaciones de frecuencia y cuellos de botella en el rendimiento. Para
mitigar este problema:
Almacena en caché la información sobre la existencia de la tabla en la memoria del trabajador para evitar llamadas repetidas a la misma tabla.
Llamadas por lotes getTable por paquete en lugar de por cada elemento individual.
Refactoriza el código de la canalización para que no sea necesario comprobar la existencia de la tabla en cada mensaje.
Usa la API Storage Write de BigQuery: en las canalizaciones de streaming que escriben en BigQuery, migra de las inserciones de streaming estándar a la
API Storage Write. La API Storage Write ofrece un mejor rendimiento y cuotas significativamente más altas.
Usa el antiguo ejecutor de Dataflow para tareas de alta cardinalidad:
en las tareas que procesan un número muy elevado de claves únicas
(alta cardinalidad), el antiguo ejecutor de Dataflow puede ofrecer
un mejor rendimiento que el ejecutor v2, a menos que se necesiten transformaciones entre lenguajes.
Optimizar 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 gestionar.
Gestión de recursos, cuotas y configuración
La asignación y la configuración adecuadas de los recursos son fundamentales para el buen estado de la canalización:
Gestionar las cuotas de forma proactiva: monitoriza las cuotas y solicita aumentos para las que puedan alcanzarse durante los eventos de escalado. Por ejemplo, supongamos que se dan los siguientes eventos de escalado:
Si se llama a los métodos TableService.getTable o tabledata.insertAll con una frecuencia alta, se puede superar el número máximo de consultas por segundo (CPS). 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 CPUs en uso pueden superar 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 las cuotas y los límites de Compute Engine.
Optimiza la configuración de los trabajadores: para evitar errores de falta de memoria y mejorar la estabilidad:
Define un número de trabajadores más alto para distribuir la carga de trabajo de forma más uniforme y reducir el impacto en el rendimiento de los eventos de autoescalado frecuentes.
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-10 (UTC)."],[],[],null,["This 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\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\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\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- [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)"]]
